如果禁用 AP 并且不用 Webpacker 或者其他关联前端工具链的方案的话，你就只能把编译好前端资源放到 public 目录下了，这个就是 Rails 3.1 前的做法，目前 Redmine 这些上古项目也还是这么用（貌似）

https://ruby-china.org/topics/37017

趋势吧，不过 docker 镜像的作者要正确制作好

Heroku 貌似被墙，RubyChina 的服务器 UCloud 赞助的，在其上用 Docker 部署

那您考虑与时俱进下吧...

如果 State 不依赖 React 简直完美，那作者对富文本编辑的现状思考很多啊

跟 @hooopo 研究表单数据存储的时候，第一条优化这个

都 8012 年了... 咱就忘了 win7 吧...

内存需求肯定少多了，计算性能没做过对比但应该半斤八两，WSL 的 IO 性能会差些，没关注后来改进没有

哦，微软在 Win 上实现了一个东西来支持 Linux 的 syscalls，也就是说让 win 能理解 x86 的 elf 格式，差别在于，静室实现的方式（规避 GPL 的法律问题）不可能 100% 复制 Linux 内核行为，但这都 8102 年了... 绝大多数流行程序都被社区检验过兼容性，包括 docker 好像都支持了。但是 cuda 这种涉及内核扩展的不行。

你说什么原生支持

他这个 precompile 还会先启动 sprockets 这个耗时还是挺久的

回头我写过帖子吧

另外完全剥离 Assets Pipeline 用 Webpacker 处理前端资源后，部署时前端的速度提升明显，assets pipeline 熟悉不直接支持力度 es6，样式 sass-ruby 停止开发，sassc-rails 缺乏维护，长期看还是堪忧的

相比 trix 更喜欢 quill 一些，现代富文本编辑器，不直接产出 html 或者 md 而是中间格式，这个好处很多

看了眼 Webpacker 的提交记录，感觉 Basecamp 团队又接管了了啊，接近半年后 Pre3 发布了

即使是传统 Server side rendering 也一样可以用 yarn、npm 来管理前端资源，Rails 在 5.1 开始 可以 Yarn 包管理+Assets Pipeline 引用资源。

现在争议比较大的是要不要全盘前后端分离

看了下应该是 docker 的问题，底下的讨论看所有的包管理工具都有可能触发这个问题

那也是 NPM 的问题了吧，归到 Webpacker 上倒也没没错，不过我觉得这个问题应该不会在 Webpacker 这层去解决的

Webpacker 3 开始没啥麻烦的了，但是 Webpack 这套和 jQuery-based 还有老式的 JS 模块化风格的库配合起来要搞好多配置 而且未必能用。比如我直接问你的 Selectize.js 怎么能跑起来

这个以后也解决不了，所以更大的问题是更新前端技术栈适配新时代

Rails 6 发布还早，年底或明年初 Alpha 了，时间还有，而且 Webpacker 本身做的事情并不多，所以还是可以观望的。

我是本来希望等 Webpacker 4 出来（Webpack 4 + Babel 7）在动手做个前端的东西，所以每周都关注他们的进度

Webpacker 的维护者似乎不在 Basecamp 去创业了，4 目前看是难产状态，维护者在一个他在做的时间很久的 WIP PR 里表示近期也没有精力来搞... 这个比较意外

这个触发流转动作没难度，表单这块 @hooopo 去年就在他们那用上了，前后端分离+GraphQL（他欠了我很多稿子

我跟 shopify 的人聊过的，ess 他们生产在用是没错的，至于 mruby 那边，你看过 shopify script 和 ess 用法对比会发现他们肯定是有一套扩展库在里面。我也苦恼了很久在里面，直到我发现，ess 的测试用例都是他们的真实脚本，那么我逆向了他们放在项目里测试用的 mruby 字节码，我就知道了他们是如何设计标准库的。

另外 ess 极其小众，维护这个项目的人几乎不处理社区的 issues（bugbounty 除外，但其实那些修正最终都是提交给 MRuby）。

这个项目我憋了很久，因为 ess 最初的许可证是专利，在我询问半年后回答我他们忘改了...等上游改正后我才大胆的公开我的版本

我已经改了一些东西了 还有一些半成品

好啊，用得时候有什么问题建议随时骚扰

其实就是上周才动手写的

AR 的对象有一个 become 方法～

enum 也可以是 string

加精促进下 SEO，话说安装 Redmine 在淘宝上也是个产业了...