webpack 学习笔记 01 使用webpack的原因

本系列文章实际上就是官网文档的翻译加上自己实践过程中的理解。

　　

　　伴随着websites演化至web apps的过程，有三个现象是很明显的：

1. 页面中有越来越多的Js。
2. 客户端能做的事情越来越多。
3. 越来越少的页面重载(当然也伴随着更复杂的代码)。

　　这些现象导致了什么？大量的前端代码。　　

　　庞大的代码库需要被高效的组织。而Module(组件式)开发的系统即为大多数开发者采取的途径。

 

　 MODULE SYSTEM STYLES

　　有很多种定义依赖，导出变量的标准或者说方法：

• <script> tag 的形式(不通过组件系统)      
• CommonJs
• Amd形式
• ES6组件
• 各种其它风格。。　　　　

     

　　<script>tag形式

　　在非组件系统中，我们的模块化后的代码是这样被组织的。

　　<script src="module1.js"></script>　　<script src="module2.js"></script>　　<script src="libraryA.js"></script>　　<script src="module3.js"></script>

 

　　各个组件向全局变量提供了一个个接口(如：浏览器环境的 window对象)。之后，借助全局对象，我们就能使用这些组件。

　　痛点

• 全局对象可能会有属性间冲突(这就是Jquery提供了给$重命名途径的原因)
• 我们需要关心组件加载的顺序(先加载依赖项)
• 开发者需要花很多精力来解决依赖问题。
• 在较大的项目中，tag列表将会变得非常的大且难于维护。　　

 

　  CommonJs：同步式的require

　　这种风格的组件系统使用同步的形式来加载依赖项，并返回导出的接口。每一个组件可以借助exports对象或者配置module.exports来导出接口(Node.js开发者再熟悉不过了)。

    require("module");    require("../file.js");    exports.doStuff = function() {};    module.exports = someValue;

　　优点

• 适合用作后端的组件(一次性加载到Cache以重用)
• 已经有了很多此风格的组件(NPM)
• 简单易用

　　痛点

• 阻塞式，不适合前端。

　　典例

• node.js
• browserify
• modules-webmake
• wreq

 

    AMD：异步式的require

　  AMD的全称是Asynchronous Module Definition，很多需要用到组建式系统，但又感受到它们在前端的痛点的开发者建设了AMD。

    require(["module", "../file"], function(module, file) { /* ... */ });    define("mymodule", ["dep1", "dep2"], function(d1, d2) {      return someExportedValue;        });

　  优点

• 异步加载，适合前端环境。
• 并行加载，带来速度提升。

　　痛点

• 带来了更多的代码工作量。

　　典例

• require.js
• curl.js

 

　 ES6组件

　  From EcmaScript6

    import "jquery";    export function doStuff() {}    module "localModule" {}

 　 虽然是标准，但是被浏览器广泛支持还需要一段时间。

 

　TRANSFERRING

　  组件虽然被执行于客户端，但不可避免需要经由服务器传送。

　  关于组件的传送，有两个极端：

1. 每个组件，一个HTTP请求。
   • 优点：仅仅传送依赖项。
   • 缺点：请求多，负载高，更慢的启动延迟。
2. 所有的组件，一个HTTP请求。
   • 优点：更快，更低延迟。
   • 传送了没必要传的东西。

　　让我们在两者间做一个妥协。在大多数情况下，以下的方法将更为适用：

　　－>在编译所有的组件时，将组件分为多种批次(chunks or batches)。

　　再某个批次再被需要的时候，再发送他们。

　　解决了前者带来的请求的高延迟、高负载，后者带来的无必要信息的传送。

　　那么，问题来了，这个分批次由谁来做？

　　webpack。

　　当然，gulp，grunt也是时下很火的可选项。具体工具的选型，仁者见仁，智者见智。 

　　

　 WHY ONLY JAVASCRIPT?

　　组件化系统难道就只能为javascript服务吗？前端还需要解决的问题有

• 样式表
• 图片
• 字体
• 模版
• coffeescript -> js
• less -> css
• jade -> html
• 各种。。。。。。

　　没错，这些，webpack也能搞定

    require("./style.css");    require("./style.less");    require("./template.jade");    require("./image.png");

 

　　

  

　  　　

 

　　

分类: webpack

标签: webpack, frontend