ele.me 是如何运行的
写这篇文章的时候，整个 APP 已经发生了不少变化，甚至已移除 Grunt 转用 Webpack。然而初衷未变，架构方式未变，半夜下笔。虽如此，本篇也不打算详述每个技术细节，更想做的是说清楚下面几点。
前端即业务
前后端分离：不要停留在「中途岛」
把每个页面都变成组件
当手工作坊进入工业自动化年代
难道你还没用 ES6 和 CSS Next？
编译加发布到所有机器只需 200 秒是一种什么样的体验？
机器与流量：APP 最大可承受多少并发？
题外：团队工作流
一、前端即业务
没毕业那会，鬼哥写了一篇文章说到「当有一份不错的工作只需要写 CSS」，就在腾讯。当年在《重构》的影响下，这个叫「重构」的职位应运而生，这是一个切图仔工作。直至今天，前端在携程仍是「重构」而 JS 工程师被称为「开发」。在很长一段时间内，甚至时至今日这个职位仍可能只负责把 PSD 转成 HTML，而数据输出是由后端工程师做的，市场上很多写「至少精通一门后端语言」也是从这点产生的。那时大家都在喊，前端是最接近用户的，最了解设计的，没错，可前端却不可能在一个公司中充当 CTO 的。
当 Ajax 成为日常，SPA 成为标配，甚至数据已都双向绑定，而 BaaS（Backend As A Service）慢慢被接受，后端 MVC 只保留了 M。iOS、Android、浏览器开发已经统称前端，Client-side MV* 驱动，前端即业务 —— 负责路由、响应用户操作和做数据通讯。如果今天你还在还原 PSD，我只能跟你说，辞职来我这。
二、前后端分离：不要停留在「中途岛」
大概 13 个月前，我加入饿了么，第一个项目是彻底改版 m.ele.me，说到前端后端要分离。有天 CTO 问「中途岛」研究过么？我当时说，那不叫前后端分离，不知道他心里有没有在问「你究竟懂不懂前端？」。要是我也写了一个 Node 层来负责与 PHP / Python 层对接，这样前端负责 Node + 浏览器端开发，可能会被升职加薪，因为最终变忙，把事情变复杂，而且有好多 bug 要修，像是劳苦而功高。可是我选择了 MV* 的 Angular.js 把用户业务接管到浏览器端，而后端作为 API 提供商，时间很快，熟悉业务加开发一个月把整个移动网站都开放出来给大家用，机智地避过了升职加薪的机会。
因为当时整个网站都运行在一个 PHP 框架上，Template 层使用了 Twig，既然已经想让浏览器接管一切，那么让 PHP 只需要处理 M 层就可以了。
无论是 Twig 还是 HTML，我们遇到一个问题：HTTP 请求太多了。解决这个问题其实可以使用script作为 Template，当然也可以直接把模板编译成 ng 的 Template Cache。前者写在 html 里太丑了，而且不能重用（你丫也可以写成单独一个文件啊），变成 js 文件吧，然后一起扔到 CDN 上去。情况就是这样：
Twig -> HTML -> Template Cache(js) -> (CDN)
结果整个网站变成了 Nginx + index.html + BaaS，呃，Node 给了很多机会，可是这会还有人想停留在「中途岛」吗？考虑一下下面的问题：
把 View 的渲染交给服务器，还是切分交给每个用户的浏览器？
是否需要重启 Nginx 、重启 PHP、重启 Node？
Cache API 后并发可以提高多少？
不需要复杂的 HTML 缓存机制/机器，CDN + 静态 html 可以搞多少并发？
我只想说一句，你选吧。
三、把每个页面都变成组件
把业务接管到浏览器同样会遇到一个问题：MV*。把目录分成lib/、model/、controller/、view/，太多这种做法了。比如 angular-seed 之前的分法就类似，把所有 controller、directive、filter、service 都放在不同文件。这样做是不是最佳实践呢？
