都已经2017年的11月份了，我们项目还打算用seajs？！没错，上周我们公司的一个项目启动了，开会的时候CTO要求用seajs + artTemplate的组合套餐来开发。在下来研究过后，我深觉此举不妙，遂和我们的CTO进行了第二轮沟通，最终选定了vuejs + webpack 的模块化开放模式。虽然是工作中的一件小事，但还是给我留下了不小的感悟。
故事背景交代完毕，接下来，正文开始～
记得前年（2015年）杭州D-DAY玉伯说过，能够亲眼看到seajs死掉也是一种幸福。一个大而全的前端框架，功能越做越多，迭代难度也会越来越大。其实小而美挺好的。
为此，玉伯当时还特意发了一条微博，说是应该给seajs和kissy也树一块墓碑了。
为什么感觉一直追赶的SeaJS已经死掉了呢？
这里，闰土感觉有句话特别应景，鲜衣木马少年时，怎可死气沉沉如暮年？
“说人话，好吧？！”
“呃......，因为它过时了呗。”
这里，闰土所说的过时，并不是指它现在就不能用了，而是说出现了明显更加先进的理念或者标准，这会导致未来它的使用场景大为减少，整体趋势已经步入衰落。
随着Web相关标准的推进，有很多框架（库）都过时了。比如：
JavaScript新的模块标准导致了SeaJS和RequireJS的过时；
原生选择器的良好支持，导致人们对jQuery不再那么依赖；
Array和Object上面一些新特性的出现，导致underscore和lodash的作用减弱。
与此同时，一些专注于做shim或者polyfill的库反倒会比较时髦，因为它们的定位非常明确：扶上马，送一程（哈哈，这是一句玩笑话，不可当真）。
然后，像Angular，Backbone，Knockout，这一大票东西，除非革自己的命，否则全部过时了（当然，angular1已经革了自己的命，大版本的API迭代，完成了ng2的救赎）。再来看看Kissy，这也是一个时代的产物，在同一个时期，有很多类似YUI或者jQuery UI的东西，然而，它们都衰落了，不再适应新的时代。
我们将来不需要用那样的方式编写前端框架，不需要用那样的方式编写界面组件，永远不要停下自己的脚步。中堂大人教导我们：一代人做一代人的事情。上一代前端框架/库都已经基本完成使命了，让我们默默记住并怀念它们。
什么，你不知道中堂大人的梗？好吧，那我来告诉你，算盘打得再精，也不如中堂大人，中堂大人已经把他们的所作所为了如指掌......（好吧，话题扯远了）。
当然，花开两朵，各表一枝（一听这话，想必你们都能猜到，剧情要反转了）。再次强调，过时、衰落，都代表着下降趋势，而不是说你现在就不能用了，仍然会有合适的场景，比如你要支持ie6之类，在你的场景没有与时俱进之前，技术选型也是不能与时俱进的。
俗话说，做人留一线，日后好相见。这回闰土的话说的够圆滑了吧，抨击seajs不能太绝，凡事都是相对的。在编程界没有绝对的事情，如果有，那就是抨击的还不够（呃，好吧，足见闰土老油条的功底）。
其实， RequireJS 也好，Sea.js 也好，CommonJS、AMD 还是 CMD 也好，在当年的产生和流行，都不是为了推框架，目的都是为了模块化开发。现在 ES2015（俗称ES6） 规范已出，JS 模块已经得到标准化，早先的模块化方案的没落，和 webpack 与 babel 等转换工具的火爆，都是大势所趋。吾等螳臂挡车，并没有什么卵用。
看到这里，知道前端圈的技术更迭是有多厉害了吧，那些一味鄙视前端技术含量不高的人人们，我只想送你们一句话，In this era, you will be abandoned。（不用百度翻译了，意思就是在这个时代，你会被抛弃。噗嗤～）
如果你身边还有鄙视前端技术含量低的人，建议你将这篇小文怼到他脸上（开玩笑的老铁，快把手里的板砖放下～）。
说了那么多，让我们来映射一下主旨：
前端造那么多东西，最终还是为产品服务，那么多人爱造轮子是个好事，对于小公司里的年轻人来说，造轮子是能力的锻炼。
但是从坏的一方面来讲，就会导致产品需要不断的迭代更新，迭代就会带来更多的维护成本，这样的话，一个产品的开发周期相当于被无限拉长，只要技术一发生更新，项目就得重构。
接着又从好的一方面来看，不断的重构会让前端岗位一直处于供需平衡状态，为了你不会下岗，就让他们造轮子的人折腾去吧。反正都是js，怎么折腾都逃不出前端工程师的手掌心。
后记最后，还是那句话：闻道有先后，术业有专攻。在从事前端的道路上，you are not alone.
随时随地看视频
