后悔没有好好做需求分析，虽然 Rails 是非常耐改的，但是用户，PM，UI 和在一起变需求，还是很够喝一壶的。

webpacker 没啥问题，可以学 Rails 6 稳定版本，webpacker 固然有坑，但是新的 bundler-css/js 坑一样多，而且有些不容易查到解法。。。

啥？你前端能自己搞定？那你肯定已经不用学 Rails 了，我现在 80% 时间都在搞前端。。。

其实Boring rails才是真的，觉得 Rails 是 black magic，可能还研究不够深入吧。。

我其实很不能理解为啥那么多 Rails 项目会升级那么困难，你每天 bundle update 一下，解掉每天升级的 gem，永远保持最新其实是相对轻松的一件事。

Rails 社区应该趁着最近 low code/no code 大火，顺势宣传一下，宣传要点：

1. “no code == no place maintain (code)”，所以还是要选 low code。
2. “low code != no lockin”，所以还是要选社区的，非商业公司锁定的方案，比如 Rails。
3. “Rails 可以扩展为 400 亿的 Shopify”，所以放心用。

7.0.0.alpha2 的一堆之前累积的deprecations还没移除呢，sprockets 也是，autoloading 也是，所以严格来说，这版本都不算 7.0，应该是 6.2，兼容性当然好。。

后面出的 beta 才是真正的 Rails 7。

我用SQLPro studio，Mac 原生。

我心中的全栈是没有短板，后端能和专业后端比，前端能和专业前端比，其实这个要求很高。

我用了 5 年 touch bar，我觉得其实挺好的，新的 MBP 结果 touch bar 砍了，重量也重了，模具也丑了，所以不准备买，准备等下一代再看看。

turbo 其实真的不错，Rails 7 即将首发，也经过一年打磨了，turbo_frame_tag 甚至可以说是指哪打哪，而且还可以一个动作更新页面的多处地方。htmx 我随便看了一眼，兼容 IE 11 其实在 2021 年 11 月，微软都放弃了的情况下，只能理解为固步自封。现在哪个框架发新版本，还支持 IE 11，我第一个放弃它。

UglifyJS only works with ES5. If you need to compress ES6, ruby-terser is a better option.

https://stackoverflow.com/a/68815609/262826

嗯，还有一个索引网站：https://stimulustoolbox.com/

说 Rails 慢我也就勉强认了，说 Rails 吃内存的就有点过分了，2 核 4G 跑 4 个 Rails 服务，占用内存不过一半，JVM Spring 能比？gem 内存泄漏的问题，其实只要保证所有 gem 都是最新版就好了，历史上的泄漏都解了，社区都有一个网站专门说这个问题：https://www.rubymem.com

花旗养老不如微软

面基面基！

react 现在前端标配，Rails 都得学。。。

也不一定，用 Bootstrp 也可以长的不一样的，但用 Bootstrap 不就图的省力么。。

同推荐 bridgetown，虽然自己还在用 10 年前的 octopress ...

bootstrap 3 在 2021 年有点陈旧，https 现在是标配了。

我观望中，暂时还是用 webpacker 方案。个人感觉 webpack 5.0 还是 JS 世界的王者，Rails 一向是标新立异的，官方推 import map 也可以理解。

可以看看mrujs

我也掉了一下，不过我爬出来了，webpacker 6.0.0.rc1 + webpack 5.0，终于吃上了！

内容细节不够，我怎么感觉只完成了 30%。。。还是感谢楼主分享

起初没有示波器就不能拍 Maker 视频，后来做不出小电视就不能拍，再后来得 17 岁高中才能拍，现在得撑起 Open Source 才行了么？

太卷了！

很少写类型判断，都是从数据库，从 json 格式上都解决类型问题，或者本来写的就是多类型通用的。

这个问题基本等于问你的月薪是否超过 18000。

ruby 不适合做大规模企业级开发。

其实 ruby 不适合做大规模企业开发的原因是，你很难招到 500 名 rails 开发，github 也不行。

With over 1000 internal developers bringing a diverse set of skills and operating in a wide range of technologies, it’s become clear that we need to fundamentally rethink how we do software development at GitHub.

面基面基！

大而全的保姆式框架，虽然面面俱到，你刚开始会用的很爽，但是对你的束缚也是真真切切。我们应该明白，任何一个软件、程序都有设计目标，功能范围。如果你在他的设计目标里使用就会如鱼得水，但是如果你超越他的设计目标，你就不得不要和这个技术框架做对抗。要去 hack 他的设计，组件。最终你会碰钉子—— 你会发现还不如从头自己来。

这两年我一直在试图突破 Rails 的设计，但我发现手头的项目好像没有啥独特的设计需求。。最近用了u-case，倒是不错，是 Rails 体系的一个好补充。

一出来就用了，但是当 Ruby 2 用的。（和我类似的点赞即可。。）

具体感觉，嗯，内存占用变大了一点点。。。🤦‍♂️

Web 复杂性越来越高是可见的，浏览器能力越来越强也是可见的，但是简单页面前后端一体的确是在总开发时间上是省的，但奈何现在有些 Web 应用的有些单页复杂性往往会非常高，在这种复杂度下，用一个好的前端框架，后端出 API 的整体复杂度相对可控一点（至少可以完全拆成两组人一起干）。

所以大前端的方向没有错，我觉得有错的是想把所有网页都用一个前端框架搞定，这即使是可行的，内存也太容易起飞，放弃用户切换页面就重新载入的后端路由后，也有较大概率导致浏览器内存泄漏，采用这样的架构不是很明智。