怎么最近这么多黑 V2EX 的？

@zhang_soledad 黑得不留痕迹……

@lips 工具不是选流不流行，而是应该根据应用场景挑选适合自己工作方式的。我也没号召大家都不用 Bower。但是从开发者的角度来说，只推崇一种工具很容易养成“拿着锤子看什么都是钉子”的心态。从工具的角度来看，任何一个流行的工具都是没那么快消亡的，所以短时间来说继续用 Bower 一点问题都没有。

受益良多，不知道 LZ 对 Core OS 怎么看？

Chart.js 还可以，也是基于 Canvas 的。不过论到可定制性和学习成本，基于 SVG 的 D3 真乃神器。

@jimrokliu 很不错的文章，谢谢推荐！近段时间学 Phoenix 的感觉就是更严格，但也更松散，一个 Phoenix 项目更像一个预装了几个 Hex 包的 Elixir 项目，Phoenix 生成的项目代码更像是 scaffold，都很简单也非常容易改写。

@yukihiro_matz Python 应该跟 Ruby 差不多速度吧？

@nightire Rails 性能已经被黑过无数次了，习惯就好。现在但凡 Web 框架比性能都会不怀好意地拉上 Rails

以前用 Slim，现在用 erb，从来没喜欢过 Haml。erb 没文档是因为它就是在文档里嵌入 Ruby 代码，它甚至不管你的文档写什么（HTML/JSON/YAML...），所以你只要懂 <%= %> 和 <% %> 以及 Ruby 就行。HAML 有文档是因为它要教你它的那些语法会如何转换成 HTML。

@mrpasserby 这个鱼钓得好

@cassiuschen 就是说部署的机器只需要有 Erlang VM 环境就可以了，不需要装 Elixir 是吧？

@lips 如果是 Rails 项目，又没有很重的前端逻辑，Sprocket 就可以干 Bower 干的事情。前端项目直接用 NPM 加上一个模块加载器就行了，推荐 Webpack。

@nightire 你已经在项目里面用了？

在学 Phoenix，感觉 非常不错 。

@i5ting 所以我说的是 以前 。虽然我不知道 Browserify 是怎么工作的，不过我用过 Webpack，它把代码编译成浏览器可以运行的模块风格，然后提供一个轻量级的 runtime 去加载模块，Browserify 应该同理。预编译的手段连语言层面的差异都可以忽略（CoffeeScript, TypeScript），更何况模块风格（CommonJS, AMD, ES6 module）。所以我想表达的意思是，CommonJS 风格的模块代码在前端不是没法用，是以前没有多少人想这么做，这是为什么我也不知道，也许是因为 AMD？我感觉的原因可能是当时很多前端项目不复杂导致没有普遍的高度模块化的需求。如果说错了欢迎指正。

@sharpx 这点我也不知道，毕竟我是正牌 Ruby 工程师加 Node.js 半桶水。Node.js 对我来说大部分时候就是构建下 build 工具和写点 proxy。不懂的也很多。如果不是现在对 Node.js 服务器端异步编程比较感兴趣，我连 NPM 怎么做包管理都不会去看……

@so_zengtao 第一次见我是啥样的？

@sharpx 确实包管理和模块加载器确实是两个概念。Bower 不该负责模块如何加载，以此作为缺点是有失偏颇。不过我觉得包管理和模块加载的关系非常密切，所以混到一起来谈。我的看法是：所谓的包封装的也是模块，打包只是为了更好地分享，所以包管理器提供包格式的定义，打包，上传，下载；模块加载器提供的才是如何加载模块和管理依赖，包的依赖实际上是因为被封装的模块之间有依赖。所以理想情况下包管理器是无所谓前端还是后端的。

很多人以前不用 NPM 作为前端包管理器，大概就这么几个原因：

1. nested dependency .
2. CommonJS 模块风格在浏览器上没法用。
3. 开发思维还是老一套的用 <script> 标签加载打包并且压缩好的文件，模块化的思想还没有成为共识。个人觉得这是根本原因。

现在模块化的思想都普遍被认可了，上面的问题就都不是问题了。所以 NPM 也被用于前端包管理也就是顺理成章的事情。

同意 @kgen 的看法，补充几点：

1. 政府为了解决越来越麻烦的大学生就业问题。
2. 热钱总要有个去处，房地产和股票已经没法去了，投资和创业是个“好”选择。做好了还能带起一条产业链，促进城市发展……

BTW 淘金热的时候，淘金的人不见得能赚钱，但在路上卖锄头和铲子的一定会赚钱。我觉得创业同理。

BTW2 当政府都开始大力推销创业的好处时，真得动脑子想想，就像我一个朋友跟我说的“当你这种外行都知道要买股票的时候，我就该卖了”。

简单地说，Bower 解决问题的思路已经跟不上前端的发展了，被取消是一个明智的决定。

具体说来我觉得原因有以下几点：

Bower 确实不太好用

它只解决了包和依赖的下载问题，但没解决加载顺序问题（虽然有第三方的解决方案），开发者还是需要手动加载模块并调整顺序。另外在解决依赖冲突方面做得也不够好，如果需要的包比较多，很容易会经常手动管理 resolutions，非常不方便。

Bower 的包管理理念跟不上前端开发的需求

几年前，开发者需要一个插件，就要去往上找插件，手动下载文件并且用 script 标签引用。那个时期 Bower 的包管理思路对开发方式是有极大改善的。但在前端发展越来越复杂，对模块化要求越来越多（框架模块化，UI 组件化，甚至 CSS 都要随模块按需加载）的情况下 Bower 能提供的就很有限了。

前端包管理选择太多

对开发者造成了负担。NPM，Bower，JSPM，Component 这些都是比较有名的包管理器的选择。每种都有自己的拥簇。这对包的开发者来说是个负担，往往一个热门项目要兼顾几种包的格式，有的还要分多个子项目如 xxx-bower，xxx-component。这对使用者来说也是个负担，因为每种包管理器都有擅长的地方，所以一个项目中往往混用两种或以上的包管理器。比如很长一段时间大家都觉得 NPM 适合后端包管理，Bower 适合前端包管理，所以一个 Node.js 项目往往要同时用 NPM 和 Bower，这无疑降低了统一性并且加大了维护成本。

NPM 的前后端通吃使 Bower 不再是必需品。

第一点中 Bower 的缺点在 NPM 中本来就不是问题。Browserify 和 Webpack 的崛起也直接让 NPM 成了前端包管理的主流选择。使用 NPM 还让一个项目几乎不需要第二个包管理器。从各种方面来看 NPM 已经是大势所趋。

没怎么认真写过 Python，不过我觉得 Python 最好的对比语言是 JavaScript。除了函数可以直接引用这点外，我学 JavaScript 的 iterator & generator 和 decorator 都是找资料找到 Python 里去了。

@billy 是的，但 chruby 安装 gem 的路径和 ruby-install 安装的 Ruby 路径没有关系，举个例子，对于 ruby 2.2.2：

• ruby-install 把 ruby 安装在 ~/.rubies/ruby-2.2.2 下面。
• chruby 切换到 ruby-2.2.2 后安装 gem 会安装在 ~/.gem/ruby/2.2.2 下面。

附上我本地的 $GEM_HOME 和 $GEM_PATH 也许更能说明问题。

~ $ echo $GEM_HOME
/Users/david/.gem/ruby/2.2.2
~ $ echo $GEM_PATH
/Users/david/.gem/ruby/2.2.2:/Users/david/.rubies/ruby-2.2.2/lib/ruby/gems/2.2.0

@luikore 因为 ES“只增不改”的策略，有些东西一辈子都会改动了。像 switch .. when ，splice ，for .. in 都属于这种。有些以后还有少许机会推出新的语法和 API 改进，然后把老语法列入不推荐的行列。但如果对现有语法有不同看法并且不喜欢这种设计，那也确实只能一直用 compile to JavaScript 的语言了。

我以前也挺喜欢 CoffeeScript，甚至把一个写了一半的 Ember app 从 JavaScript 全部转成 CoffeeScript 了。

不过自从用了“ES2015 + 不打分号的编码风格 + 数组末尾也可以打逗号”后，我就不怎么想念 CoffeeScript 了。CoffeeScript 在我看来有几点不如 ES2015，并且以后也没法改进：

函数必定有返回值

这在写 event handler 和 Promise 时影响非常大。前者返回 true 有可能导致意外地事件冒泡，后者就不说了。有时候我必须提醒自己一定要写 return 。ES2015 的 array function 在 () =>xxx 语法下才有自动返回值，() => { xxx } 情况下不会有，这点控制得更好。

某些 ES2015 语法没法用

比如 import/export ，必须用 Embedded JavaScript 语法去写，这会导致一些问题，比如 export default class X 这种语法在 CoffeeScript 必须拆成两行。我想 async/await 语法估计也如此。

可选择的编译规则

ES2015 可以根据平台支持程度选择性地 transpile 特性，可能未来就完全不需要 transpile 了。举个例子，如果用 Cordova 开发 Android 应用并选择了 Crosswalk 作为 webview，我完全知道平台支持什么语言特性，以此针对性地关闭 Babel.js 的某些 transpiler。而 CoffeeScript 必须一直编译。老实说拿这个来比较不公平，观点就见仁见智了。

CoffeeScript 是个不错的语言，不过我觉得它已经完成历史使命了。

@qilinzou 嗯，我也喜欢源码编译安装。 ruby-install 就是源码安装的，并且可以看到全过程。其实我觉得“安装”这个词不大恰当，因为 ruby-install 就是自动帮你下载，编译，然后放到指定的目录去（~/.rubies/ruby-x.x.x）。它省去的是“手动找下载地址，然后敲命令编译”的功夫。

@rei 貌似 Turbolink 有针对 iOS/Android 的 native wrapper，看来 Basecamp 准备把它们做 hybrid app 的经验抽出来了。

至少把需求和设计思路说下吧…… 不贴代码是耍流氓，但是只贴代码也是耍流氓啊。

我只想说，幸存者偏差…… 学了新语言或者在用的可能跑到其他语言的论坛讨论去了。这里能统计的多数只有 学了新语言还在 Ruby 社区讨论的 或者是 尝试了下新语言但主要还是搞 Ruby 的 。

为什么很多段落都翻译了两遍，而且还是不同风格的？

文章很精彩，这种学习思路更值得学习。

我也觉得 at_exit 这种想法虽然巧妙，但感觉有点不正常。一句普通的 ruby xxx_test.rb 内隐藏了这种逻辑，其实倒没有单独开一个命令直观和简洁。

看完了，感觉有点奇怪。

我赞同 @jasonliu 的观点，MVC 就是一种理念，不用去纠结名词。不过我觉得为了深入理解，还是应该看看 MVC 最原始的定义。这可以反过来更好地理解设计思路，而且对理解其他框架也更有帮助。想挖挖的可以看看 Wikipedia Model–view–controller 。这不是纠结，是较真。

但要说较真吧，我觉得作者其实也不大较真，通篇其实他就在纠结 Model 2 和 MVC。这点还不如看看 Digesting JavaScript MVC。虽然别人目的是比较主流的 JavaScript MVC 的设计理念和差别，但对最原始的 Smalltalk MVC 和其他一些变种的阐述都还算比较到位。而且最后的广告植入毫无痕迹……

相比之下这篇文章结尾的广告就像电线杆子上的纸条，让人没有看的冲动……

@shinetech_wh 自家的顶一下。我不知道这是不是被谣传成“五个 HR 的公司”的，不过其中三个是货真价实的程序猿…… 还有一个 .NET 的……

+1

你的问题 StackOverflow 上都有解答，自己去搜吧。简单地来说，你该用 gulp-sass 2.x。