https://github.com/google/closure-stylesheets#renaming
应该是这个。就是防 css 名字冲突之类的功能。

右上角最后一个按钮是停用所有 breakpoints ，直接就破了这东西了。

我之前有个用 node 写的爬虫项目，里头用的 rx 。项目需要对 4 个网站的某个资源前 5 页的结果进行抓取。我用 rx 实现每次对一个网站的 5 页做平行请求，每个请求如果失败就重试，重试 3 次之后再放弃。完成一个网站 5 页抓取之后再进行下一个网站 5 页内容的抓取，最后收集结果保存。
这种需要对流进行复杂操作的场景，自己写就太困难了，靠 rx 就非常容易。
如果是做前端 ui 的话，需要 rx 的场景实在太少。硬上 rx 只是增加一层抽象，给自己添乱。

你有好几个异步数据流吗？你需要对这好几个数据流进行合并等高级操作吗？
没有就别上 rx

这地址挂了吧

@rashawn 这东西是 web 端啊。因为浏览器上只能跑 js ，所以这东西出来才那么多人觉得有意思。再接着你说的问题，服务器上不止 node 一个选择，为啥那么多人选 node 呢？
说到底，语言跑得快或慢，真的那么重要吗？绝大多数场景下的性能瓶颈都不在语言那吧。

十万手机号你还要编辑个啥

我们假设下一代 javascript 的速度是现在的十倍， web 有什么变化？

楼主你自己可以这么思考： git flow 能解决什么问题，一个人开发有没有这些问题。

有些免费的云平台支持 node ，比分讲 heroku

你觉得云里雾里，是因为你看到的都是怎么实现 restful 的文章。
你要找的是一篇文章，告诉你 restful 能解决什么问题，别的方法为什么解决不好这个问题。然后思考你的工作有没有这些问题，要不要上 restful 解决这些问题。

@467347544
https://www.html5rocks.com/en/tutorials/speed/static-mem-pools/
这有篇文章，你参考下。

你要干啥？做游戏的话得考虑用内存池自己管理了。

这种优化就是把普通 list 变成 lazy 的 list ，然后内部保存了一个 command list 。每次往那个 chain 后头加个 filter ， map 之类的方法的时候，往内部的 command list 里加东西。最后对这个 lazy list 取值的时候再去对 list 里的每个 item 执行那个 command list 。本质是个 monad （ linq 就是 monad ）。
从遍历的角度看，虽然 list 只遍历一次。但是那个 command list 每次都要遍历。速度未必比每次遍历都快。

@matts8023 all 是几个东西同时出去，等全部完成后收集结果。没有依赖关系。

如果你是第二步依赖第一步的结果，第三步依赖第二步的结果。那写出来肯定是一个套另一个的。 Promise 不是拿来解决这种问题的。

1.异步跟多线程没关系。
2.async await 是把异步的东西弄成写起来像同步一样。
3.promise 是个能往函数里传，也能从函数里返回的东西。当你从这个角度看 promise 的时候，它就不只是一个语法糖了。有人说 promise 是为了解决回调地狱而出现的，那是瞎扯淡。
4.想真正利用好异步，还是得靠 rx 。

能实现 =》
1.能更好的实现（算法）
2.能应对变化的实现（架构）

写代码无非是这样的过程。学习了跟“算法”、“架构”有关的新知识之后，再去拿自己之前写的东西做实验，看能否用新知识改进之前的东西。然后再写新东西的时候，直接用之前实验的成果。

@hanzichi 是的。我待过好几个这样的公司了。他们都把工资分 n 块，里头基本工资低的要死，剩下的都是奖金什么的。税和保险都是按那个基本工资交。