［翻译］Angular的问题

xufei commented 9 years ago

［翻译］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的新版能生存下去。

calidion commented 9 years ago

将上面的内容重新组织了一下： Web开发的前端与后端的界线在那里？

hax commented 9 years ago

@calidion 概念、术语、名词是服务于沟通的。你可以重新定义术语，但是如果大多数人对这个术语的内涵和外延的理解，以及实际的用法都跟你不一样，那实际丧失了沟通的作用，或者至少极大的增加了你和其他人的沟通成本。

在你重新定义“前端”和“后端”这两个词之前，我建议你读一下 http://en.wikipedia.org/wiki/Front_and_back_ends 这个词条。当然维基百科未必就一定是正确的，但是至少可以代表主流的理解。

calidion commented 9 years ago

我怀疑你没仔细看wiki，Wiki对于web前后端的定义与我说的是一致的。同时我的过渡性的普遍性解决了他的困惑。

hax commented 9 years ago

@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.

怎么跟你的一致了？

还有什么“过渡性的普遍性”，按照我对前端和后端的定义，几乎不存在这样的“过渡性”。因为判断的标准是代码本身是否服务于表现层。如果存在所谓“过渡性”只能说明这代码的分层有问题。

calidion commented 9 years ago

就这么点英语，还没有读全。真是无语。这个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.

hax commented 9 years ago

@calidion 请注意“A rule of thumb”是什么意思。

我只贴头上一句是因为这句才是定义。请照着定义读3遍再看看你自己的定义。

calidion commented 9 years ago

这也是我称我的文章解决了这个wiki的疑惑的原因。因为这个wiki本身并不知道如何准确的去区分。

hax commented 9 years ago

@calidion 你的区分是基于你的定义。但我说了你的定义跟wiki根本是不一样的。所以你所谓的准确区分对基于此维基词条的概念来说是无意义的。

calidion commented 9 years ago

笑了。你不针对我的内容讨论，却在一个对如何界定前端后端上不明确的条目上下文章。如果你想继续讨论这种无意义的事情，我就不陪你了。

hax commented 9 years ago

人家的定义明明白白的写在那里，我再贴一遍给你

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.

不过对你来说估计不符合你胃口的东西你就视而不见。

calidion commented 9 years ago

你所引用的presentation layer更多是指GUI，在软件工程领域，也不是你所谓的模板。
你所提到的HTML模板是数据与结构层，并不是presentation layer

如果你懂前端HTML， CSS， JS的主要功能，你应该很清楚，现代HTML的作用是什么

模板不是展现层，你将这段话引用过来，说明你认为HTML模板是展现层。由此可见你的概念是混淆的。

如果对于HTML的作用不清楚，当然也是国内开发者的通病。我这里有一篇文章比较详细的说明他们之间的关系，可以供你参考： DIV+CSS的说法实际上是一种误解
在这里我再次强调概念的重要性。概念不清楚的人很难在实际环境中区分开复杂的环境，并作出正确的判断。这虽然是大部分项目的常态，但是也是大多项目失败的重要原因。

所以不管出于什么原因引用这一段话，都表明你本身存在着理解上的问题。

hax commented 9 years ago

@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的。

最后，我完全同意概念的重要性，所以才不厌其烦的反复跟你讲概念。

calidion commented 9 years ago

html是不是数据，结构？如果是，那么为什么不是在data access layer?

感觉你是想将任何事情都当成是前端。试问按你的逻辑，应该如何划分Web前端与后端？

我不否认前端可以有n-tier，后端也可以n-tier. 但是将n-tier里的东西与web前端与web后端混起则显得有点混乱。

其实我想听一下你完整的前端与后端理论。

概念重要我是完全同意的。所以请让我完整的想听一下，你如何定义presentation layer与data access layer，前端与后端。

“服务器端的routing和controller也都可能属于presentation layer” 请说明你的推理过程。

hax commented 9 years ago

@calidion

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的设计其实回应了很多这些问题（尽管许多人还是不买帐）。

rlog commented 9 years ago

@calidion , @hax 我觉得你们如果不带互嘲和反讥的讨论问题我们这些‘看客’还是很受益的。非要用这种语气聊天吗？

calidion commented 9 years ago

HTML是内容，也是数据。内容只是数据的另一个形式的表述，本质上没有明显的差别。HTML是内容数据与结构数据的结合。

HTML是表现层，数据层，逻辑层三层共同作用的结果。一个HTML页面的内容确实分你所说的三层的内容。一方面HTML里要填充数据，另一方面HTML要准备好有效的结构。再一方面HTML葽考虑网站的整体业务逻辑。

所以HTML是一个综合体。当然最主要的是数据与结构。数据本身就是一个广泛，而抽象的概念。所以就不要再细化了。
isomorphic还是API的方式，只是一种形式上的差别。我通过我的“过渡性的普遍性”理论表达了我对领域重合度问题的看法。我不会去限定前端的技术内涵，并且表达了前端与后端在技术栈上没有本质的差别观点。所以在我看来，前端与后端用浏览器与服务器来区分就可以了。技术是可以共用的。
对于我来说，我对前后端没有任何的倾向性。但是在如何界定前后端上，我是比较在意的。前后端扩大不扩大对于我来说根本没有意义。如果说你在考虑扩大前端的职权，那更象是一个政治问题，而不是技术问题，概念问题。如果说你想更好的区分前后端的职权，实际上API的形式对你更有利，当然前提得有人能将前后端端平。我喜欢API+HTML独立是因为套HTML是最容易出问题的地方。API化具有一定的优势。但是对于初级工程师来说，没有很好的测试理念是很难写好API的。同时在前端组装也存在一点的问题。
业务复杂度跟前后端也没有任何关系。对于很多大型游戏来说，复杂的业务在前端。所以讨论前后端没有任何必要讨论技术栈与业务的问题。因为随着发展，前后端都是可以出现非常复杂的技术的。
正因为我们讨论的不是表现层的问题。才没有必要纠结于HTML或者模板。一方面以浏览器与服务器作为前后端的界线，另一方面也让两者在技术上共通，共享。这才是我要表达的概念的重要性。Web前端后端更多是一个环境概念，而不是完全是一个技术概念。如果你理解了这一点，你的困惑就没有了。
关于人才问题，我对人才的概念的理解是更加复合的。分清楚了前端与后端是环境概念后，就不要将这个概念对应到人或者技术上了。你可以说你要前端工程师，但是前端工程师难道就不能干后端的活？一个好的人才的能力是非常有扩展性的。当然对于领域兴趣有限的人来说，固定于一个领域也是完全没有问题的。
虽然前后端的差异在减少，但是实际上前后端的差异还是明显存在的着的。并且目前看来，对于一个规模较小的网站，前端的常规工种要比后端实际上要多一些。
在一条明确的线(浏览器与服务器)与不明确的线(模板处理，展现)之间，你选择了后者，而我选择了前者。所以你的办法暂时无法去区分前后端，而我的办法是可以很容易的区分前后端的。同时我也必须指出来，如果前端只是处理模板，DOM，展现，那么angular就没有必要性了。backbone也一样。就连JS都显得多余。

chinfeng commented 9 years ago

在 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 之流的都无法逃脱性能的魔咒。

island205 commented 9 years ago

火后留名。

keenwon commented 9 years ago

说的很好，继续观望，等2.0出来再说吧。

coogleyao commented 9 years ago

很好！理不辩不明～

calidion commented 9 years ago

angular的性能问题其实也不是框架的根本性问题，而不过是一个阶段性要解决的问题。angular理念本身是没有什么大的问题的。以致于angular 2.0一出来后，性能直接打肿PPK的脸。angualar 2.0的性能超过很多人推崇的react好多倍（相关视频可以到youtube上搜索）。

性能很重要，但是理念也是很重要的。很多时候性能的提升与理念是不冲突的。

那种说什么模板或者HTML必须在后端解释的没有逻辑性的言论是不可能经受时间的考验的。

angular 2.0目前处于alpha状态。

可以通过 angular 2.0 访问。

fujc-dev commented 7 years ago

好多大神啊，我居然把评论都看了

xufei / blog