给个摘要比较好。

为什么要说‘即使’，太 tough 了吧

#2 楼 @xlaok 哈哈

#2 楼 @xlaok 这个词语很到位，精准！

可能是我比较挑剔，这里面大部分的例子我看来都是为了写例子而写，既不符合原著 OOP 的风格，也不符合 Javascript 的惯例。看了三分之一，基本看不下去了。

#2 楼 @xlaok 想想“即使，也要”都有歧义，确实不妥，标题已改。

#5 楼 @billy 我也感觉后面关于 OO 那些有点牵强。

前端正处在从原始的 jquery 脚本时代迈向框架时代的大跃进里，许多原来写单页脚本的前端从思维方式上还没有完成这样的转换。

很多习惯了写单页脚本的前端目前缺乏的不是某个代码规范，而是工程化的思维模式。

以前写单页脚本的时候，脚本由单个人维护，不会掺杂一些比较复杂的逻辑，不同页面的脚本之间基本没有什么关联。

在这种情况下，只要能够快速完成开发需求，就足够了。

但是在目前的框架时代，你个人编写的组件是嵌入在整个前端项目里，而不是某个单独的 html 文件。

衍伸出来的问题就是组件和整个框架的联系、组件的复用性和组件之间的相互关联，重前端的情况下更多的业务逻辑和它们之间的耦合会迫使系统复杂复成倍增加。

每一次的改动都要考虑到这次改动和整体之间的关联，即使只是开发部分组件，也需要对整个系统有足够的了解。你一个单独组件里的错误，很可能会使整个应用挂掉。

之前面试过不少前端，发现现在前端确实很难招（当然可能是因为我们公司对好的前端缺乏吸引力）。

大多数问 js 的作用域、this 的指向和原型链的委托机制这些基础的语言特性都答不上来。对于框架，也很少能够有把组件的生命周期讲清楚的。

原来在单页脚本时代，遇到问题，可以随便找个方法绕过去，然后再回到舒适区。可是框架时代这样就不行了，不把整个系统都吃透是不行的。

这个过程是痛苦的，但是是必要的，各个公司也要有耐心给前端时间去完成这样的转变。

这完全不是前端工程师的视角。。。这是 Java 工程师的视角吧。。。 看到那个 swith 用 class extend 就感到又回到深渊了，我都是赚 object。有一部分还是不错的，往后看感觉就回到了设计模式的恶习。可能是立足点不一样吧，总体评价的话就是“感觉完全不前端”。

#8 楼 @adamshen 精辟

前端要把自己搞得走火入魔。