zoukankan      html  css  js  c++  java
  • 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");

      

      

         

      

  • 相关阅读:
    SIP穿越NAT SIP穿越防火墙-SBC
    安卓SAX解析XML文件
    C#进阶系列——WebApi 异常处理解决方案
    C#进阶系列——WebApi 接口返回值不困惑:返回值类型详解
    C#进阶系列——WebApi 接口参数不再困惑:传参详解
    C#进阶系列——WebApi 身份认证解决方案:Basic基础认证
    C#进阶系列——WebApi 跨域问题解决方案:CORS
    C#进阶系列——WebApi 接口测试工具:WebApiTestClient
    微信公众平台向特定用户推送消息
    JSONP跨域的原理解析
  • 原文地址:https://www.cnblogs.com/E-WALKER/p/4759043.html
Copyright © 2011-2022 走看看