雨夜带刀's Blog

谈谈 external 模式的打包

模块化在前端日新月异的工程化工具的推动下已经摆脱了前端模块加载器(SeaJS、RequireJS)的束缚,现在通常的方案是使用 browserify 或 webpack 来将模块化的文件打包,然后直接在浏览器端使用。

但是通常的打包策略是将整个项目打包成一个文件 bundle.js,默认情况下 bundle.js 中囊括了所有的依赖,包括第三方的从 node_modules 中加载的文件,这会造成 bundle.js 非常臃肿,而且在生产环境中不能很好的利用静态资源的缓存策略。这些打包技术在国外非常火,生产环境提供一个 bundle.js 的做法在国外的网络环境下毫无压力,但是国内的网络环境和国外的没法比,为了下载的性能还是建议分开打包。

分开打包还有一个好处就是,目前的前端开发环境现在都流行使用监测文件的变化而使用 livereload 技术,这也意味着会存在实时动态打包的需求,分开打包对于实时打包的速度有质的影响,对于基本不会变化的第三方模块没有必要每次做实时动态打包的时候都包含进去。

Immutable 在 JavaScript 中的应用

Mutable 对象

在 JavaScript 中,对象是引用类型的数据,其优点在于频繁的修改对象时都是在原对象的基础上修改,并不需要重新创建,这样可以有效的利用内存,不会造成内存空间的浪费,对象的这种特性可以称之为 Mutable,中文的字面意思是「可变」。

对于 Mutable 的对象,其灵活多变的优点有时可能会成为其缺点,越是灵活多变的数据越是不好控制,对于一个复杂结构的对象来说,一不小心就在某个不经意间修改了数据,假如该对象又在多个作用域中用到,此时很难预见到数据是否改变以及何时改变的。

var obj = { /* 一个复杂结构的对象 */ };

doSomething(obj);
// 上面的函数之行完后,此时的 obj 还是最初的那个 obj 吗?

针对这种问题,常规的解决办法可以通过将对象进行深拷贝的形式复制出一个新的对象,再在新对象上做修改的操作,这样能确保数据的可控性,但是频繁的复制会造成内存空间的大量浪费。

var obj = { /* 一个复杂结构的对象 */ };

// copy 出一个新的 obj2
// 但是 copy 操作会浪费内存空间
var obj2 = deepClone(obj);

doSomething(obj2);
// 上面的函数之行完后,无论 obj2 是否变化,obj 肯定还是原来那个 obj
头像

雨夜带刀

前端开发工程师,技术宅,现居北京。

雨夜带刀的开源项目

easy.js
一个简洁的 JavaScript 类库,集成了模块加载器,同时也有包含了常见的的组件库,可访问项目网站
seed
符合 AMD 规范的 JavaScript 模块加载器。
ecope
从 easy.js 组件库中移值过来的基于 jQuery 的组件库,简单实用,API 风格统一。