HE Shi-Jun

不仅是感觉舒服，而且我觉得也是合理的。因为API统一作为抽象层总是要付出代价的，关键这代价放在哪里。浏览器端与服务器端（node）比，显然是浏览器端对任何成本更加敏感——比如看看npm的树策略和bower的平面策略就可以看到不同的选择方向。服务器端多数情况下其实无所谓你包了几层——反正node本来的强项也是io密集应用，而API统一的成本是间接调用也就主要是cpu消耗，相比较而言对性能影响估计可忽略不计。至于多的代码占用空间啥的，更是如此。

@sapjax 我举个工作中的例子。最近我们上了一个在线聊天的功能，使用的是某云服务提供的基于Web Socket的chatting service。他们暂时只有iOS和Android的sdk，所以用于网站的sdk是我们自己写的。在这个项目中我就选择尝试了前述用browerify但是统一于html5 api的方式。主要的原因是两个。第一是这强迫我们必须把界面（大量dom操作，只在浏览器中测试）和通讯和协议层（websocket、ajax以及少量dom storage部分，大部分在Node.js环境中测试，然后通过browerify打包后再在浏览器环境中测试）分离，负责sdk开发的可以专注于协议本身的问题，和第三方的接口也比较方便。第二是后续我们服务器端也需要直接调用云服务，这个时候就直接共用了相同的sdk。 所以这样的需求不见得很多，但是还真的是存在的。 其他的典型例子，比如经典的表单验证。如果能统一到 html5 的 validation API，会方便很多。

是不是md5其实无所谓，关键是计算出上一次部署文件和本次部署文件是否有差异。大概7、8年前就做过这样的方案——拿本次部署对应的资源文件（未加版本号的）比对上次部署对应的资源文件（未加版本号的），计算出差异，然后计算依赖，得到最终所有要变的资源文件集，所有变更的文件自增版本号，不变的用上次的版本号，更新所有依赖链接为最终的path。

压缩导致结果变化的情况没遇到过。不过某些大厂有用差异更新的，小差异导致压缩的短变量名大量变化从而增加了diff大小的情况，倒是会有的。

@hzoo We only need transform `lib/index.js`, so add this plugin to config which will apply to `src/*` seems too heavy?

Yes. Maybe we can change `build` command to `babel src -d lib && babel lib/index.js --plugins add-module-exports --out-file lib/index.js`?

ppk此文写得很有深度啊。

@calidion 把性能问题归咎于产品设计，是绝对错误的。具体产品项目里，我们可以根据框架能力来作出平衡，但是我们不能反推出来说这不是框架的问题。 企业开发中，高级开发者有多少？我对此要打个极大的问号。还有，喜欢不喜欢js这是无关紧要的。问题是大部分后端其实写js都多少会有一些问题。 bigpipe和angular完全是不同层面上的技术，你说bigpipe比angular低级实在无厘头。 总之，作者ppk是非常资深的前端，他的观点应予至少的尊重，而不是用“扯淡”。A2的变革改了大量东西，其中绝对有ppk所指出的问题的应对（虽然不可能全部涵盖）。你说他观点保守，能举点靠谱的例子吗？ 我个人是非常赞同ppk对A1的评价的——“非前端人员做给非前端人员用的前端框架”。

@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，只做展现”。我更倾向于相信他的观点是前端不是纯粹浏览器端而是把该放在服务器端的东西放在服务器端（那部分也可以是前端的职责）。

@calidion ppk反对的是把parsing的代价转移到浏览器端（因为有性能问题），而不是反对某种特定的模板技术。假如说我们把模板编译为template元素和填充脚本（没有parsing代价），也许他就不怎么反对了。 bigpipe的关键点是让多个服务器逻辑可并行执行，且不增加http roundtrips。保持连接不是代价，而是其性能优势的原因。你说实现bigpipe代价大或者业务耦合，那是没实现好。 你有一个问题，认为浏览器端=前端。所以凡是我（或ppk）认为不应该在浏览器端做的事情，就认为我们是在限制前端。这完全是误解。我当然认为模板（html）是前端职责而不是后端，只是是放在浏览器端还是服务器端去parse，这是根据情况来的。谁限定了前端只能处理浏览器端代码？