我有意见，我拿作者原话反驳你的观点，你为什么不去反驳作者的观点去？纠正他啊，你的框架跟 Rails 一点关系都没有

你用的不是 https://codeigniter.com/ 对吧？

是的话，你的使用感受能代表作者的观点？作者说受 Rails 影响，你说不是，你比作者说话权威？

说你是 Troll 才是嘲讽你

那是你的自由，你的项目你爱咋咋地，但是，CI 作者自己说的事，你替作者说不存在的，你这也太霸道了吧

再说了，贴出作者的言论就是嘲讽你了？

华顺怎么说的

不懂就别乱说

贴了个证据，纠正了你的错误观点：

但是 CI ThinkPHP 这类东西，尤其后者，根本就是任务型的，CI 自身也是任务型的，一点都不 OO，到处都是 this-> 的反射，所以也不至于描述得前辈你说的，太夸张了。（跟 Rails 思想几乎扯不上边）

你认为这是：

然后，你们居然还拿 creadits 来说事，然后还嘲讽我等对 rails 没有实际了解过的 PHP 居民（好比没有到过中国四川吃辣椒的外地人），好好好，你们土著民了不起。

不好意思，我就是来打你脸的

另外，我 91 年的

我们没吐槽、也没贬低过其他技术、框架，但是 CI 自己写了受 Rails 启发，作者承认的事，你不认，你算老几？

抱歉，我 get 不到你的

那么显然你完全没了解 Rails，甚至不了解 Web 开发，不过你的恶意观点是对的。

Anyway，在这里玩得开心就好

你不用跟我介绍这些框架，PHP 我写过四五年，你也不用反向怀疑，因为你根本没了解过历史。

我把话放这 Web MVC full-stack framework 是 Rails 发明出来的领域，你看到标榜 Web MVC 的框架都是受 Rails 影响的。

我这样说吧，所谓的 Web MVC full-stack framework 就是 Rails 开创的，CI 也深受 Rails 的影响

亲... PHP 的几个流行框架，Symphony、Laravel 都是 Inspired by Rails... 何况还有 CakePHP 这种精仿... 你 可别忽悠我，我 10 年那会做外包对 CakePHP 是源码级精通

Rails 的做法一直是主流的 Web 架构风格... 大前端也就是去年才开始的，你到底有多少工作经验啊...

全栈框架当然要做前端（这才是只有 dead framework 才会做的事），何况 Rails 从 6 年前就开始抓前端了，曾经 Sprockets（Assets pipeline）无比先进，但是前端更愿意用自己那套，而且技术上也超越 Sprockets 了，那么与时俱进而已

等我手头忙完介绍下吧

时间问题，主要是 sprockes 4 开发很不顺利，不过 即使在未来，前端不复杂的项目用 ap 还是很好的，无脑配置，依赖简单，webpack 的配置真是复杂

顺带一提，看似 Rails 提供了各种全家桶大杂烩，但其实所有组件都是可选并且是可替换（而且确实有可替代品）的。

Ruby 谈什么构建？编译前端 assets 发生在部署时候的。

其次，跟前后端渲染有什么关系？Webpack 是个用来做前端资源打包的，Rails 的 Omakase 的思想就是为开发时候一定会遇到的场景提供一套预制好的逻辑自洽的方案出来，所以在重前端的今天，Rails 提出了 Webpacker 来把前端工具链（这里 Rails 选择了 Webpack）集成进来。

另外有三个值得注意的点：

• Rails 6.0 前端 Assets 管理将完全拥抱前端工具链，也就是说，Webpacker 将成为 Rails 全家桶的正式成员（现在还是可选组件）
• Webpack 4.0 相比现在的 3.0 又（为什么是又。。。）要大改
• Webpacker 的开发过程受到 Webpack 几次大改版的影响，早期的设计并不好，大概是 9 月 3.0 发布，才能说是走上正轨了，所以早年对 webpacker 的看法需要重新纠正一下

我现在用自己调整过的 webpacker 替代 assets pipeline 用，其实 Webpacker 根本就不复杂，他就做了四件事：

• 提供了一组 helper 方便你在 Rails 的 view 里引用 webpack 的资源（和 assets pipeline 的对应）
• 包装了 webpack 和 yarn 的工具链到 bin，这里就是把传入的参数传递给真正的命令前做了一个依赖的检查（比如 Node 版本够不够呀，如果没装要怎么装呀）、还有传递执行环境的工作
• 把 webpack 的编译过程集成进 assets pipeline 中去（我魔改了这块使得他可以独立运作，不再依附于 Sprockets，为啥依附？自然是 Assets pipeline 还是 Rails 的默认前端 assets 管理方案）
• 提供了开箱即用的配置（比如 vue、angular 模板，又比如通过 YAML 分离了一部分 webpack 的配置）

如果你觉得 webpacker 复杂，那其实是 webpack 复杂，er 根本就是个中转代理而已

webpacker 还是面向全栈开发的，所以他把自己的目录深植于 app 目录，如果你的团队的成员要身兼前后端开发的职责，因为交互复杂需要引入前后端分离或者需要使用新的前端技术的时候，webpacker 是一个非常好，而且非常容易被接受的方案

但是，如果你的团队分工明确，恐怕 webpacker 就未必适合你团队了，但这并不是说 webpacker 不适合这种场景，而是前后端代码在一个仓库会牵扯到一个工程管理问题。

webpack 配置好复杂。。。 另外稍作配置，完全替代 sprockets 没有问题，我自己这么用三个月了，编译速度提高，时髦值也上去了，不过最近很忙，没啥精力整理分享

webpacker 就是 webpack 呀，只是预先做好了和 Rails 集成的配置而已

你想说的是 DIY Do-It-Yourself，而不是 DRY Don't-Repeat-Yourself 吧

这种风格的核心原理是 obj.instance_exec(&block) 你 google 搜 Ruby DSL 就能看到很多风格 DSL 是怎么做的了

那么你不知道就怎么说 但是他们又不喜欢 DRY ?

我不难为你了，这个 thread 留给大家评判吧

应该是 Rails app 没读到，你可以验证下

具体的原因很难解释，比如 Cap 部署时会把命令运行在 非登录、非交互 的环境下，对环境变量的使用的规则就会比较特殊。

通用的简单的方法我建议你用 dotenv-rails 来把环境变量注入到 Rails app 去

我想说 Rubinius，它 DRY 了一堆 Ruby implementation of Ruby，虽然这样效率有堪商榷，但是代码很利于学习。

那到底他们喜不喜欢 DRY 呢？

问题是你一直在评价 Ruby 啊，我主要否定你在 Ruby 上的看法，Ruby 的事，我比你懂多了吧，而你恰恰这里臆断的东西太多。

而且，你谈到

估计是 Rubyist 过于浮躁，总想着出名吧。

这是我作为 Rubyist 不可以接受的。

再说 Java 还有别的语言、技术，你怎么知道我就不懂 Java 呢？你怎么知道我不会点别的呢？就说你搞 iOS，国内唐巧虾神喵大，国外那个 Chris，我和他们谈笑风生

我的 style 明显就是喜欢重复制造齿轮，你会发现我的代码中很多冗余的实现，实际上很多余，很没必要，实际我是故意这么写的，我就不用社区包，我就希望我把整个世界重新写完。

你刚刚不还提 他们又不喜欢 DRY。 你这个 style，DRY 么？

你既然认同自己 还不够了解、才刚接触 那就 少臆断，不懂的可以多提问

你看看你自己从来这边到现在的回复，对技术的评价都是个啥，我在跟你的邮件里也指出了这个问题，你现在才承认

那是因为你对 GIL 一知半解，GIL 对应用的影响本来是面试题里死记硬背的东西

我没有辩证 YARV 不差，我只是在回答你的问题：

【指令级内存操作】我指的是 Jazelle 可以通过指令集级别去进行优化中间代码，Ruby 好像没这个玩意吧，YARV 能跟它比吗。

另，我有 R 大微信，之前教育过你 GIL 的那个曾是 R 大的室友，其实我们都是认识的。

搜了下 Jazelle 这玩意不就是 JIT 么？不过是输出专有硬件的指令集去，Java machine、Lisp machine 都是有特定历史原因的产物，这些东西有多少是做到大规模应用的？

另，说到 JIT，Ruby 其实也有 JIT 的实现 IBM 给做的，本坛也有介绍 Ruby + OMR JIT 简介

另外 mRuby 的 JIT 就要完成了，这就是官方的了