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");

  

     

  

上一篇:Jenkins的一个bug-同时build一个项目两次导致失败


下一篇:jquery元素查找方法