Js开发在整个行业的现状主要的有两点
维护成本高
多人协作项目的困境
Js项目维护成本过高
经历过10年的ie统治时期的浏览器世界一成不变,和06年开始ajax的兴起带动垂死的javascript的复兴,浏览器市场也开始翻天覆地的快速变化,排版引擎和js脚本引擎开始得到不断的优化,js的执行效率不断的得到提高,但是………..
我们的js一直没变过. 现在所有的主流 Web 浏览器都遵守 ECMA-262 第三版,即实现的是JavaScript 1.5版 时间 2000
那么,js依然是当年的js,浏览器和对web的需求早已经不复当年。当年那个为做表单验证而生的js语言,如今承担的是复杂的界面ui和交互处理,以前只需要写十几行或者几十行的js现在需要面对几千上w行的需求。
那么带来的问题就是十年来js语言特有的随意性导致的各路js程序员的js风格各异。
Js的弱类型特性导致项目中经常会出现jser的各种奇技淫巧。
上面的两问题直接导致的是js程序交接维护上的困难。面对js风格清晰易懂的jser的代码还好,如果接手js风格怪异太个性的jser的代码,并且如果还没有注释,那么,看代码真心会看到你吐血
编写规范的随意性 ,编写风格的个性化,是js项目维护成本的很大一部分原因
多人协作项目的困境
其实看过前面的内容,我们大抵的了解到,js是应很简单的需求而生的,甚至简单到是用来做简单的表单验证的。也就是说,js代码,在很长一段时间内,都是由一个开发独立完成的,多人协作上会出现的问题
1,全局变量命名混乱冲突导致系统错误
2,代码集中少量文件导致开发效率降低
3,容易出现功能重复开发
Js开发编写方式的演进
函数:js作为函数式语言与生带来的特性,jser们通过在window下注册一个又一个的function相互调用来完成产品们的需求(全局变量命名极为混乱和不规范)
类:jser为大型js项目开发的尝试, 2006年,Ajax兴起。JavaScript绝地重生,越来越多的后端逻辑放到了前端。网页中的JS代码量急剧增加。这时写函数方式组织大量代码显得力不从心。有时调试一个小功能,从一个函数可能会跳到第N个函数去。这时jser们前仆后继,进行各样尝试,类出现了,Prototype率先流行开来。用它组织代码,用js的灵活性模拟类的编程,每个类都是Class.create创建的。又有YUI、Ext等重量级框架。虽然它们的 创建类方式各不同,但它们的设计终极目标却都是要满足大量JavaScript代码的开发而努力
类开发尝试的转折-------这是一个战火纷飞的年带,各路框架豪杰不断涌现,jq的诞生带来了js开发的又一次变革,jq所至,其他框架寸草不生,同时也直接导致 prototype 等“类”的尝试又化为乌有,很大一帮jser转投jq尤其是js新手直接着手jq者,在享受了jq在小型页面dom操作的遍历之后,大型js项目的多人协作和代码组织问题又暴露到了台前,甚至是制约js乃至整个web发展的一个不小的因素
那么,模块化开发——现在,未来?
Commonjs,首先要说下这个。何为commonJS?commonJs可以理解成一个组织,他们中的所有人都致力于提高javascript程序的可移植性以及可交互性。在js模块化开发上做各种的尝试,这种可移植性以及可交互性不仅仅局限于浏览器端,而且也包括了服务器端的javascript, CommonJS 提出了一种用于同步或异步动态加载JavaScript代码的API规范,非常简单却很优雅,称之为AMD(Modules/Asynchron , Re足球平台出租quireJS和NodeJS的Nodules已经实现了这个API,而Dojo也将马上完全支持(Dojo1.6)。规范本身非常简单,甚至只包含了一个API:
define([module-name ], [array-of-dependencies?], [module-factory-or-object]);
这个就是差不多的整个amd规范的定义。我们这里主要已requirejs为例做个简单的说明
RequireJS快速入门-模块定义