写在前面

因为zepto、jQuery2.x.x和Nuclear都是为现代浏览器而出现,不兼容IE8,适合现代浏览器的web开发或者移动web/hybrid开发。每个框架类库被大量用户大规模使用都说明其戳中了开发者的刚需。本文将对比zepto/jQuery到Nuclear的设计和演化的过程。

无框架时代

互联网的春风刚刮来的时候,人们当时利用三剑客制作网页。

这里会发现showMsg必须是全局的,onclick触发才能访问,这样就会导致每绑一个事件就要污染一个全局变量。这点问题难不倒前端工程师,加个超级namespace,所有的事件挂在它下面:

但是也有问题,比如这样的场景:

或者更真实一点:

在定时器没执行完成或者AJAX没有success之前,用户的所有交互都会报:

然后,善于记录分析总结思考提炼的工程师们拿出本子记录下最佳实践:

  • 不建议在dom元素上直接声明事件绑定调用
  • 声明式事件绑定所调用的方法必定要污染全局某个变量
  • 声明式事件绑定的相关js未执行完的情况下发生人机交互会报脚本错误,且严重影响用户体验
  • 建议在js中先查找dom、再给dom绑定事件

想象一下:一个按钮5秒后才绑的事件,用户前4秒内一直点都没反应,然后5秒到了,但是用户已经放弃该网页了。

util库时代

开发者们按照上面总结的最佳实践,重构了上面的代码:

这给开发者们带来了另外一个麻烦的问题,以前声明式直接在div上绑定事件不需要查找dom,所以不需要标记id,现在每个需要绑定事件的dom都需要标记id用于js查找。而且,这种写法依旧没有改变声明式事件绑定的一个问题:

  • js未执行完的情况下发生人机交互【虽然不会报脚本错误】,但是严重影响用户体验

比如你div是个按钮形态,看上去用户就想点,一直点一直点。但是js还没执行完,事件还没绑定上去。用户将收不到任何反馈。
但是开发者并不关系这‘毫秒’、甚至‘秒’级别的用户体验,也有的开发者利用UI逻辑去规避,比如先来个loading?比如绑定完事件再显示该dom。
就这样,这个问题就这么不了了之~~~~。随之而来的是:
查找dom好累,封个类库:

绑定事件好累,封个类库(edwards的events.js):

再然后,开发者们觉得引用这么多工具库好累…

zepto/jQuery时代

开发者们觉得引用这么多工具库,而且他们其实都隶属于同一类东西(查找dom、dom绑定事件都是操作dom)可以糅合一起。就有了后来风靡全球的jQuery和zepto在web里实现人机交互:

开发者的刚需就是:找到dom、绑定事件、写逻辑。而且,上面的程序还不会丢失语义,一看就知道想干什么。但是:

  • js未执行完的情况下发生人机交互【虽然不会报脚本错误】,但是严重影响用户体验

开发者们被各种爽到之后,这个问题已经被抛到了九霄云外。那我们就继续往下看,看到哪个阶段把上面这个问题解决了?!

AngularJS

因为AngularJS通过ng-click绑定事件,所以没有解决。

React

因为React的布局和逻辑放在一起,解决了跨越了十多年之久的前端问题:

  • js未执行完的情况下发生人机交互【虽然不会报脚本错误】,但是严重影响用户体验

通过把相关的布局和逻辑放在同一个组件中,整个系统变得整洁清晰了。 我们为这个重要的洞见向 React 致敬。(引用于riot)

React的核心根本不是什么UI=fn(state);不用React也可以UI=fn(state)。

Nuclear

理念:some HTML + scoped CSS + JS === Reusable Component
Nuclear的网站在这里: http://alloyteam.github.io/Nuclear/ 里面有大量的介绍。

通过下面的使用方式:

会在html里生成如下的结构:

更为具体的对应可以看这张图片:

组件化编程

  • 组件html结构、css和js必须在一起,要么都加载,要么都不加载。
  • 只加载其中一部分都是浪费如css加载了,组件没用到js加载了,浪费带宽
  • 带来不好的体验,如组件js加载完了,css却没加载完成,导致用户看到错乱的页面
  • 脚本错误和糟糕体验,如组件HTML和css加载完了,js却没加载完成,导致用户交互无响应

Nuclear编程

  • 组件化编程
  • 超小的体积,5k
  • 支持任意模板引擎
  • 双向绑定改善编程体验
  • 面向对象编程
  • 支持局部CSS

回到最初的问题:

  • 不建议在dom元素上直接声明事件绑定调用(Nuclear建议事件直接绑在dom上)
  • 声明式事件绑定所调用的方法必定要污染全局某个变量(只污染了Nuclear)
  • 声明式事件绑定的相关js未执行完的情况下发生人机交互会报脚本错误,且严重影响用户体验(组件化编程,组件的html、css和js是一个整体)
  • 建议在js中先查找dom、再给dom绑定事件(Nuclear建议事件直接绑在dom上,查找dom的需要可以标记nc-id或者nc-class)

总之:使用Nuclear组件化编程,使组件的HTML、CSS和JS同时一起生效可以规避许多问题。

Github: https://github.com/AlloyTeam/Nuclear

感谢阅读~~

原创文章转载请注明:

转载自AlloyTeam:http://www.alloyteam.com/2016/04/zepto-jquery-angularjs-react-and-nuclear-evolution/

  1. 小易分享网 2016 年 8 月 18 日

    这个文章写的好,转走了! http://www.xevip.cn

  2. 风爻 2016 年 7 月 19 日

    对类React思路的前端框架都很有好感,然而痛点其实也有的,第一个问题是SEO,还要中间引入一个渲染层,架构上麻烦;第二个问题是简洁程度,时间久了,糟糕的React代码,其实也就是呵呵,开发人员写html的时代已经过去很久了,jade基本算是标准,之前也看到有尝试把React和Jade整合在一起的项目,不稳定、性能问题,都是事,整体乐观,但还有很长的路要走。嗯,尝试后保持观望,总结:其实也不用那么着急着否定这个世界

    • HD 2016 年 7 月 19 日

      SEO可以通过server rendering解决的。React本身对JS的扩展已经会遇到困难,而和Jade共用就更困难了

  3. slowly 2016 年 5 月 10 日

    鼓励创新和思考解决业务问题的意识,但不要陷入轮子的围城中……

  4. 淡墨青衫 2016 年 5 月 9 日

    Nuclear是为了解决什么问题呢,相对于React、Vue有哪些优势?

  5. 张宇 2016 年 5 月 5 日

    react同样重视的是开发者的体验,每一行都加反斜线也是醉了

  6. meepo 2016 年 5 月 3 日

    在JS中编写HTML代码的体验感觉很差,每一行需要加反斜杠或者引号,没有语法高亮,也用不了zencoding。

  7. 杨立ming__KK 2016 年 4 月 29 日

    vuejs感觉是目前组件化编程体验最好的了,

  8. 亚里士朱徳 2016 年 4 月 29 日

    这样都通过js来加载组件的话,这样增加浏览器的重排和重绘会不会带来性能问题?

    • TAT.dnt

      TAT.dnt 2016 年 4 月 29 日

      按需加载组件渲染样式对现代浏览器来说不是问题。待后续的nuclear性能评测数据。还有就是完全可以通过构建按css、js打包提前加载或者按组件打包按需加载,这些都不是问题。

      • 亚里士朱徳 2016 年 4 月 29 日

        PC端可能说得通,考虑过移动端尤其是低端安卓机么?

        • 亚里士朱徳 2016 年 4 月 29 日

          webpack为什么不写进来呢?

          • TAT.dnt

            TAT.dnt 2016 年 4 月 30 日

            webpack算是构建工具,可以和nuclear一起使用。对了,忘了说了。切断observejs双向绑定性能可以翻倍。比如最新的测试:http://alloyteam.github.io/Nuclear/pt/

        • TAT.dnt

          TAT.dnt 2016 年 4 月 30 日

          但是基于html的组件化应用编程和游戏编程不一样,帧率不用60fps。低帧率按需更新用户根本不会觉得卡顿。对了,忘了说了。切断observejs双向绑定性能可以翻倍,超大的list可以考虑不用双向绑定。比如最新的测试:http://alloyteam.github.io/Nuclear/pt/

  9. 戴文奇 2016 年 4 月 28 日

    如果 父组件和子组件 都是异步拉数据渲染出来的。父组件需要在子组件渲染ok后立马做些处理 。用这个框架怎么处理?。。。

    • TAT.dnt

      TAT.dnt 2016 年 4 月 29 日

      最终目的都是要构造一个或两个option,拉取完两条数据再构造就行。子组件的option在父组件install时候传递或者重新构造。

  10. 刘sir 2016 年 4 月 27 日

    适合自己就是好的!

  11. 当当 2016 年 4 月 27 日

    这是KPI压力下的产物吗

  12. 王道中强流 2016 年 4 月 27 日

    感觉不怎么人性化呢~this.option.items.push(this.textBox.value)看到这一句我的第一观感是:这哪来的option,又是哪来的items,然后又是哪来的textBox……看完各种箭头后,才明白。不像我看到Vue.js的时候,第一眼就望穿秋水,清澈透亮。也许这项目有它的优点,但是按照目前这种使用方式,恐怕流行不起来。

发表评论