webpack 学习笔记 01 使用webpack的缘由

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

  

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

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

  这些现象致使了什么?大量的前端代码。  html

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

 

  MODULE SYSTEM STYLES

  有不少种定义依赖,导出变量的标准或者说方法:java

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

     

  <script>tag形式

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

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

 

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

  痛点webpack

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

 

   CommonJs:同步式的require

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

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

  优势gulp

  • 适合用做后端的组件(一次性加载到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");
相关文章
相关标签/搜索