［翻译］Angular的问题
xufei opened this issue · comments
［翻译］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的新版能生存下去。
翻译的并不通顺，读起来有些拗口，应该再精益求精一些。
恩。翻译出来造福大家，给个赞。
用 issues 开博客的人应被支持
ppk此文写得很有深度啊。
早上看到阮一峰老师转发了这篇文章，中午手痒翻译了一份。
认真地说，这篇文章的很多观点我还是很赞同的，而且令人印象深刻，比如说：
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 您的这一番论述很赞，^_^，比原文章看着爽
@xufei 的评论， 赞一个， 完全说出了我的心声。尤其是作为一个EXTJS+JAVA过来的前端。。。
原文中对angular缺点那块， 前面的表述是客观事实。
但后面的发展期望， 跟我刚好相反， 2.0的吸引力只会越大。
@xufei 您的评论很赞，同感，之前也是使用 JAVA 和 ExtJS 进行开发，因此目前被 AngularJS 吸引！
期待 AngularJS 2.0 ......
用Ionic做了一个iOS APP，至少反馈来说没提到性能问题，同样期待AngularJs 2.0
跟过的一个项目是用 Vaadin 作界面的，从前端的角度看就是坑爹，不过 Java 的程序员似乎觉得可以接受，只能说自己不是目标用户，自然无法理解，Angular 也是如此。
赞！
没有通用解决方案是最重要的点
让我最有感触的还是题外话
这个文章过于扯淡，首先如何用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刚好解决了这个问题。
所有的后端只要提供逻辑接口就可以了。完全不用考虑模板的问题了。
而前端又可以解脱从来，更好的考虑性能，业务展示，交互。
@xiaobaicaistring 你的理解能力堪忧。我说angular没有问题，不是ionic。我只是说ionic比较抢眼。 ionic我本身并不看好，但是不表示angular不能支持移动端。理解？
@xiaobaicaistring @calidion 两位别吵了，能不能做这个是根据各自的应用对性能的要求情况的。angular的digest检测过程确实被广为诟病，开发者开发的时候留意一下，可以缓解这个问题。
ReactJS有一个开放的做法，就是开发者可以自己定制脏检测，从而比较细腻度地控制DOM更新，在某些对DOM操作要求很高的场合很有用，两位可以去关注下。
把性能问题归咎于产品设计，是绝对错误的。具体产品项目里，我们可以根据框架能力来作出平衡，但是我们不能反推出来说这不是框架的问题。
企业开发中，高级开发者有多少？我对此要打个极大的问号。还有，喜欢不喜欢js这是无关紧要的。问题是大部分后端其实写js都多少会有一些问题。
bigpipe和angular完全是不同层面上的技术，你说bigpipe比angular低级实在无厘头。
总之，作者ppk是非常资深的前端，他的观点应予至少的尊重，而不是用“扯淡”。A2的变革改了大量东西，其中绝对有ppk所指出的问题的应对（虽然不可能全部涵盖）。你说他观点保守，能举点靠谱的例子吗？
我个人是非常赞同ppk对A1的评价的——“非前端人员做给非前端人员用的前端框架”。
性能问题当然是跟产品有关系的。 归不归只是一个看法的问题。如果新浪微博一下子展示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放到浏览器渲染的好处我前面已经讲过不了。不再重复。个人完全不能同意模板应该放在后端的说法。
总之将html当成是另一个android就对了。服务器别再干吐html这种傻事是最好的。
ppk反对的是把parsing的代价转移到浏览器端（因为有性能问题），而不是反对某种特定的模板技术。假如说我们把模板编译为template元素和填充脚本（没有parsing代价），也许他就不怎么反对了。
bigpipe的关键点是让多个服务器逻辑可并行执行，且不增加http roundtrips。保持连接不是代价，而是其性能优势的原因。你说实现bigpipe代价大或者业务耦合，那是没实现好。
你有一个问题，认为浏览器端=前端。所以凡是我（或ppk）认为不应该在浏览器端做的事情，就认为我们是在限制前端。这完全是误解。我当然认为模板（html）是前端职责而不是后端，只是是放在浏览器端还是服务器端去parse，这是根据情况来的。谁限定了前端只能处理浏览器端代码？
- 你的理解力需要加强。没有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 逐步在接管服务端的展现层，需要的服务接口由后端提供。
我说过很多东西是有粘合点的。就象CSS与JS一样。
但是并不是因为粘合了，我们将JS与CSS混合在一起，相反，要更加的区分开。JS与CSS都可以实现展现特效。
你所谓的前端工程师与node工程师的道理也是一样的。
不能将处理模板工作的人就叫做前端工程师，会javascript都叫前端工程师。
之前的前端工程师做后台完全没有问题，因为他是可以全栈的。
你说python工程是前端还后端，难道他们不会写点JS？不会写点CSS？
不会点数据库？不会弄点Map reduce?
一个人兼多种职位是没有问题的。但是不同的时间他所承担的角色是需要分清的。
不能因为一个人即可以架构，又可以前端就叫他是前端架构，也许他只是一个项目经理。
所以概念与实际要区分，承担的角色与实际的角色也是要区分。
特别是针对一个人的时候，是可以有多重角色的。但是不能因为人可以多重角色而忘记了区分工程职责的不同。
阿里，百度就是因为一些没有概念的人才会乱叫前端的。
这不是一个好现象。
否则所有的人都叫前端也没有问题。
既然你可以叫PHP前端开发工程师，我也可以叫数据库前端管理员。Linux前端管理员，还有Linux内核前端开发工程师。
当然这跟**专政有异曲同工之妙，属于**特色。
angularJS在设计这个这个框架的时候，是用什么设计的，有用什么类图的工具吗？
反对parsing就是反对模板？第一次听说，呵呵。主流模板都支持预编译，就是为了减少parsing的代价。且我已经举了template元素的例子，视而不见？
“如果服务器端解释HTML叫前端，那么服务器的所有内容都可以叫前端。”——你这话，所有后端都要笑了。20年前人家就知道three-tier架构了。business layer如果混入了html，那是要被嘲笑的。
怎样算前端？我觉得有不一样的见解是很正常的，每个公司每个团队都可能有独特的地方。不过总还是存在大量共性。认为所有其他人的看法都不对，就太过自大了。建议你多听多看。
其实大约8、9年前，我当时做的所有库和框架都是纯浏览器端的方案，完全后端技术中立。即使那时我也从没有认为服务器端模板就不是前端范畴。选择纯浏览器端的方案无非是服务器端模板的职责常被（我认为）不恰当的划归后端工程师，以及服务器端模板受限于服务器技术平台，java/asp.net/php各相不同。（想想看为什么现在大量前端架构是基于nodejs的。）
但是后来我逐渐认识到这种纯浏览器端的前端存在一些难以克服的问题，比如parsing代价，首次加载优化，seo，无脚本支持，某些兼容性处置等等等等。不是说纯前端方案一定不行，而是其要做出的折中在许多场景下（尤其是面向所有用户的互联网平台级产品）是太大了。
我就举一个小小的例子，根据UA提供不同的polyfill和shim（最近一些非常前沿的框架和服务如nlz和polyfill.io就这么干的），要用纯浏览器端的方案做几乎是不可能的。
@hax
能明确说一下你所谓的parsing是什么吗？ 什么预编译，什么template难道有不需要parsing的？能搞清楚概念再讨论吗？
更搞笑的是，你能理解成好像我是支持在business layer里加html的？你都什么逻辑？我刚好是支持你不要混入html全部放到前端来，放到浏览器端来。什么three-tier, 你就是thousand-tier也跟前端无关。何况前端也可以n-tier。我有反对分层吗？ 笑话。先理解好我的意思，再来反对我。我不希望我们的讨论是没有逻辑性的。
如何理解当然可以不同，但是不同总得有不同的理由？我说的前端是浏览器相关的html, css, js技术。不包括模板吐html。虽然html是前端的，但是他并不浏览器直接作用的内容。我不反对前端技术可以有很多种形式，但是他必须是围绕在浏览器端的技术。 模板技术作为动态网页的技术很早就存在了。如果按你的意思，cgi就是最早的前端技术。因为cgi技术就是吐模板的。php，jsp之流都后代之孙。所以按你的思路c,bash,perl,python,凡是作何可以生成html的技术都是前端技术？我不自大，也不自卑，我只按逻辑来讨论问题。**人最在的问题是没有逻辑。我碰到没有逻辑的人多了。好在github上的内容都是公开的。相对平等，大家都是明白人，按逻辑去推理，总能找到能经受时间考验的内容。
说前端架构基于node就表示你根本不懂node是干嘛的。node难道只是用来做前端架构的？node的出现首先解决的是服务器的性能问题，而不是前端问题。node的web服务器是很晚才出来的。node出来时是做的基于事件的tcp服务器。最早的例子都不是用http做的。你说出来这些话，我觉得我真没有必要在这里浪费时间了。最怕跟概念不清的人胡扯。
如果你能把解决服务器的性能问题也归到前端，那么就当我什么都没有说过。
因为node的发展导致前端技术的暴发性发展是有的。不过因此说node是前端是可笑的。grunt, yeoman, bower等基于node生态的工具是极大的提升了前端的开发能力，但node本身并不直接跟前端相关。关于技术的重合点的问题我就不重复了。据基因科学表明人与猿的基因相似度在90%以上，我们都不认为人就是猿。如果前端与后端如果没有点重合的地方，那就是违反自然规律了。
你举的例子只能说明你的思路受限。我已经用纯前端做过好几个项目了。完全没有服务器端的吐模板工作。根本不存在什么你所说的不可能性。并且我通过纯前端可以�区分不同的手机，区分不同的浏览器。这跟放在服务器端有什么区别？ 我是不太理解。希望能讲解一下。
parsing也要我教？好吧，简单的，<p>Hello {{user.name || 'world'}}</p>这样一个模板要怎么变成最终可用的代码？
假设某个模板引擎是编译为
function anonymousTemplate(model) {
return '<p>Hello ' + escapeText(model.user.name || 'world') + '</p>'
}此编译过程可以在load了template源码后执行，也可以预先编译，这样加载的就不是template源码而是编译后的js函数。
明白了吗？
至于你其他写的一堆我就先不回应了。你看懂上面的再说。
我还以为对于parsing有什么高见呢。
前后端分不清，模板分不清，难道后端代码不需要parsing?
至于说谁懂没懂，还真别急下结论。
你能不能看懂我说的是其次，重要的是你根本没有理解对。
说到所谓的一些问题时，你可考虑过浏览器一开始根本没有javascript支持?
根本没有ajax支持。
你所谓的一些问题，看似好像很重要，实际上就是扯蛋。
否则你也别用HTML5了。
因为IE6不支持。
连不支持脚本都考虑上了，你的考虑也是很全面的。
你是不是用的lynx上的github？如果是我就不跟你争了。你赢了。
还有能否讲解一下既然PHP，javascript等写在HTML的脚本语言都是前端。
那么通过浏览器前端javascript判断UA与服务器前端PHP判断UA都是前端判断UA。
是不是表示两个判断没有差别？都是前端判断？
还有一个问题是能不能让PHP直接在浏览器里执行数据库访问代码？毕竟大家都是前端的。直接将数据库请求放进来也没有什么大不了吧？
愿听前端高手解答。
在受到广泛质疑后ppk写一个近似狡辩的文章。
http://www.quirksmode.org/blog/archives/2015/01/front_end_and_b.html
内容也是考虑no script的情况。既然考虑了no script，
怎么不考虑无法解析html与css的情况。
还有你开发的客户端应用是不是同时支持 android, ios, web os, firefox os, ubuntu touch, wp了?
如果你还没有做不到，你就是最好别扯什么兼容性。
即使你做到了，你也可以在很多兼容性好的平台采用激进的技术。
同时在支持不好的设备上采用更成熟的技术。
从任何的角度来说，激进的采用前端模板与在旧设备上采用后端技术也不会有任何的冲突。
下面是反对ppk的文章。
http://blog.salsitasoft.com/the-shifting-definition-of-front-end-developer/
虽然我不能完全同意他的看法。
但是至少比ppk的要更加同意一点。
我的观点非常明确，作何技术都是有重合点的。作何时候都不可能相近的事物100%分离开。
Angular之类的ria是一个大的趋势，但不阻碍一些保守份子使用原来的技术。
但是保守分子也不应该起来无理的反对进步。
当前端与后端在做同一件事情的时候，放在那一端只是一个选择的问题。
既然放在后端没有人反对，放在前端你有什么可反对的？
谁规定了html必须由后端来吐?
ppk说别人是troll,实质上他自己才是真正的troll.
在理想的条件下，后端做好业务逻辑与接口，前端做到业务逻辑与展现。大部分联网核心业务逻辑必然放在后端。 如果不是联网应用，那么所有逻辑都可以放在前端。
桌面html的大势已经起来了。如果我只是做桌面应用，并且不连网，我也需要尊从ppk�另加一个服务器专门用来展示html？
@calidion 模板预编译的问题，我哪里讨论过js支持问题？我不知道你在扯什么。我这么简单一段话你都看不懂，就不指望你看懂ppk写的文章了。
你连我在说什么都不知道，还好意思说我能不能看懂？
何况看不懂看得懂。每个人都可以有不同的解读，你也不是最后的审判者。
我说parsing就是模板的功能，而你却说不是。然后举个例子打自己的嘴吧。既然不能明白模板包括模板的解析，你还讨论什么模板？
如果一个模板包括什么都不能分清，你就当后面的全是废话即可。我不会要求你一定能看懂的。
我也不想证明你懂还是不懂，这不是我的任务。
我只是想说明前端模板化是没有问题的，用不用是你的选择问题。
你觉得解析速度不满足，你可以不用。
但是你无权按你的思路来告诉别人前端模板化不行。
PPK不支持ajax的观点，现在脸都已经被打肿了，现在只不过是重复同样的结果而已。
再加上quirksmode已经是很古老的问题了。
现在正确的HTML技术绝对是禁止进入quirksmode里面的。
关于兼容性的问题如果不懂，可以看下我的介绍：
虽然没有很多文字，但是也没有见国内有人能比我提前总结出来。
大部分兼容性问题的讨论都是低水平的细节的讨论。
如果你有兴趣展示你的水平，不妨来挑个错。
如果没有，就别动不动猜测别人能不能看懂了好吗？
如果你是来讨论问题的，那就讲具体的技术问题。不要预设你自己认为的就是对的，不要给别人安一些没有讲过的话来攻击（比如我从来没说过前端模板一定不行）。
其实多说也没用，你一时半会儿是改不了这脾气的。我只想建议你沉静一点，不要老是急于否定别人，就算你想否定，也花点时间先搞清楚别人的观点，再花点时间研究到底具体的那些点是有问题的，才好有的放矢。
不说ppk，本帖的译者徐飞、（从你的博客看到的）你嘲讽过的seajs的作者玉伯，还有我本人，都算是前端的过来人了。不是说权威，不是说资历，但是如果一个人在一个方向上持续耕耘了很多年，至少应有基本的尊重。
这个尊重，不是指客气，而是指要假设他们的理性能力至少和我一样，因此如果他们的观点和我不一致，我首先要想的不是他们智商太低、水平太低，而是或许我漏掉了他们的某些根据。可能是我忽略了，也可能是他们没完全讲清楚，甚至有一些他们自己也没有意识到的背景知识。
我举个你大肆嘲讽的seajs作为例子。其实我也认为seajs相比较requirejs并没有什么本质性优势，但是仍然是有很多好的点的。比如api的简洁性。requirejs其实后来也加了commonjs wrapper的支持，我不能说它是因为效仿seajs而加的，至少说明方向性上是一致的。又如静态化，cmd实际上是比标准amd更接近静态化，像require实际上是作为关键字而不是方法存在，在语义上cmd比amd更接近ES6 module。相反，你攻击的有些点，比如按需加载还是预先打包，实际上是具体场景下的选项，而不是黑白两分。
注意：以上是以seajs举例说明，如果要具体讨论可另外开贴，请勿在本讨论下直接回复。
总之，如果你眼里都是低水平，你最多也就能达到自以为比他们高一点点，希望你能逐渐看明白别人的高水平都是在哪里的——这一点是比较难的，我自己是在自大了5、6年之后看到一个完全超乎我想象的前端框架才明白这一点的。希望你能比我幸运。
seajs我只是说了几个他们的问题，特别是seajs这群人自吹自擂，说别人水平低，才是我攻击他们的原因。我没有否认他们的工作，只是觉得做的并没有比requirejs好，却要自吹有多好，这种风气是不可取的。
ppk也一样，ppk对新事物可以有他自己的理解，有自己的理解不代表他是对的。他对ajax的看法已经被打脸。并且我也觉得选择是自由。没有人阻止ppk用他的办法。
至少在哲学上，ppk没有这种自由的观点。
尊重是相互的，至少在我看来，我以表达客观的观点为主。如果因为客观而显得不尊重，那我只能表示我们的接受能力还有待掉高。至少客观不会出现div+css这种错误的说法，而尊重就会出现。
尊重是好事，但是不利于问题的真正解决。
seajs说自己比require好多少，可尊重过围绕requirejs生态的其它人的工作？
我大不大肆嘲讽的seajs仁者见仁，如果说seajs这帮小屁孩不说这样的话，我也没有必要去理他们。
观点太主观，作者视野有点窄。 CommonJS 和未来的 ES6 module 才是主流，requirejs 的前途比起browserify 和 component 都不如，非常不推荐使用。
afc163
你如果真看了贴子，还说是我不尊重，说明你的立场是预设的。
我不想跟你讲谁是尊重，谁是不尊重，至少阿里那批跟我讨论的人没有几个值得我尊重的人。
尊重有时也可以称为沆瀣一气。
如果你想跟他们一样，尽管大骂。
es6不管是cjs还是amd都是接近的。因为es6的目标就是合并这两个。不过在我看来可能不是一个好的决定，这个需要让时间来证明。
同样我不觉得水平高就是对的。自以为水平高，拿不出来充分的理由，有什么意义？
有些人可能更多的是营销。
话题扯远了，还是继续为什么前端不能用模板？
可以根据我的表述反驳，不必考虑尊重的问题，我只喜欢跟有逻辑的人讨论。
谢谢。
躺着中枪。
PS：我说的那句话观点鲜明，没啥问题。requirejs 和 seajs 是那个年代的特有产物，目前的趋势就是死掉，非常不推荐使用。
@hax
如果你或者ppk的看法是对的，那么你就应该反对react.js，因为react.js定位只做v，说白了就是前端模板化的工作。我在写移动端时也试图弄过前端的模板框架，不过因为没有backbone、angular优雅而废弃，react.js的跟我的思路更加类似，但是我比较倾向于angular的方式。
我认为对新事物抱有一定的怀疑是可以的，但是不要过于主观，而不看趋势。
否定前端模板化的人，我只能说等着瞧。
前端模板化是我在5年前就明确的一个趋势，只不过最近几年才爆发。
竟然前端里面还有人认为模板是后端的事，从我的角度来看，我应该怀疑这些人是不是做软件开发的，更怀疑这些人是不是做前端的。
@afc163
不要扯蛋。js也是时代的产物，也是一样要死的。
作为软件开发者，要知道兼容性与扩展性的平衡，更要通过实践来验证新事物。
不是什么新事物一出来旧事物就马上退出的。
既然你们在异步加载与js的未来发展上预见性上不足，就不要打包票你的观点有多准确了。
我觉得我现在继续推荐requirejs一点不会有问题。
es6是不是能真正的使用起来，还是个问题。
对于这么多的改变，能不能被社区接受也是一个问题。
变异的js是不是能受到开发者欢迎也是一个问题。
从个人的角度来看，并不怎么看好。
html5出来很多年了，真正用的很欢乐的有几个？
很多东西是需要时间的考验的。
同时模块加载，类，从来不是什么大问题。
特别是如果使用象angular这样的类库的话。
@afc163
再提醒一点，如果阿里真的有能力就不要跟在google后面做类似yeoman的工具或者generator.
而是做一个比yeoman更牛的自动工具出来，加速前端的工业化。
我支持前端模板化，不过并不看好react.js，将代码与html混合不是个好主意。
@calidion 我觉得有些话本不需要重复多次。这是我最后一次就模板的问题解释观点：
我（或PPK）从来没反对模板，甚至也从来没反对浏览器端模板。所以我们根本不可能反对react（即使对react有所保留也不是基于它是浏览器端模板这一点）。PPK反对的是把解析和编译模板的成本转移到客户端（尤其是性能相对较差的手机浏览器），但是他不会反对预编译的模板（注意预编译并不表示一定是服务器端模板，也可以只是经过gulp/grunt等的构建过程而已）。顺便注意react的jsx就是要编译的，且react作为一个纯view的技术自然没有限制说不能用在服务器端。
我之前也举过Template元素的例子，Template元素能避免很大一部分解析模板的成本，并且在代码安全性上也完胜绝大部分浏览器端模板库，只是有其他代价（你得自己填充数据），且只有新浏览器支持。
实际上，我自己理想的前端架构中，模板处于核心位置，而不像Angular/React等架构，模板只用于视图，是从属于由JS构建的App的。因为我没有找到满足我理念的类似框架，因此从三年前开始就一直在自己搞模板引擎。目标并非基于纯浏览器端的模板，也非纯服务器端的模板（尽管目前的实现是服务器端模板），甚至不是两端复用的模板，而是同时覆盖浏览器端和服务器端的模板系统——能够依据配置（甚或自动）生成最终运行在浏览器里的代码——在不同环境不同浏览器中生成的代码可以是不一样的，但是确保语义（行为）是一致的。比如可能配置为首次加载时（用户从未访问过）直接rendering了最终页面呈现给用户，而后续访问则是浏览器端通过ajax获取数据并执行预编译好的浏览器端模板——当然你总能手动做这样的优化，但是很麻烦（特别是纯浏览器端的模板）。对于新的支持Template元素的浏览器，理想状况是编译为基于Template元素构建，而不需要完全编译为基于字符串拼接的函数。而对于支持SPDY/HTTP2的新浏览器，甚至可以考虑首次加载也不必使用服务器端模板来rendering，因为这只是一种优化手段。
注意我上面讲的那些细节并不重要，重要的是，我如何看待“前端”，与你如何看待“前端”的差异。
即使我可能需要在服务器端做许多事情，但是这些事情其实是围绕着最终浏览器呈现的，因此我定义这些事情都是属于“前端职责”，因为一个后端工程师缺乏对浏览器端技术的充分和细致的理解和掌握（比如不知道Template元素，也自然不知道如何把一个中立的模板编译为基于Template元素填充数据的代码）。
当然你可以认为这些方式方法不好，没用，过时了，等等，我们可以个别的讨论每个这样的问题，但是这不改变这些事情是属于前端范畴这一点。
希望这段解释对你能work。
- 我不会同意你所认为的前端只处理模板这块的工作
- 更不会同意将服务器处理模板当成前端，虽然我认为模板最好是纯前端的工作
- 作何一个产品最终要交付于用户使用，难道这后面的所有工作都是前端？你这样显得特别概念不清。
有时间先看看interface是什么概念。光interface就有一堆的概念，你现在不但不区分，反而将他们混淆起来，你如何将问题说明？
工具
grunt, bower, 都是工具，可以针对前端，也可以针对后端，所以在我看来，他们不是归类于前端或者后端的，他们是工具。任何开发都是需要工具的。
但是我们可以认为bower是前端工具，属于前端的工具链。
HTML不是区分前后端的界线
长期的在后端套模板的工作，确实也是与前端相关的事情。
但是很不巧，大部分情况下，模板的生成是要消耗后端的脚本计算能力的，所以他首先是一个后端运算，然后他再生成html，所以除了生成html以外，没有作何与前端的相关工作了。
所以个人认为这是一个分界区，理应放在前端处理的。
所以个人不支持将模板放在后端，虽然reactjs支持后端预编译。
任何web应用都无法避免与html交流。所以说以html来明确界定前后端显得很困难，特别是一些旧技术还能吐html出来。所以我觉得争论包不包含html不是界定前后端技术分界线，特别是在技术界线不明确的情况下。
所以个认为将html从后端代码剥离是一个更好的方式前后端显得更加明确，以前技术上实现有难度，现在基本上没有了。所以这是一个趋势。
前端，后端，工具
所以我的看法是：
- 在服务器端运行的技术是后端
- 在浏览器端运行下的技术是前端
- 工具是工具，辅助前后端。工具是可以前，可以后。工具具有其灵活性。
前后端技术不具有明显的差异性
都可以有数据库，都可以多线程（虽然目前还不行），都可以做并行运算。
都可以处理html。
所以前后在技术层面本质上没有差别，更多的是概念上的差别。
目前浏览器技术完全可以运行于后台。
浏览器都可以运行于服务器，那么这个概念也是不变的。
所以前端与后端不是以你的技术区分的，而是根据你的运行环境来区分的。
例如：
- javascript用运在浏览器端叫前端脚本，运行于node就是后端脚本。
- 比如搜索引擎技术是对html文档的处理技术，但是搜索技术绝对不会被归到前端技术上
html一样可以在无联网的环境下运行，这时不存在前端与后端的概念。这时只有桌面的概念。
其它的我就不多讲的，相信大家都应该理解了。
过渡性的普遍性
大部分东西是不能完全区分开的。这种现象我认为可以称之为过渡性。过渡性是所有事物的普遍现象。即使在概念明确的情况下，有些技术也是即可以看成是前端技术， 也可以看成是后端技术的。前面的javascript与html就是例子。
将上面的内容重新组织了一下：
Web开发的前端与后端的界线在那里？
@calidion 概念、术语、名词是服务于沟通的。你可以重新定义术语，但是如果大多数人对这个术语的内涵和外延的理解，以及实际的用法都跟你不一样，那实际丧失了沟通的作用，或者至少极大的增加了你和其他人的沟通成本。
在你重新定义“前端”和“后端”这两个词之前，我建议你读一下 http://en.wikipedia.org/wiki/Front_and_back_ends 这个词条。当然维基百科未必就一定是正确的，但是至少可以代表主流的理解。
我怀疑你没仔细看wiki，Wiki对于web前后端的定义与我说的是一致的。同时我的过渡性的普遍性解决了他的困惑。
@calidion 同学，你又淘气了
the terms "front end" and "back end" are distinctions which refer to the separation of concerns between a presentation layer and a data access layer respectively.
怎么跟你的一致了？
还有什么“过渡性的普遍性”，按照我对前端和后端的定义，几乎不存在这样的“过渡性”。因为判断的标准是代码本身是否服务于表现层。如果存在所谓“过渡性”只能说明这代码的分层有问题。
就这么点英语，还没有读全。真是无语。
这个WIKI所谓的前端与后端是很广泛或者普遍的。
这里介绍了软件设计领域的前端与后端概念，跟我所描述的是一样的。只不过我所描述的是更细分的领域 ，只是针对WEB来说的。不过实际上他所举的例子也是WEB的。
In software design, for example, the model-view-controller architecture, provides front and back ends for the database, the user, and the data processing components. The separation of software systems into front and back ends simplifies development and separates maintenance. A rule of thumb is that the front (or "client") side is any component manipulated by the user. The server-side (or "back end") code resides on the server. The confusion arises when one must make front-end edits to server-side files. Most HTML designers, for instance, don't need to be on the server when they are developing the HTML; conversely, the server-side engineers are, by definition, never on anything but a server. It takes both to ultimately make a functioning, interactive website.
@calidion 请注意“A rule of thumb”是什么意思。
我只贴头上一句是因为这句才是定义。请照着定义读3遍再看看你自己的定义。
这也是我称我的文章解决了这个wiki的疑惑的原因。
因为这个wiki本身并不知道如何准确的去区分。
@calidion 你的区分是基于你的定义。但我说了你的定义跟wiki根本是不一样的。所以你所谓的准确区分对基于此维基词条的概念来说是无意义的。
笑了。你不针对我的内容讨论，却在一个对如何界定前端后端上不明确的条目上下文章。如果你想继续讨论这种无意义的事情，我就不陪你了。
人家的定义明明白白的写在那里，我再贴一遍给你
the terms "front end" and "back end" are distinctions which refer to the separation of concerns between a presentation layer and a data access layer respectively.
不过对你来说估计不符合你胃口的东西你就视而不见。
-
你所引用的presentation layer更多是指GUI，在软件工程领域，也不是你所谓的模板。
-
你所提到的HTML模板是数据与结构层，并不是presentation layer
如果你懂前端HTML， CSS， JS的主要功能，你应该很清楚，现代HTML的作用是什么
模板不是展现层，你将这段话引用过来，说明你认为HTML模板是展现层。由此可见你的概念是混淆的。
如果对于HTML的作用不清楚，当然也是国内开发者的通病。我这里有一篇文章比较详细的说明他们之间的关系，可以供你参考：
DIV+CSS的说法实际上是一种误解 -
在这里我再次强调概念的重要性。概念不清楚的人很难在实际环境中区分开复杂的环境，并作出正确的判断。这虽然是大部分项目的常态，但是也是大多项目失败的重要原因。
所以不管出于什么原因引用这一段话，都表明你本身存在着理解上的问题。
@calidion
你是怎么理解presentation layer的？这里关div+css什么事情？除非你把presentation layer狭隘的理解为style。
presentation layer就是presentation layer，不是GUI。命令行界面（比如MUD）一样可以是presentation layer。
按照维基的定义，对应presentation layer的叫做front-end。以此为基准，以web platform为presentation layer技术栈的即是我们常说的Web前端开发。
在复杂的BS应用中，不仅html+css+js都是presentation layer，服务器端的routing和controller也都可能属于presentation layer。此点你可以找多层架构相关的文章去看。所以你拿是否在服务器端来判断这件事情是不符合此定义的。
至于模板，模板本身是一个广义概念，但是我们这里讨论的html模板当然是属于presentation layer的。
最后，我完全同意概念的重要性，所以才不厌其烦的反复跟你讲概念。
html是不是数据，结构？
如果是，那么为什么不是在data access layer?
感觉你是想将任何事情都当成是前端。
试问按你的逻辑，应该如何划分Web前端与后端？
我不否认前端可以有n-tier，后端也可以n-tier.
但是将n-tier里的东西与web前端与web后端混起则显得有点混乱。
其实我想听一下你完整的前端与后端理论。
概念重要我是完全同意的。所以请让我完整的想听一下，你如何定义presentation layer与data access layer，前端与后端。
“服务器端的routing和controller也都可能属于presentation layer” 请说明你的推理过程。
html不是数据——不是data access layer意义上的data。
我们偶尔讲html是数据，大多是“html是内容”的一个不严谨表达。而html是_内容_，是相对于css（样式）和js（行为）而言，完全不涉及应用架构中的数据层——要知道表现层和数据层之间还隔了一个逻辑层呢。
对于逻辑层和数据层而言，其所操作和存取的数据通常完全不是html形式的，而是更一般和底层的形式，数据层上可能是sql表，逻辑层可能是某种数据集形式。就你比较喜欢的RIA来说，ajax的数据接口通常是json或xml的，尽管产生json/xml的部分在复杂应用的整体架构中也很可能被划归为表现层（比如仅仅是对业务服务接口的适配），但至少不是html。它们和html的最重要的差别在于，一般json和xml是没有明确定义的semantic的，它们至多有明确定义的schema（其实也很少见，特别是json），数据的意义是在使用中隐含表达的（或者由接口文档给出模糊的定义）。从这个角度说，html模板（不管是浏览器端还是服务器端）起到了将数据转换为信息（在既定结构中转换和填充数据形成完整内容）的作用。
当然也可能数据本身就是html document或片段。但是这跟我们讲“html是_内容_”的意思是完全不同的。
n-tier 本身不讲前端后端，在典型的三层架构出现的年代，我们还没有web前端这个工种，只有网页设计制作（美工、切页面的……）和程序员（工程师）的区分。如果把前端作为切页面的延续，或许比较容易达到你的以是否接触服务器端来区分前后端的定义。但是如果我们把前端后端作为程序员当中的分化，则不难得到以负责presentation layer的为前端的定义。当然，实际上前端开发者的来源是两方面都有的，有从网页设计或美工转入的，也有从程序员转入的。即使在现在，在一些公司里仍然保持了这种区别（所谓“重构”职位和“前端”职位）。
认为我“想将任何事情都当成是前端”，可能是因为我（和大部分团队的前端leader）倾向于扩大前端职责的一个错觉。实际上后端有很多很复杂很难的事情我们一般不说，比如超复杂的业务规则、海量的数据存储和查询之类的挑战。
今天当我们讨论web应用中的前端的时候，其实已经不是表现层的问题，而是是否有部分逻辑层也转移到了浏览器中，这是对传统架构的挑战（这几年又一次非常火的前后端分离的大讨论就是应此而来）。要应对这个挑战有很多方式，比如全栈就是一种方式（好不好另说了），如你坚持纯浏览器端+ajax访问服务器端接口的方案也可以作为一种方式，Isomorphic JavaScript也算一种方式，（这文章里只用过两次backend，你可以注意到它对应的就是文章里图的api部分，所以这文章作者对backend的用法是和我及大多数人一致的，不是按照server/browser-side划分的。其实淘宝和腾讯都有用类似的这种架构。当然你可以不同意这种架构，但是请注意他们对前端后端这些概念的用法。）还有许多不同的方式。哪一种最好现在没有答案（可能将来也不会有确定的答案），但是至少不要用狭隘和偏执限制住自己对不同方式的理解和吸收。
还要补充一点，讲Isomorphic JavaScript的那拨人对Angular的不满其实更集中在架构上，而ppk的这篇文章里，只是把此作为一个方面，还有很多其他方面的（一些是非纯粹技术的）问题。这是一个综合性的探讨，而且Angular2的设计其实回应了很多这些问题（尽管许多人还是不买帐）。
-
HTML是内容，也是数据。内容只是数据的另一个形式的表述，本质上没有明显的差别。HTML是内容数据与结构数据的结合。
HTML是表现层，数据层，逻辑层三层共同作用的结果。
一个HTML页面的内容确实分你所说的三层的内容。
一方面HTML里要填充数据，另一方面HTML要准备好有效的结构。
再一方面HTML葽考虑网站的整体业务逻辑。所以HTML是一个综合体。当然最主要的是数据与结构。
数据本身就是一个广泛，而抽象的概念。所以就不要再细化了。 -
isomorphic还是API的方式，只是一种形式上的差别。我通过我的“过渡性的普遍性”理论表达了我对领域重合度问题的看法。
我不会去限定前端的技术内涵，并且表达了前端与后端在技术栈上没有本质的差别观点。
所以在我看来，前端与后端用浏览器与服务器来区分就可以了。技术是可以共用的。 -
对于我来说，我对前后端没有任何的倾向性。但是在如何界定前后端上，我是比较在意的。前后端扩大不扩大对于我来说根本没有意义。如果说你在考虑扩大前端的职权，那更象是一个政治问题，而不是技术问题，概念问题。如果说你想更好的区分前后端的职权，实际上API的形式对你更有利，当然前提得有人能将前后端端平。我喜欢API+HTML独立是因为套HTML是最容易出问题的地方。API化具有一定的优势。但是对于初级工程师来说，没有很好的测试理念是很难写好API的。同时在前端组装也存在一点的问题。
-
业务复杂度跟前后端也没有任何关系。对于很多大型游戏来说，复杂的业务在前端。所以讨论前后端没有任何必要讨论技术栈与业务的问题。因为随着发展，前后端都是可以出现非常复杂的技术的。
-
正因为我们讨论的不是表现层的问题。才没有必要纠结于HTML或者模板。一方面以浏览器与服务器作为前后端的界线，另一方面也让两者在技术上共通，共享。这才是我要表达的概念的重要性。Web前端后端更多是一个环境概念，而不是完全是一个技术概念。如果你理解了这一点，你的困惑就没有了。
-
关于人才问题，我对人才的概念的理解是更加复合的。分清楚了前端与后端是环境概念后，就不要将这个概念对应到人或者技术上了。你可以说你要前端工程师，但是前端工程师难道就不能干后端的活？一个好的人才的能力是非常有扩展性的。当然对于领域兴趣有限的人来说，固定于一个领域也是完全没有问题的。
-
虽然前后端的差异在减少，但是实际上前后端的差异还是明显存在的着的。并且目前看来，对于一个规模较小的网站，前端的常规工种要比后端实际上要多一些。
-
在一条明确的线(浏览器与服务器)与不明确的线(模板处理，展现)之间，你选择了后者，而我选择了前者。所以你的办法暂时无法去区分前后端，而我的办法是可以很容易的区分前后端的。同时我也必须指出来，如果前端只是处理模板，DOM，展现，那么angular就没有必要性了。backbone也一样。就连JS都显得多余。
在 ng 官方的 Guide 中，有这么一句：
Angular is built around the belief that declarative code is better than imperative when it comes to building UIs and wiring software components together, while imperative code is excellent for expressing business logic.
我认为原作者是没能理解 ng 的这套哲学，多数观点、例子，是逆其道而行。看起来就如不得其法的人神经唠叨的抱怨。
唯有性能问题，这个还算是比较正确的。也许浏览器发展还不够快，新式框架如 react 之流的都无法逃脱性能的魔咒。
火后留名。
说的很好，继续观望，等2.0出来再说吧。
很好！理不辩不明～
angular的性能问题其实也不是框架的根本性问题，而不过是一个阶段性要解决的问题。angular理念本身是没有什么大的问题的。
以致于angular 2.0一出来后，性能直接打肿PPK的脸。angualar 2.0的性能超过很多人推崇的react好多倍（相关视频可以到youtube上搜索）。
性能很重要，但是理念也是很重要的。很多时候性能的提升与理念是不冲突的。
那种说什么模板或者HTML必须在后端解释的没有逻辑性的言论是不可能经受时间的考验的。
angular 2.0目前处于alpha状态。
可以通过 angular 2.0 访问。
好多大神啊，我居然把评论都看了