实际上 GoRails 上也有一讲涉及到部分应用 vue 的（标题应该是谈如何用 vue.js 解决含有 nested attributes 的表单渲染），我个人也是倾向大部分场景都可以这样做（其实就是把过去 backbone.js 或者类似的前端 MVC 换成了 Vue）。

我最近经手了一个项目，又要兼顾 SEO，又要搞前后端分离，搞到最后变成 Node.js 做了一个动态站（Nuxt.js）然后数据通过调用我的 Rails API 获取，要我说这是一种很扭曲的架构

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

我原话，Rails 开创的是什么？Web 领域的 MVC 结构的 全栈 框架，这里涉及细节了？

看看 CI 现在的结构

这就叫 Inspired by，说实话，CI 源码我读过，起码路由和 ORM 的架构上，原理上还落后 Rails

这才是思想，一个框架需要解决哪些问题。至于实现细节，从来都是因地制宜的，次要的。

这些是什么鬼，说得好像自己站在这种拿着人家的文案就像是诠释了全世界一样的，CI 你用过几年，有几个项目用它写？

CI 用过几年... 我说我大学靠 CI、靠 CakePHP 私活挣了几万，我第一份工作就是写 PHP，读大学的时候我对 PHP 5.7 之前的掌握成都，我就是敢吹这牛逼，我当年读书的高度已经在那了，现在我比那时候经验还丰富，对 Web 架构的理解比读书时候透彻多了。

哦，其实我给学校做项目的时候 Java、C# 也还算写过一些的。

吹牛逼谁不会啊，上代码啊，比比 Github 项目的引用数量？比比业内的声望？你在哪高就？

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

所以，作者的观点可以被你的意志转移了对吧？你的资本在哪？

为啥冒火，你都 你们土著民 了还不许我发火？你当面敢这么说不抽死你丫挺的

那好啊

嘲讽 在哪里，你们土著民 哪里了不起

拿作者的观点来反驳你的观点，这叫“嘲讽”你？！

你的语句哪里有毛病？

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

这是不是你原话，嘲讽 你们土著民 是不是你说的

我有意见，我拿作者原话反驳你的观点，你为什么不去反驳作者的观点去？纠正他啊，你的框架跟 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 呢？