zoukankan      html  css  js  c++  java
  • 前端工具之WebPack解密之背景

    请注意,这是一篇站在完全新手的角度上来写的文章。可能你是一个后端人员想了解前端工具的使用和概念;也可能你是一个前端小菜(还在DIV+CSS的世界里挣扎着)。本文比较适合那些以前完全没有接触过WebPack,而又想使用的朋友。通过本文你能理解webPack工作原理及做用!(不会至于看了半天资料还没有头绪!)

    前言:本人是一个从后端转向前端的程序猿,在此之前对于前端的印象一直是:HTML + CSS + JS。完全没有想过前端会发展的如此的迅速,各种名词的出现:Node、NPM、Grunt、Gulp、Bower、Webpack、Browserify、Yeoman。瞬间让感觉到不知道如何下手(好像根本学不完的样子)!

    先上一张别人的图,目前的前端工具!

    一些前端工具

    一、背景

    如果你和我一样,之前对于前端打包工具的发展一无所知,甚至于不知道这些工具出现的必要性。你可以浏览此部分的内容,如果你不想知道这些或者对这些并不感兴趣,可以直接跳过此部分。

    互联网程序现状

    随着移动互联的来袭,当前越来越多的网站已经从单纯的网页模式,开始升级为webapp模式。它们运行在现代的浏览器中,使用HTML5、CSS3、ES6等技术开发,已经从单一的浏览功能转变为一个基于浏览器的富客户端。并且webapp通常是一个SPA(Single Page Application 单页面应用)。每个页面(View)通过异步的方式加载,有着良好的用户体验。但是这样做的结果是导致程序初始化和使用的过程中需要更多、更复杂的JavaScript代码来实现,这就对前端程序的开发带来巨大的挑战!

    模块化系统的演变

    随着程序的复杂性的增加,项目结构的庞大。把单一js文件按职责进行模块化划分。

    我们在写页面的时候会这样写:

    <script src="base.js"></script>
    <script src="utils.js"></script>
    <script src="vipPush.js"></script>
    

    这是最基础的JavaScript加载方式,每个JS的所有方法和属性都是暴露在window对象中的(就像把所有代码都放在一个命名空间或者同一个包下),借助全局对象,我们就能使用这些属性和方法。如果更为复杂的程序会使用命名空间的概念来组织这些模块的接口,比如:YUI

    这种开发方式带来的弊端:

    • 全局的作用域下容易造成变量的相互冲突(这是一个很常见的问题)
    • 文件只能按照<script>的书写顺序进行加载
    • 开发者要解决各个模块和代码库之间的依赖
    • 如果按照此模式进行开发,长期下去整个项目(前端)代码必定会混乱不堪

    因为有了模块的概念,让我们的开发变得比较方便。让我们可以很方便的使用别人的代码,想要什么功能就加载什么模块。这样下去模块的规范就变的更重要。目前:通用的JavaScript模块主要有:

    1. CommonJs
    2. AMDCMD
    3. ES6的模块

    CommonJS: 同步加载解决方案

    著名的node.js模块系统就是参照CommonJS规范来实现的。其核心思想就是通过require来进行同步加载其它模块,然后通过exportsmodule.exports来导出需要暴露的接口。

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

    优点:

    1. 服务器端模块便于重用
    2. 在NPM里有很多功能模块
    3. 简单易用

    缺点:

    1. 同步加载的方式注定不能用于客户端(clients),同步的加载意味着阻塞加载,浏览器的加载方式是异步的
    2. 不能非阻塞的并行加载多个模块

    代表:

    1. 服务端 node.js
    2. Browserify,浏览器端的 CommonJS 实现,可以使用 NPM 的模块,但是编译打包后的文件体积可能很大

    AMD: 异步加载解决方案

    AMD(asynchronous Module Definition)意思就是"异步模块定义",其规范主要是一个接口define(id?, dependencies?, factory),它采用的是异步加载的方式加载模块,模块的加载不影响它后面请语句的运行。所有执行语句都是在模块加载完成之后的回调函数中执行的。

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

    优点:

    1. 适合在浏览器环境中进行加载模块
    2. 可以并行多个模块

    缺点:

    1. 提高了并发的成功,代码的阅读和书写比较困难
    2. 不符合通用模块化的思维方式,是一种妥协的实现

    实现:

    CMD: 另一种异步加载解决方案

    CMD(Common Module Definition)规范与AMD很相似,尽量保持简单,并与CommonJs和Node.js的Module规范保持了很大的兼容性

    define(function(require, exports, module) {
      var $ = require('jquery');
      var Spinning = require('./spinning');
      exports.doSomething = ...
      module.exports = ...
    })
    

    优点:

    1. 依赖就近,延迟执行
    2. 可以很容易在 Node.js 中运行

    缺点:

    1. 依赖 SPM 打包,模块的加载逻辑偏重

    实现:

    ES6 模块

    在ECMAScript2015(es6)中,增加了JavaScript语言层面上的模块体系定义,其设计思想是:尽量的静态化,使得编译时就能确定模块的依赖关系,以及输入和输出变量。

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

    优点:

    1. 容易进行静态分析
    2. 面向未来的 EcmaScript 标准

    缺点:

    1. 原生浏览器端还没有实现该标准
    2. 全新的命令字,新版的 Node.js才支持

    实现:

    把程序所有的文件进行模块化之后,我们还要处理一个问题那就是传输问题。模块的化分让我们可以让程序变得可以组件化进行开发,组件虽然被客户端执行,但是依然要由服务器传送给客户端。

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

    1. 每个组件,一个HTTP请求

      • 优点:仅仅传送依赖项
      • 缺点:请求多,负载高,更慢的启动延迟
    2. 所有的组件,一个HTTP请求

      • 优点: 更快,更低的延迟
      • 传送了没有必要传送的东西

    让我在这两种情况之间做一个妥协:分块传输,按需进行懒加载,在实际用某些模块的时候进行增量的更新,才是比较合理的加载方案。

    要实现这个功能,需要在编译打包时进行静态的分析、模块进行分批次的打包。那么这个分批次谁来做呢?
    答案就是:WebPack

    参考资料:

  • 相关阅读:
    类型反射和晚期绑定
    JS读写Cookie(设置、读取、删除)
    数据绑定
    解读代码
    ASP.NET vNext (一)- 基本概念和环境配置
    设计模式总结
    面向接口编程技术架构图
    搞个这样的APP要多久? (转)
    网站服务架构(转)
    jexus
  • 原文地址:https://www.cnblogs.com/zxdBlog/p/6112147.html
Copyright © 2011-2022 走看看