拆参数，拆对象，默认值处理，这几个新特性，实在是人见人喜欢，其他的就无所谓了。 node 基本 es6 都支持了吧，又不要编译，不用干嘛呢。

楼主你讲的是现在后端开发避免不了，而且暂时解决不了的问题。
前端（ web, 手机客户端）的 view 长成某个样子，要你造个 api 提供满足这个 view 的数据。 view 改了，你是改之前的 api ，还是造个新的 api ？之前的 api 是留着，还是删掉不要呢？ web 和手机客户端上的界面差不多，但是需求稍微有点不一样，你是造俩 api ，还是造一个同时满足它们的需求呢？
最后的结果就是一团乱。

https://www.infoq.com/articles/no-more-mvc-frameworks
这文章的前几段就描述了这种情况。

“返回 12 个月的统计信息”，这么个名字的 api 就应该返回 12 个月的统计信息。
“返回有数据月份的统计信息”，这么个名字的 api 就应该只返回有数据的。
不是职责问题，是人家要什么样的 api ，你又能给什么 api 的问题。

jQuery -> 前端模板 -> MVC -> react
你直接从头跳到尾，步子迈大了，当然不知道怎么回事。

http://jsbin.com/vasolucame/edit?html,css,js,output

其实是挺有意思的问题。

各种云服务的文档，毕竟是拿来卖钱的，不会含糊。 jquery 的文档，多年积累，简单易学。

明明是面向对象语言的设计模式
这几条原则倒是各个语言通用的：
Encapsulate what varies.
Favor composition over inheritance.
Classes should be open for extension, but closed for modification.

你要是搞前端，就去学学 elm 。函数式编程的关键是写 pure function ， js 少了很多语言级别的特性，做不到的。

`$('[style="display:block !important;position:fixed;top:0;margin-bottom:10px;width:100%;background:#c44;color:#fff;font-size:15px;z-index:99999"]')`

人家也要靠广告吃饭。嫌广告多或者嫌 adblock 提示恶心，那就不要上他们家网站了。搞这些斗争何必呢。

前端太 low 。要么你走要么他走

无限键盘那个数字小键盘的灯都是不亮的，就为了省电。你还想找个带背光的

@mahone3297 因为废了老大劲做出来的东西用户体验根本不好。没有流畅动画，不符合用户习惯。

1. 能不做 spa 就不做。
2. 你有多少个页面，是否要在前端用路由库？哪个框架搭配的路由库你觉得简单能接受？
3. 每个页面东西有多少，是否要考虑 lazy load 每个页面的代码，哪个框架实现 lazy load 简单？
4. 现在前端都是组件化的。你选择的框架是否用丰富的组件，拿来拼拼就能用？
5. 能不做 spa 就不做。

按你举的例子，格式化时间戳之类的东西就应该放 view 层，写（找）几个公用的 util 函数就是了。 react 本身是组件化的东西，天知道哪天你需不需加个不需要转换格式的组件，到时候你怎么办。

从你想着 “这些组件需求一样，我给他们一样格式的数据” 开始，你就是在想继承了，你就错了。

性能问题完全可以通过把你的 util 函数 memoize 解决 。

你想的是虚拟按钮触发物理按钮。实际应该是虚拟按钮跟物理按钮执行同一个函数。

手机上一般没空间放图标。怎么体现品牌呢，就只能是靠颜色了。前面那个白色的设计和现在的红色设计摆一起，你说哪个更像是 youtube

典型的就是购物车， TODO list 那样的东西。要解决的就是这么一个问题：同一块数据出现在 view 里的不同地方，这些地方又都能修改这个数据，怎么让这些地方同步起来。简单讲就是 mvc ，你修改 modal ， modal 触发 change 事件， view 注册这个事件，把 view 上面跟 modal 相关的地方都给更新了。 mvvm 是更新 view 的一种方法，前端的 react 用的是另外一种方法。不管你选 mvvm 还是其他什么，基本上你要做的都只是更新 modal ，其他的交给框架来做。

@menc 谁打？你打，我打，还是找个评测组每天审核想在 npm 上发包的人，谁代码写的少就打谁？忽略重点，胡搅蛮缠。

v2 真是奇葩。国外讨论的重点是 npm 的中心化问题。这边在讨论人家区区几行代码配不配发布到 npm 上。