雨夜带刀's Blog

谈谈 external 模式的打包

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

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

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

前端自动化构建和发布系统的设计(二)

前端自动化构建和发布系统设计(一)中主要介绍了使用 gulp 来构建,本篇将主要介绍发布部分。

URI 的设计规则

先来看一个完整的静态资源的 URI,http://a0.jmstatic.com/5d4f23234a51261e/common.css,这个 URI 由三部分组成,依次为 静态随机资源域名/文件 md5 值/原文件名 。

  • 静态资源域名是随机生成的,这样可以在同一个站点中使用多个静态资源域名;
  • 文件 md5 值是根据文件内容来生成的,这样能确保其唯一性;
  • 原文件名有2个作用,作用1是可以从文件名看出在开发环境中对应的是哪一个文件,作用2下面再说;

前端自动化构建和发布系统的设计(一)

前言

前端的业务逻辑和交互效果越来越复杂,代码量也随之越来越大,伴随着越来越大的代码量而来的还有代码的管理和部署的问题。模块化和预处理框架大行其道,新框架的出现让前端的开发环境越来越高大上了,但是部署到线上就越来越费劲了。在开发环境中模块化会将原本的大型应用分割成很多小模块,但是在上线的时候考虑到这些静态资源对 HTTP 请求数和请求体积的开销,很多小模块都需要合并然后再进行压缩。在 node.js 火起来之前,比较常见的处理工具有 ant,但是 ant 是基于 java 的,对于前端工程师来说使用起来很费劲。

grunt vs gulp

node.js 火起来之后,出现了很多用于处理前端静态资源的优秀模块,还有专门用于前端静态资源构建的框架,如鼎鼎大名的 grunt,但是 grunt 由于其基于配置的设计模式和构建模式基于文件的限制,对于复杂一点的构建逻辑配置起来就会比较繁琐。

头像

雨夜带刀

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

雨夜带刀的开源项目

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