blog
blog copied to clipboard
xufei
［翻译］Angular的问题
［翻译］Angular的问题
在过去半年里，我跟一些潜在客户进行了交谈，他们在寻找前端顾问来帮助开发团队控制Angular项目的时候，遇到了麻烦。
尽管有一些对Angular很热情的前端人员，我有种感觉，对于一个主流框架来说，他们的数量还是太少了。我期望Angular能比之前受到更多关注。
Angular更多地是面向企业的IT部门，而不是前端人员。它独特的编码风格，它那种更倾向服务端而不是浏览器侧的对HTML模板系统的封装形式，以及严重而基础的性能问题吓跑了不少人。
我曾经说过，Angular更多的用户是有Java背景的人员，因为它的编码风格是面向他们的。不幸的是，他们没有被培训以认识到Angular的性能问题。
对于Angular 1.x是否适合现代web开发，我表示怀疑。如果有人持有不太客气的倾向，他会把它描述成一个：非前端人员做给非前端人员用的前端框架。
Angular 2.0被提出了激进的改写，意图使它更符合前端人员的口味，但我怀疑他们所感兴趣的是另外一个MVC框架了。此外，重写有可能会疏远Angular的当前目标受众。
如果你想要知道为什么我有这些想法，恐怕要把这篇长文章看完了。
Angular 服务页面
我感觉到Angular的基本理念在前后端之间模糊不清。看一看这个示例代码吧，这是我拉过来的真实的东西:
<body>
<h2>Todo</h2>
<div ng-controller="TodoController">
<span>{{remaining()}} of {{todos.length}} remaining</span>
[ <a href="" ng-click="archive()">archive</a> ]
<ul class="unstyled">
<li ng-repeat="todo in todos">
<input type="checkbox" ng-model="todo.done">
<span class="done-{{todo.done}}">{{todo.text}}</span>
</li>
</ul>
<form ng-submit="addTodo()">
<input type="text" ng-model="todoText" size="30"
placeholder="add new todo here">
<input class="btn-primary" type="submit" value="add">
</form>
</div>
</body>
这代码让我想起了一个简单的服务端脚本语言，比如JSP或者ASP，它们使用数据库的内容来填充HTML模板。这些语言在web开发栈中有一席之地——但是在服务端，而不是浏览器端。
上个月，我在一个大型的荷兰公司参与了项目，它们庞大的网站使用了各种小部件和设计模式，做相同的事情，但不是来源于通用的代码库，整个网站间充斥复制／粘贴。这显然是个不受欢迎的状况。
他们转向Angular以解决这个问题，包括把所需的部件集中化。虽然模板是正确的解决方案，在浏览器中这么做却是根本错误的。应用程序维护的成本不应转移到所有用户的浏览器（在这里，我们所讨论的是每个月数以百万计的点击）中——尤其它们不是移动浏览器。这个事情是属于服务端的。
严格来说，这不是Angular的问题，而是这个公司使用Angular进行的实现所致。然而，从逻辑上讲，是Angular，在所有JavaScript 框架中，把这个问题更深化了。它的类似JSP的品质，允许了，甚至鼓励了这种行为。
Angular 的目标受众
Angular是面向大型企业的IT后端和经理们的，他们被JavaScipt疯狂扩散的工具们搞迷糊了。在一篇优秀的文章中，Andrew Austin描述了在企业IT中Angular的状况：
对整个团队都属于Google的AngularJS团队，有很多积极的看法。首先，有商业实体控制的框架通常是比较积极的，因为它完全避免了政治派系之间的斗争。在开源世界，这种内讧是公开的，严重的，影响到团队构建伟大软件的目标。
企业IT经理们想要背后有一个大公司良好维护的代码，这样他们不用担心突然就得不到支持了。此外，Google在web技术方面名声较好，所以，如果他们推出一个JavaScript库，那必须是非常好啊……是不是？
企业IT经理也喜欢这么一个事实：Angular对后端开发人员友好。我用Twitter跟weather.com的Joe Pearson进行了讨论，他告诉我，最近转向Angular，主要是为了Java开发人员。Angular所使用的代码构建方式很适合他们，但对他们的前端人员却并非如此。从我客户那里得到的消息，是他们的Java开发人员决定使用Angular。
换句话说，Angular出了吸引经理们，还打动了Java开发人员。框架与恰当的应用程序结构概念相结合，一切都不是意外。Google的目标是征服企业市场，Angular是它的工具之一。
另一方面，很多前端人员，在JavaScript和浏览器上面花了很多年，已经拥有了自己的编码风格，倾向于对Angular表示怀疑。
这本身不是个问题：人们应当使用适合自己编码风格的框架。不幸的是，Angular的问题太深了。
性能问题
再看一眼Angular的示例代码吧：
<body>
<h2>Todo</h2>
<div ng-controller="TodoController">
<span>{{remaining()}} of {{todos.length}} remaining</span>
[ <a href="" ng-click="archive()">archive</a> ]
<ul class="unstyled">
<li ng-repeat="todo in todos">
<input type="checkbox" ng-model="todo.done">
<span class="done-{{todo.done}}">{{todo.text}}</span>
</li>
</ul>
<form ng-submit="addTodo()">
<input type="text" ng-model="todoText" size="30"
placeholder="add new todo here">
<input class="btn-primary" type="submit" value="add">
</form>
</div>
</body>
在{{}}中的所有代码段都是Angular语句。问题在于，Angular无法发现这些语句，除非解析整个DOM，包括文本阶段和属性值——这过程的开销太大了，特别在移动端。
虽然对于整体性能而言，这不一定是致命的问题，解析整个DOM所花费的时间是需要作为一个问题被指出的。不幸的是，这种性能似乎被Angular所代表的整体所忽略了。
Filament Group的测试报告对Angular来说，不太乐观。尽管作者非常小心地提到，对一个大型、复杂的应用做测试，结果可能更积极些，他们的简单测试应用的Angular版本表现并不好。Ember的也不好，只有Backbone脱颖而出。
Steven Czerwinksi提供了有趣的细节：
每次更新都花费了一段较长时间来创建和销毁DOM元素。如果新视图有不同的行数，或者任何一行的单词数量不同，Angular的ng-repeat指令都会整体创建或销毁DOM元素。这个开销很大。
尽管这篇文章展示了如何简单地解决这个问题，我担心的是，Angular默认的就是这种性能低下的模式。前端框架默认应当使用前端建立的最佳实践。但Angular没有。
即使是Google，似乎也同意它有问题了。在对Angular的批评中，最能让我感到共鸣的文章是来自Daniel Steigerwald 写的Angular.js有什么问题的：
Google不把Angular用在自己的标志产品比如Gmail或Gplus上。
哎，你要吃你自己的狗粮哎。
对于一个普通水平的，只拥有少量前端知识的后端人员来说，这些问题是看不到的。这个框架如它宣传的那样运作，它来自一个在前端技术领域拥有声望的公司，所以，普通水平的后端人员就会默认：这就是前端世界的做事方式。
Angular的方式
对很多前端人员而言，最大的问题是，Angular强迫自己用一种指定的方式去干活。Software Improvement Group发布了一份报告指出（我的强调）：
使用AngularJS给开发人员提供了一堆好处。……这些好处为AngularJS的流行作出了贡献，当遵守AngularJS的约定时，生产力会更高。
这份报告把这个问题当作了优点，而不是缺点。在一份自认为带个人倾向的JS框架纲要中，Henrik Joreteg的观念就比较负面了：
选择Angular意味着你学习的是如何用Angular这个框架，而不是用JavaScript来解决问题。……我有些开发人员，他们的主要技能是Angular，而不是JavaScript。
因为有必要学习使用Angular的方式去处理事情，这个框架的学习曲线很陡峭。Ben Nadel，一个Angular爱好者，而不是一个反对者，把这个事情可视化了：
换句话说，Angular需要你花很多时间来学习如何使用Angular的方式来做事，有些人会喜欢这样，但另外一些会视之为一种额外负担，对其敬而远之。
哪里不对
这些为什么是问题呢？Angular哪里不对呢？Rob Eisenberg 给出了一个解释：
差不多五年前，当AngularJS刚创建出来的时候，它并不是给开发人员用的。它是一个工具，更倾向于给需要快速创建持久化HTML表单的设计人员用。随着时间推移，它作了改变以适应各种场景，开发人员也用它建造更多、更复杂的应用程序。
关于Angular历史的更多东西，参见Hacker News这个帖子。
我不认为，一个快速原型工具应当被用于复杂的，企业级的生产代码上。
这还没完。同一篇文章中给了另一个担忧的原因：
虽然Angular可以被用于创建移动应用，但它的理念并非为它们设计的。这包括了所有的东西，从我刚提到过的基本的性能问题，到它的路由的能力缺失，以及不能缓存预编译视图，甚至是过于普通的触摸支持。
这个只有5岁大的框架没有为移动端做有效优化，很不可理喻。回到2010年，移动也不是个问题。
不过，我们应该看的不是2010，而是2012年。我记得最早，Google开始推广Angular是2012年中。（这个日期有2012年6月的这篇文章为证，我觉得这可能是最早提到Angular的一篇了）。
在那个时候，Android对Google的未来至关重要，这事已经很明朗了，所以你在推的这个工具要支持你未来的平台，这很重要……是不是？
我想知道，当推出这么一个框架，初衷不是帮助开发人员，包含严重DOM性能问题，未对自家移动平台作优化，这个时候，Google到底在想什么。
Right hand, meet left hand.
Angular与前端
别误会：有些前端人员是热衷于的，也存在模块仓库和最佳实践的站点。
我的观点是，我期望有更多前端人员拥抱Angular。我有种感觉，它们的数量少得吓人——看看我的客户们的那些问题，他们找个好的Angular前端顾问有多么难。怎么会这样的呢？
部分的答案是：可能因为Angular设计得更迎合Java开发人员的口味，而不是JavaScript开发人员。这使得前端人员不易接受。不过，编码风格并不是绑死语言的，所以这不是完整的答案。
更重要的原因可能是JavaScript社区的拖后腿。Angular引发了一些严重指责。Alexey Migutsky总结得最好：
Angular.js对大多数项目来说“够好”了，但对于专业Web应用开发（长期维护，在所有现代浏览器上性能可靠，有平滑的UX，对移动设备友好）来说，还是不够好。
我认为他是有发言权的。我在本文中所总结的长篇控诉，特别是性能问题，让我怀疑Angular 1.x能不能适合现代前端工程。Angular要么是一个非前端人员创建的，给非前端人员用的框架，要么是把自己的前端特征藏得太好了。
这也就是为什么我认为在本文的开始引用过的Andrew Austin，当他这么陈述的时候错了：
对一个组织来说，相比雇用jQuery开发人员，雇用AngularJS开发人员可能更难。……但是不要担心，日子一天一天过，越来越多的JavaScript开发人员会发现AngularJS的，他们会用它来创建真正的应用。……相比于雇用有AngularJS经验的开发人员，培训已有的团队，或者雇用那些对学习AngularJS有兴趣的JavaScript多面手会更加容易些。
对于一个前端人员，习惯于用特定方式来做事，迁移到Angular的方式可能比较痛苦。此外，他们反对Angular所导致的性能问题。Angular对前端的敏感点迎合得不够，所以很多前端倾向于无视它。
后端们就没这么麻烦了。他们没有先入为主的前端代码应当如何写的概念，不经过培训的话，也认识不到Angular的性能问题。
我的荷兰客户提到一个事情，加剧了这个问题：一般来说，前端开发者不喜欢企业级应用（企业IT流程，无尽的会议，为了解决简单的问题花很多周，这些的简称），因为它被视为无聊。这导致了前端Angular开发者和顾问更少了。
这也就是为什么多数Angular开发人员来自后端，特别是Java。据我所知，一个前端框架主要由非前端开发者来支撑的情况是独此一家的。
Angular 2.0
对于提到的这些抱怨和问题的总结，Angular团队并未装聋作哑。在10月的时候，他们宣布了Angular 2.0，这是对1.x的完全背离。为了能上新版本，Angular用户将不得不重新编写网站代码。
为什么需要这么激进的变更呢，很容易理解。为了给Angular一个重大性能提升，需要抛弃启动时候解析{{}}DOM的开销。为了这么做，语法必须改变，这会对开发过程造成严重后果。我想说，Angular 2.0需要开发人员在HTML模板中嵌入更少的应用逻辑，更多地放在脚本中。
我认为，这种激进的重写基本是瞄准前端人员的，他们将获得更好的性能，更符合自己对JavaScript框架预期的语法。
然而，这带来最大的代价就是会疏远最大的用户群体。企业IT选择Angular，期望能幸免于这样突然，关键的变化。采用Angular2.0会需要他们重新分配预算来重写已经在运行的代码。此外，我想知道有Java背景的人怎样看待新代码风格。
基于这些原因，我认为很多企业用户会坚守1.x，无视2.0。当然，Google最终会停止支持1.x的。因此，我认为Google想要使用Angular打破企业级前端的堡垒，在最近两三年内还是不会成功的。
虽然企业IT的背叛可以被前端人员的青睐所抵消，但Angular从此在他们心中印象就不好了。此外，前端界现在也不需要另外一个MVC框架。
尽管有严重的技术问题，Angular 1.x还是一个较大的成功，尤其是在拥有Java背景的企业开发人员中。2.0的重写是瞄准前端开发人员的，但不会对他们有太多好处，反而会失去一些当前的拥趸。我不认为Angular的新版能生存下去。
早上看到阮一峰老师转发了这篇文章，中午手痒翻译了一份。
认真地说，这篇文章的很多观点我还是很赞同的，而且令人印象深刻，比如说：
Angular更多地是面向企业的IT部门，而不是前端人员。 非前端人员做给非前端人员用的前端框架。 Angular更多的用户是有Java背景的人员。 Angular是面向大型企业的IT后端和经理们的。 对很多前端人员而言，最大的问题是，Angular强迫自己用一种指定的方式去干活。 当遵守AngularJS的约定时，生产力会更高。 对于一个前端人员，习惯于用特定方式来做事，迁移到Angular的方式可能比较痛苦。
整个文章比较深刻，该说的东西都说到了，但我还是有一些话要说。
首先，他把Angular想要面对的领域搞错了。我想要先问几个问题：
- 有没有适应所有场景的前端框架？
- 目前的世界上，有经验的Java开发人员更充裕，还是前端更充裕？
- 为什么多数Java开发人员害怕写JS？
我自己来回答吧。
- 在任何领域都不存在通用方案，所谓通用，也就意味着对某些特定场景缺乏关照。Angular的出现，并非是为了跟jQuery竞争，而是为了迎合企业应用领域，以及一些管控类项目的场景。这些场景有它的特殊性，对他们来说，模型层的复杂度高于普通网站，之前那种混杂DOM操作和业务逻辑的代码更不易管控，从前端开发者的角度是不太容易意识到这些问题的，他不知道在这类场景下，谈论某种库或者某个框架都没有意义，只有整体的一揽子解决方案才有意义。刚才这个文中所提到的移动端的考虑，更是太强人所难，到现在为止，哪个框架敢说自己成功解决了在PC版的Web和移动版之间的良好通用性？Vanilla？
- 我在南京，在这里，能把Java写得规整，像模像样的码农至少几万个，前端写得同样规整有经验的，至少差两个数量级。这种情况下怎么办，不充分利用已有资源，坐着等天上掉馅饼吗？所以在现在这个阶段，必然有很大一部分Java开发人员要去写JS。
- 多数Java开发人员为什么害怕写JS？原因很简单，他并不怕写纯逻辑，而是怕写DOM操作代码。这些东西对他来说很烦闷，而且JS代码太过缺乏约束，也让他很无所适从。之前很多企业软件使用ExtJS这样的框架，用写Java的方式来写Web前端，这种开发人员严格来说还是算Java开发人员，不能算前端。
ExtJS为什么能被这些人接受，是因为它避免了对DOM的直接操作，所有东西都转化为逻辑了，同理，如果一个框架能避免他们接触DOM，但是又比ExtJS优点多，为什么不用呢？与ExtJS相比，Angular是不是离前端更近点？
所以我认为，Angular的存在，基本上不是抢jQuery的饭碗，而是要抢ExtJS的。回忆一下用ExtJS时候遇到的问题，界面部分的代码繁杂，UI人员基本没法参与，现在换成Angular，是不是好得多了，只要认真封装几个控件，万事大吉。至于说性能，难道ExtJS的性能很好吗？
如果要让Java人员参与前端开发，必须处理好几个问题：
- 制定严格的代码规范，宁可死板，绝不宽松
- 从架构层面把各种问题摆平，切分任务为小块，每个人只写特定小块代码
- 在前端作分层，确保每一层代码的稳定
- 跟真正懂前端的人一起把HTML、样式、控件好好规划
再回头看看，Angular给我们带来了什么？站在架构师的角度，你最害怕什么？害怕的是项目失控。怎么才能随时知道没有失控？分层，从下往上，逐次确保每个层面的稳定可靠，最上面的层出了问题，修复的代价最小。从这个角度出发，必须优先保证模型和业务逻辑不出问题。
Angular能让你把可控的东西一路往上推到很极端的地方，除了特别薄的表面，其他所有东西都纳入掌控，然后切切分分，丢给Java码农去搞，然后转身去跟真的懂前端的少数人一起把外面那层皮做好，协作一定是很愉快的。
刚才这些，我解释了为什么企业级的开发人员和架构师对Angular如获至宝。现在谈谈文中提到的其他几个问题：
- 性能
这个问题一针见血，确实有性能问题，但我们提到，这个框架的主要应用场景还是企业应用领域，只要它不把范围扩大，不会有什么影响，因为在这类领域，这种程度的启动性能问题压根就不敏感。
在实际开发中，一定会遇到一些其他性能问题，比如大数组，复杂对象，这些才是真正有影响的，需要用不同的手段来优化。这个我后面专门写文章讲。
那么，为什么我认为这些不是关键问题呢？是因为目前的企业前端开发领域，最核心问题压根不是性能，而是生产力，生产力处于严重低下的地步。收割机出来之前，人们手工收割，一行一行割过去，有了收割机，一次割一片。如果考虑细节效率，肯定收割机不如手工，因为收割机很容易漏收，掉在地上的也不少。那我们难道就因此坚守老的收割方式？火车出现之后，驾驶马车的看不惯它，问题是，你怎么知道你现在所谓的那些前端代码风格就是好的，高效的？改变个代码风格，一定错了吗？
况且，Angular的绝大多数性能问题处于非常上层的位置，这一层是有很多机会优化的，可以不影响业务代码的实现。
- 移动端
虽然目前也存在Ionic这样的框架，但我自己对这方面还是比较保留，也从来不会推荐人使用Angular开发移动端的东西，除非只是表单类的系统。
事实上，我们目前也并没有哪个框架真正解决了移动端高效生产，或者哪怕是开发得稍微舒心一点的问题，在这个事情上，大家只是五十步笑一百步。
- Angular 2.0
与作者的观点相反，我对2.0非常看好，认为它基本不会失去企业开发者的支持，同时会赢得更多移动端开发者。
在企业应用领域，甚至存在过GWT这么奇怪的东西，也就是完全用Java写界面，然后编译到HTML和JS去，而且这个东西在这个领域还是有很多人认同。Flex和Silverlight也同样有很大的用户群，基于这个，凭什么说AtScript就不会流行？我相信会有很多Java开发人员宁可写AtScript，也不愿意写JS，更何况，ng2.0只是自己用AtScript实现，业务开发人员一样可以很好地用JS开发啊。
关于这一块，我的两篇文章也说得很清楚了：
题外话：在现实中，我们碰到很多处理不好前端代码的项目，根本原因在于两点：
前端开发者缺乏架构意识 项目负责人和架构师没有足够的前端知识
这两点不解决，用什么框架都一定做成渣。
@xufei 的评论， 赞一个， 完全说出了我的心声。尤其是作为一个EXTJS+JAVA过来的前端。。。
原文中对angular缺点那块， 前面的表述是客观事实。 但后面的发展期望， 跟我刚好相反， 2.0的吸引力只会越大。
@xufei 您的评论很赞，同感，之前也是使用 JAVA 和 ExtJS 进行开发，因此目前被 AngularJS 吸引！ 期待 AngularJS 2.0 ......
这个文章过于扯淡，首先如何用angular不是作者定的。其次angular做移动没有任何问题。问题在于你以什么方式去用angular，如果是做移动端的人应该都知道ionicframework.目前表现还是比较抢眼的。 至于说angular 2.0是针对作者所遇到的问题我只能呵呵。 对于大量dom节点的性能问题，我想说的是，通过制造大量的不合逻辑的问题，本质是产品逻辑有问题的表现。 至于说Java开发人员怕写JS完全是水平的问题。 至少我遇到过的不管理是开发JS还是JAVA还是PHP都没有说不喜欢JS的 (这句话可能言过其实，但是大部分高级的开发者是不会在乎语言的。)
还有基于angular的材料设计已经可以使用了。
这个作者的很多观点都很保守，以至于JS能发展到现在完全是出乎于他的意料的。 所以不必太在意这个作者的观点，这个作者本身就是不支持AJAX化的。 但是目前AJAX已经成了标配，并且JS将不断的在前端发力。
对于angular是为企业开发而设计的看法完全不能同意。
如果新浪，facebook能搞出来angular就不用搞什么bigpipe这种低级的技术了。 后端人员不喜欢写js是因为切换成本太高。 而angular刚好解决了这个问题。 所有的后端只要提供逻辑接口就可以了。完全不用考虑模板的问题了。 而前端又可以解脱从来，更好的考虑性能，业务展示，交互。
@calidion angular做移动端没有任何问题？你真的用ionic做过东西？IOS先不说，换几个安卓机整几个转场动画你就知道什么体验了
@xiaobaicaistring 你的理解能力堪忧。我说angular没有问题，不是ionic。我只是说ionic比较抢眼。 ionic我本身并不看好，但是不表示angular不能支持移动端。理解？
@xiaobaicaistring @calidion 两位别吵了，能不能做这个是根据各自的应用对性能的要求情况的。angular的digest检测过程确实被广为诟病，开发者开发的时候留意一下，可以缓解这个问题。 ReactJS有一个开放的做法，就是开发者可以自己定制脏检测，从而比较细腻度地控制DOM更新，在某些对DOM操作要求很高的场合很有用，两位可以去关注下。
@calidion
把性能问题归咎于产品设计，是绝对错误的。具体产品项目里，我们可以根据框架能力来作出平衡，但是我们不能反推出来说这不是框架的问题。
企业开发中，高级开发者有多少？我对此要打个极大的问号。还有，喜欢不喜欢js这是无关紧要的。问题是大部分后端其实写js都多少会有一些问题。
bigpipe和angular完全是不同层面上的技术，你说bigpipe比angular低级实在无厘头。
总之，作者ppk是非常资深的前端，他的观点应予至少的尊重，而不是用“扯淡”。A2的变革改了大量东西，其中绝对有ppk所指出的问题的应对（虽然不可能全部涵盖）。你说他观点保守，能举点靠谱的例子吗？
我个人是非常赞同ppk对A1的评价的——“非前端人员做给非前端人员用的前端框架”。
@hax
性能问题当然是跟产品有关系的。 归不归只是一个看法的问题。如果新浪微博一下子展示1亿条微博，那么新浪再增加100倍的机器也没有任何效果。产品的合理性与技术的性能都是需要的。
任何框架解决的问题能力都是有限的，这也是需要人参与开发的原因。这也是程序开发人员的价值所在。否则angular + node + mysql + mongo + linux 如果能自己搞定一切，人在中间干嘛用？ 如果真是这样，任何人都没有任何价值。
bigpipe技术层面不同，解决的问题是相同的。angular可以实现多个视图不同时期不同位置的更新。 big pipe用后台的方式来实现代价很大，特别是象PHP这种不能长期驻留的脚本机制，需要写扩展。增加复杂程度，也增加布署时的难度。用angular同样可以实现这些功能。当然一个新技术与老技术比确实没有什么可比较的，毕竟优势太明显了。java或者php上不好做的，在node上实现非常容易。所以好处我就不多讲了。
PPK是资深是没有错的。但是他有Richard Stallman在开源界资深吗？一样有很多人反对他的GPL协议与他的观点。 我不认为资深就什么都对。你这种拿权威压人的思路本身就是不对的。 我前面也提到了。PPK根本不看好RIA。 但是flash,html5现在已经是大部分产品的主要暴发技术了。
我对PPK的评价并不赞同。 我一开始也不喜欢Angular但是相比较于其它框架，angular的概念足够全面，并且足够易用。 最重要的是，那还在坚持不断的改进。 我并不认为angular适合所有人的需求，但是我并不认为他是：“非前端人员做给非前端人员用的前端框架”。 angular解决的是业务的问题，是前端代码的组织的问题，而不是DOM的问题。 既然Angular是“非前端人员做给非前端人员用的前端框架”，那么那个框架是“前端人员做给前端人员用的前端框架”？试问有这样的框架吗？
我一直比较反感拿前端说事。什么叫前端？前端就是只会点DOM？ 我从不会过份区分前后端。任何技术本质是解决问题，而不是什么前端后端。 没有绝对的前端与后端。
目前大部分通用js类库都是同时包括前后端的。
同时我非常推崇后端直接取消模板的，这一点趋势在国外社区特别明显，象yeoman之类的基本上就是将人在这个方向上推。 优点有几个： 1、服务器数据可以更加结构化，垂直化 2、可以避免套数据造成的结构混乱 3、后端可以更加集中精力关心业务与数据，而不用关心展现 4、后端更加通用，不管是ios, android, html只要一个后端就能搞定 5、布署更加方便，在HTML5的CORS技术下，可以将HTML代码布署在各个地方或者手机端 6、更加移动化，如果FIREFOX OS或者UBUNTU流行，那么这种HTML5页面可以直接布署到这些手机上，成本更低。 7、设计、UI、开发的对接更加容易，不用再去重新切HTML代码。 8、调试更加方便，可以脱离后端直接调用UI界面的功能
缺点是： 1、对前端的开发员的水平高求更高 2、前端不再是简单的切页面，是真正的开发人员 3、对于前端的工具链要熟悉
以上观点当然是很个人的。并且执行理念也不是任何人都可以的。只有理解了这个理念的人才可能会有动力与能力去执行。 我不会反对任何其它的开发方式，但是无法同意PPK的观点。 我觉得前端的模板化是对浏览器的扩展，也是对开发实践的增强。
PPK如果将前端当成是调用DOM，只做展现，我认为是完全错误的。并不存在严格意义上的前端。
PPK最大的问题在于将套模板当成是后端的工作。显然违反了最基本的开发者的认识。就象当初他对RIA所持的偏见一样。但是时间证明了他是错误的。从目前的形势来看，只能说越来越多的JS产品越来越R了。否则前端就不用繁荣了。
@calidion 你说ppk对ria有偏见能否给出他的论述？
首先，我不认为ppk把套模板当成是后端的工作，我觉得你完全误解了他的意思。
他的意思是模板parsing和拼装的代价不应放在浏览器端，尤其是不应放在移动端浏览器（翻译里有点小问题）。
现在包含前端模板的框架几乎都有相同的问题。当然这些框架也都在想办法来解决由此带来的问题。包括新的浏览器端技术如Template元素也是在降低这样的代价。但无论如何，纯浏览器端的方案在几年之内都是无法完全解决这个问题的。
其次是产品和性能关系的问题。你举的1亿条微博是想表达什么呢？我们讨论问题当然是在可能的范畴里。Angular 1.x在功能和性能方面显然过于偏向前者，这不是ppk一个人有这样的意见。当然如果你对Angular的细节很熟悉，有信心可以在具体性能问题上找到优化解决方案，还是可以继续用它。不过更多的情况是，选择了Angular之后，踩了坑，被迫去深入框架内部，找到性能问题所在。诚然，解决方案也包括调整产品设计。但是你跟我说用Angular遇到性能问题就是产品逻辑有问题，那我只有呵呵了。
再次，关于bigpipe，你为什么会觉得Angular能解决bigpipe所针对的问题？我完全无法明白你的思路。
你可能不太了解我，我从来不会拿权威说事，相反我很多时候都是反对权威的，但是我反对的前提是我搞清楚那些观点和方法的来龙去脉（至少达到我自认为可以向大多数人解释清楚的程度）。所以，我讲ppk是资深，意思并不是他说的就是对的，而是你应该仔细考虑他的观点。
比方说，你说“angular解决的是业务的问题，是前端代码的组织的问题，而不是DOM的问题。”这不正符合ppk说的“给非前端人员用的前端框架”吗？你都没明白他的意思，你反对他个毛呢？
还有“前端人员做给前端人员用的前端框架”，jQuery、YUI、Kissy、QWrap等等难道不是这样的东西？
关于前后端分工的问题，我理解你的想法，不过我认为你的问题是错误的把ppk作为靶子。ppk的观点并不是你想的那样“将前端当成是调用DOM，只做展现”。我更倾向于相信他的观点是前端不是纯粹浏览器端而是把该放在服务器端的东西放在服务器端（那部分也可以是前端的职责）。
1.偏见见他的书，他认为ria不是正确的方向，最终会回到原来的状态，也就是RIA不会有什么发展。
2.他的意思我完全没有理解错误。原话是这样的： Although templating is the correct solution, doing it in the browser is fundamentally wrong. This job belongs on the server.
他的意思是模板化没有错，但是放在前端就错了。这项工作属于服务器端。
我完全不认同他的这一点。模板不放在前端，前端还玩什么？就是要有前端做模板化。否则搞什么mustache， handlerbars。angular只不过将这些东西集成了而已。如果这样说，表明他其实也是反对这些模板工作？
3.pigpipe只不过是减少了多次返回数据与多次渲染与展示分区的问题。并且代价是保持连接。这在有些web服务上的代价是很大的。这些东西现代的技术通常解决起来比bigpipe都好。并且bigpipe下，业务的耦合性加大。好不好仁者见仁。
4.你的观点刚好是我所反对的。前端不只是UI，不只是dom操作. 否则Gmail, Google Map就不会出现。html5也没有必要发展出来了。jQuery是给前端的难道underscore就不是了？这种观点是不是能成立？
5.你的意思是html不应该放在前端，但是我的观点刚好相反。套模板是后端问题最多的地方。也是后端结构混乱，代码质量差的根本原因。本来可以很好的做垂直切分的数据，因为做渲染就揉到一块。这是后端代码写的烂的一个重大原因。也是后端逻辑混乱的原因之一。
6.html放到浏览器渲染的好处我前面已经讲过不了。不再重复。个人完全不能同意模板应该放在后端的说法。
@calidion
ppk反对的是把parsing的代价转移到浏览器端（因为有性能问题），而不是反对某种特定的模板技术。假如说我们把模板编译为template元素和填充脚本（没有parsing代价），也许他就不怎么反对了。
bigpipe的关键点是让多个服务器逻辑可并行执行，且不增加http roundtrips。保持连接不是代价，而是其性能优势的原因。你说实现bigpipe代价大或者业务耦合，那是没实现好。
你有一个问题，认为浏览器端=前端。所以凡是我（或ppk）认为不应该在浏览器端做的事情，就认为我们是在限制前端。这完全是误解。我当然认为模板（html）是前端职责而不是后端，只是是放在浏览器端还是服务器端去parse，这是根据情况来的。谁限定了前端只能处理浏览器端代码？
@hax
- 你的理解力需要加强。没有parsing能力的模板还叫什么模板？反对parsing就是反对模板，反之亦然。特定不特定没有任何影响。按你的说法反对的应该是数据在模板上的密集运算，而不是parsing。但是数据运算刚好是我所要支持的。没有数据运算的模板要他有什么用？既然对计算这么敏感，为什么不考虑用WAP？或者直接用文本，都没有浏览器渲染的必要。你还要颜色，要图片干嘛？ 再加上现代的手机动不动内存几个G，CPU也是几个G。什么运算不能在上面做？什么网页的渲染能让几个G的CPU处理不过来，也说明这个网页做的是足够的挫。
- 不用BIGPIPE一样可以并行，并且BIGPIPE本身很大程度上是因为无法并行才做的串行化，BIGPIPE不是并行的好例子。 BIGPIPE本身就是对业务的耦合，否则如何做BIGPIPE，笑。至于说实现好不好是另说的事情。
- 前端当然只能是跟浏览器相关的端（包括模拟浏览器）才叫前端。服务器端解释HTML叫前端是一种胡扯。如果服务器端解释HTML叫前端，那么服务器的所有内容都可以叫前端。因为他离OS的核心都很远。讲前端也要注意你说话的场景。别自己想一套就认为是正确的。如果连概念都搞不清楚，如何讨论问题。前端开发不跟浏览器打交道，难道跟内核交道？自己愿意错误的叫服务器为前端是可以的。因为这个错误是你或者你们少部分人的错误。试图将这种错误传播的更广泛并不容易。因为对于概念敏感的人还是很多的。前端不处理浏览器或者依附于浏览器的代码，难道处理后台的服务器代码？
另，如果认为服务器解释HTML是前端，那说明你更应该支持将这些HTML放到真正的前端模板里。而不是在服务器里做解析。服务器模板是前端模板技术不够发达时表现，也正好表明前端应该更加大力的发展模板技术，而不是相反。
解析HTML的工作确实应该是属于前端的工作。但是目前大部分情况下都被服务器所承担。HTML模板刚好可以帮助解决这一长期不合理的情况。
关于文章中提到的将angular应用到gmail上的说法。等同于将.net用在dos上。是一种很可笑的说法。是一种对软件开发过程无知的体现。既然一个项目变更这么容易，为什么不用C语言写浏览器端的代码呢？ 说到吃狗屎，angular网站本身就是用angularjs完成的。新的material design也是用angularjs完成的。material design难道是面向桌面的。所以针对移动端的指责是没有任何依据的。
另外，既然觉得angular不好，是企业的应用解决方案，不如建立直接用extjs好了。extjs至少不会不支持企业的需求。但是我觉得好的前端大都不会喜欢去实践屎一样的extjs.而angular虽然有很多问题，至少实践起来不至于那么面目可憎。
angular有问题是客观的，但没有指出来的那么严重。拿backbone与angular比本身就是很可笑的。backbone要实现一个事件要写多少代码，angular呢？ 说移动端开发慢的人又能提供几个移动端速度快的?那些所谓的快的东西很多方面是无法满足你的需求的。等你花好几天解决了一个因为快而需要解决的问题时，用angular的人已经解决了好几个新的问题了。你愿意等，那是你的成本。硬件速度慢从来都不是一个大的问题，否则安卓就发展不起来。开发速度慢，才是更重要的问题.
小提一句：前端不是仅在浏览器端。我印象中，前端从一开始，就需要通过 php 等服务端语言为模板层负责。在阿里特别是支付宝，前端更是通过 Node 逐步在接管服务端的展现层，需要的服务接口由后端提供。
@lifesinger
我说过很多东西是有粘合点的。就象CSS与JS一样。 但是并不是因为粘合了，我们将JS与CSS混合在一起，相反，要更加的区分开。JS与CSS都可以实现展现特效。
你所谓的前端工程师与node工程师的道理也是一样的。 不能将处理模板工作的人就叫做前端工程师，会javascript都叫前端工程师。 之前的前端工程师做后台完全没有问题，因为他是可以全栈的。 你说python工程是前端还后端，难道他们不会写点JS？不会写点CSS？ 不会点数据库？不会弄点Map reduce?
一个人兼多种职位是没有问题的。但是不同的时间他所承担的角色是需要分清的。 不能因为一个人即可以架构，又可以前端就叫他是前端架构，也许他只是一个项目经理。 所以概念与实际要区分，承担的角色与实际的角色也是要区分。 特别是针对一个人的时候，是可以有多重角色的。但是不能因为人可以多重角色而忘记了区分工程职责的不同。
阿里，百度就是因为一些没有概念的人才会乱叫前端的。 这不是一个好现象。
否则所有的人都叫前端也没有问题。
既然你可以叫PHP前端开发工程师，我也可以叫数据库前端管理员。Linux前端管理员，还有Linux内核前端开发工程师。 当然这跟民主专政有异曲同工之妙，属于中国特色。