为什么需要web模块

这是原文的地址:why web modules?

这篇文章是摘自requirejs官网里的一篇文章,个人觉的从这里可以找出前端为什么需要引入模块思想

我们先来看看,没引入模块之前,将要面临的问题:

  • web 站点向 web app发展
  • 代码越来越大
  • 构建越来越困难
  • 开发者想分离JS文件
  • 开发者想优化代码以提高http性能

解决方案

前端开发者可能需要以下的方案:

  • 类似于后端里的import/include/require 关键字语法
  • 加载依赖的能力
  • 一个容易使用的前端优化工具

先看看以有的第三方实现

脚本加载器

先整理出一些可选的第三方加载库

  • Dojo: dojo.require('some.module')
  • LABjs: $LAB.script('some/module.js')
  • CommonJS: require('some/module')

这些方法都可以加载指定的JS文件,理想情况下,我们可以使用commonJS语法来加载JS,因为以后越来越多的库使用它,而且我们想我们的代码可以重用.我们还需要某种语法,将允许装载今天存在纯JavaScript文件 - 开发人员不应该重写他们的JavaScript来获取脚本加载的好处。

但是我们需要一个在浏览器端运行的很好的加载库,commonJS require()是一个同步方法,默认是立即返回的,但是这个在浏览器内是不可能的.

异步与同步

下面的例子表明异步与同步的一个区别

var person = require('module/person');

function Manager(){
    this.reports = [];
}

Manager.prototype = new person; // --> browser is error

假如这个在NodeJS里运行是没问题的,模块会同步执行返回,但是在浏览器端,脚本显然会异步返回,这时候调用它的实例就会报错,那么我们怎么处理浏览器端的异步呢?

XHR 加载脚本

我们可以临时使用XMLHttpRequest(XHR)来加载脚本--通过正则获取到上面内容中的的模块,然后利用eval()或者script元素来把XHR返回的内容添充到text属性中或者eval执行它.

使用eval方法是不规范的:

  • 开发者从一开始就被教导不能使用eval
  • 有些执行环境不允许使用eval
  • eval很难调试,目前只有firbug,chrome提供的inspector有选项来指定eval文本的路径
  • eval上下文很难跨浏览器,也许只有在ie中使用execScript方法,这些就会导致代码块的差异

使用script标签来包含XHR的内容也是不对的:

  • 当调试出现bug的时候,出现的错误代码行号跟原始文件行号不一致

使用XHR来加载文件本身就有跨域的限制,虽然现在的浏览器已经支持跨域请求,但是IE是通过使用XDomainRequest对象,显然不规范导致的代码越多就越容易出问题;而且为了保证跨域访问被对允许,必须发送标准的请求头.

Dojo目前就是以XHR为基础然后使用eval来加载模块的,针对跨域使用xdomain来处理,所以XHR加上eval是可以用来加载模块的,只是这样对开发者来说负担太大了.

如果我们想创建一个模块加载器的话,其实我们可以做的更好的

Web Worker 加载脚本

web worker 有可能是加载JS模块的另一种方法, 但是:

  • 不能跨浏览器
  • web worker是以消息机制来通讯的,在worker线程内的JS是不能访问DOM的,所以只能通过eval或者script标签来解析内容,这样的话就会出现上面XHR方式带来的问题

Document.write 加载脚本

document.write能够用来加载脚本,因为它支持跨域,而且能够正常的显示脚本,方便调试

不过它不能立即执行,虽然理想情况下能保证依赖全部加载,但是只能在脚本执行完之后才能访问到里面的JS代码

而且document.write在页面加载完成之后就不会再执行,这样就不能实现按需加载,通常只在用户需要某个功能的时候再加载JS是能够有效的提高网站性能

Head.appendChild 加载脚本

先看下面的代码片段:

var script = document.createElement('script');
script.src = 'feenan.js';

document.getElementsByTagName('head')[0].appendChild(script);

head.appendChild相比于上面的方式来说有一点复杂,不过这只是基本的想法,跟document.write相比,它不会阻塞页面渲染而且页面加载完之后还能继续调用

不过也有一个致命的问题,跟同步相比不能立马执行完,理想的情况是,模块加载有保证所有的依赖在执行脚本之前就加载完毕.

函数包装

了解了上面的几种方案,都有几个相同的问题,所以我们需要自己构建模块加载,处理依赖关系,像下面这样的:

defind(
    // 模块名称
    'feenan',
    // 模块依赖
    ['zepto'], 
    // 传递依赖参数
    function($){
        return {
            init: function(){
                console.log('hello feenan!');
            }
        }
    }
);

上面的是requirejs的语法,假如只是想请求简单的JS文件,可以像下面这样写,不需要define关键字.

require(['zepto'], function($){
    // 此处就可以调用zepto的方法了,$只是别名
})

选择这种语法是因为这比较简单,并且允许使用像head.appendChild那样来加载JS

浏览器端的commonJS跟上面不一样的是,需要额外对现有的代码包装一层,这个会影响调试

想了解更多的关于AMD规范的模块机制,可以参考这篇文章,why AMD 有空再来篇中文版的!


  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值