We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
俗话说一叶知秋,如果说快速发展的前端有个主线串点成线,个人觉得是模块化的发展,因为模块所具备的特性,决定了其组织结构的可能性,以及人与人的合作模式。我们可以藉由模块化的发展,来了解前端的变化
早期 js 被作为脚本语言,协助表单校验等界面辅助增强,那时候前端也简单,不需要模块化
后来利用命名空间做代码拆分
YAHOO.util.Event.stopPropagation(p_oEvent); // YUI2
比如这个时期 YUI3, 这里出现了清晰的模块定义,和通过闭包来做模块运行空间
// 定义模块 YUI.add('hello', function(Y) { Y.sayHello = function() { Y.DOM.set(el, 'innerHTML', 'hello!'); } }, '1.0.0', requires: ['dom']); ... // 使用模块 YUI().use('hello', function(Y) { Y.sayHello('entry'); // <div id="entry">hello!</div> })
感觉已经很久之前了,但其实也才 14年左右,前端的模块化已经有了一些规范, CMD (延迟执行)、AMD (提前执行)、CommonJS(当时主要是服务端模块化) 模块规范以及基于模块做工程化的讨论非常激烈,是个百家争鸣的时代
那时 seajs 比较火,写法是这样
// 通过 define 来定义定义模块 define(function(require, exports, module) { // 通过 require 引入依赖 var $ = require('jquery'); var Spinning = require('./spinning'); // 通过 exports 对外提供接口 exports.doSomething = ... // 或者通过 module.exports 提供整个接口 module.exports = ... });
// 使用模块 seajs.config({ base: "../sea-modules/", alias: { "jquery": "jquery/jquery/1.10.1/jquery.js" } }) // 加载入口模块 seajs.use("../static/hello/src/main")
那时的源服务也是需要自己处理,比如 spm 的发展,远没有今天的成熟,都是摸着石头过河,那时的前端圈子讨论问题态度非常认真,问答质量也非常之高。
后来随着发展, AMD、CMD 的浏览器端模块规范都逐渐淡化,以及构建环节的兴起,COMMONJS 模块规范 和 npmjs 作为源的体系逐渐壮大,形成如今的前端模块体系。
真的是分久必合,在 NPM 这个时期,前端模块 和 Nodejs 模块都收入 NPM 包管理,npm 包的 package.json 对模块的描述能力,以及安装卸载方式,增强了模块的控制和表述能力。前端和nodeJS,模块的处理,都融合在一起,兼具数量和多样性,爆发出很多活力,新的设计和想法层出不穷,并迅速传播。 因为是编译前置,因此写法上简单很多。
require("module"); require("../file.js"); module.exports ={ handle};
Webpack 作为如今前端打包的事实标准方案,提出了一切皆模块的思想,使得 CSS、HTML、JS 都能转化为相同的模块进行处理,结合 NPM 体系 使得前端模块管理日趋成熟. 也正是 Webpack的灵活,才在处理js版本,css、js 写法兼容等方面有很大帮助。
基于模块的发展和演化,未来可能会在几个方面有空间
The text was updated successfully, but these errors were encountered:
No branches or pull requests
无模块化
早期 js 被作为脚本语言,协助表单校验等界面辅助增强,那时候前端也简单,不需要模块化
基本的名字划分
后来利用命名空间做代码拆分
基本的模块化
比如这个时期 YUI3, 这里出现了清晰的模块定义,和通过闭包来做模块运行空间
CMD、AMD 和 Seajs
感觉已经很久之前了,但其实也才 14年左右,前端的模块化已经有了一些规范, CMD (延迟执行)、AMD (提前执行)、CommonJS(当时主要是服务端模块化) 模块规范以及基于模块做工程化的讨论非常激烈,是个百家争鸣的时代
那时 seajs 比较火,写法是这样
那时的源服务也是需要自己处理,比如 spm 的发展,远没有今天的成熟,都是摸着石头过河,那时的前端圈子讨论问题态度非常认真,问答质量也非常之高。
后来随着发展, AMD、CMD 的浏览器端模块规范都逐渐淡化,以及构建环节的兴起,COMMONJS 模块规范 和 npmjs 作为源的体系逐渐壮大,形成如今的前端模块体系。
NPM 时期
真的是分久必合,在 NPM 这个时期,前端模块 和 Nodejs 模块都收入 NPM 包管理,npm 包的 package.json 对模块的描述能力,以及安装卸载方式,增强了模块的控制和表述能力。前端和nodeJS,模块的处理,都融合在一起,兼具数量和多样性,爆发出很多活力,新的设计和想法层出不穷,并迅速传播。
因为是编译前置,因此写法上简单很多。
Webpack
Webpack 作为如今前端打包的事实标准方案,提出了一切皆模块的思想,使得 CSS、HTML、JS 都能转化为相同的模块进行处理,结合 NPM 体系 使得前端模块管理日趋成熟. 也正是 Webpack的灵活,才在处理js版本,css、js 写法兼容等方面有很大帮助。
未来趋势猜想
基于模块的发展和演化,未来可能会在几个方面有空间
参考
The text was updated successfully, but these errors were encountered: