Eric

欢迎试用，代码尚不稳定，欢迎反馈。

You can take a look at this igniter variant: https://github.com/low-api-support-trojan/igniter Proxy only will soon be implemented as well as support that all apps will be excluded by default and auto...

这个文章过于扯淡，首先如何用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不能支持移动端。理解？

@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？ 我从不会过份区分前后端。任何技术本质是解决问题，而不是什么前端后端。...

PPK最大的问题在于将套模板当成是后端的工作。显然违反了最基本的开发者的认识。就象当初他对RIA所持的偏见一样。但是时间证明了他是错误的。从目前的形势来看，只能说越来越多的JS产品越来越R了。否则前端就不用繁荣了。

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就不是了？这种观点是不是能成立？...

总之将html当成是另一个android就对了。服务器别再干吐html这种傻事是最好的。

@hax 1. 你的理解力需要加强。没有parsing能力的模板还叫什么模板？反对parsing就是反对模板，反之亦然。特定不特定没有任何影响。按你的说法反对的应该是数据在模板上的密集运算，而不是parsing。但是数据运算刚好是我所要支持的。没有数据运算的模板要他有什么用？既然对计算这么敏感，为什么不考虑用WAP？或者直接用文本，都没有浏览器渲染的必要。你还要颜色，要图片干嘛？ 再加上现代的手机动不动内存几个G，CPU也是几个G。什么运算不能在上面做？什么网页的渲染能让几个G的CPU处理不过来，也说明这个网页做的是足够的挫。 2. 不用BIGPIPE一样可以并行，并且BIGPIPE本身很大程度上是因为无法并行才做的串行化，BIGPIPE不是并行的好例子。 BIGPIPE本身就是对业务的耦合，否则如何做BIGPIPE，笑。至于说实现好不好是另说的事情。 3. 前端当然只能是跟浏览器相关的端（包括模拟浏览器）才叫前端。服务器端解释HTML叫前端是一种胡扯。如果服务器端解释HTML叫前端，那么服务器的所有内容都可以叫前端。因为他离OS的核心都很远。讲前端也要注意你说话的场景。别自己想一套就认为是正确的。如果连概念都搞不清楚，如何讨论问题。前端开发不跟浏览器打交道，难道跟内核交道？自己愿意错误的叫服务器为前端是可以的。因为这个错误是你或者你们少部分人的错误。试图将这种错误传播的更广泛并不容易。因为对于概念敏感的人还是很多的。前端不处理浏览器或者依附于浏览器的代码，难道处理后台的服务器代码？

另，如果认为服务器解释HTML是前端，那说明你更应该支持将这些HTML放到真正的前端模板里。而不是在服务器里做解析。服务器模板是前端模板技术不够发达时表现，也正好表明前端应该更加大力的发展模板技术，而不是相反。 解析HTML的工作确实应该是属于前端的工作。但是目前大部分情况下都被服务器所承担。HTML模板刚好可以帮助解决这一长期不合理的情况。