Rails, Hotwire + Lit 。

Monolith First https://martinfowler.com/bliki/MonolithFirst.html

> 当我听到有关团队使用微服务架构的故事时，我注意到了一个常见的模式。
>
> 1. 几乎所有成功的微服务故事都是从一个变得太大而后被拆分的整体开始的
> 2. 我听说过的几乎所有从头开始构建为微服务系统的系统最终都陷入了严重的麻烦。
>
> 这种模式导致我的许多同事认为你不应该用微服务启动一个新项目，即使你确信你的应用程序足够大，值得这样做 。

推荐 https://lit.dev/

建议看 DHH 去年的演讲：no build

https://www.youtube.com/watch?v=iqXjGiQ_D-A

技术发展不应该一直叠加复杂度，随着发展回到平台原生是更好选择。

用 Pro 模式 https://post.smzdm.com/p/a8pzz2x6/

关动态模糊。

增加一个 Mobile App Backend ，统一处理 App 发起的请求和维护后台配置，解决问题并且增加就业。

14 pro max 用户被恶心到了。

共用省资源，独立好维护。

@enchilada2020 Node 近十年的强势在于前后端分离，即使前后端都用 Node 但也是基于不同的框架不同的思维，用 API 来跟前端沟通。

近今年出现真正的全栈 Node 框架，例如 Next.js 和 Remix 。最近 Next.js 因为 React server action 引起争议，被嘲讽终于追上了 PHP 。我觉得 Next 把整个应用都放在 React 的抽象层里很有勇气，也可能会遇到很多问题，我持观望态度。接下来 Node 社区可能会分裂为前后端分离和全栈两个派别。所以我觉得 Node 的全栈其实还不成熟，未来还需要踩很多坑。

Ruby on Rails 今年 20 周年，确实热度下来了，新人寥寥无几，但是坑都被踩得差不多。7.0 版本终于把前端梳理好了，可以用上前沿的 importmap 期待未来的 turbo 8 （ Morphing ），进一步改善前端的开发体验。不喜欢 Rails 默认栈也可以换其他主流前端工具，jsbundling 方案可以灵活适配。

使用无聊的技术反而有利于生产力，因为不用去踩未知的坑，更多精力花在产品上。

Choose Boring Technology https://boringtechnology.club/

“其他”包含了国外的测试点，会拉低平均，把“其他”去掉。

@enchilada2020 Python 的框架没有全栈的野望，Node 在全栈还有很长的路要走。

如果有志于往全栈发展，那应该看 https://rubyonrails.org/ 框架。因为它是为数不多的 The One-Person framework ，而不是 Part-Stack Developer 框架。

今年的 Rails World 演讲：

https://www.youtube.com/watch?v=iqXjGiQ_D-A

Turbo 标语

> The speed of a single-page web application without having to write any JavaScript.

https://turbo.hotwired.dev/

使用 Turbo 的功能几乎不用写 JS ，Turbo 也不会阻止你的代码用不用 TS ，不知道激动啥……

想起 Atom Editor 1.0 的宣传片

https://www.youtube.com/watch?v=Y7aEiVwBAdk

别吃蘑菇，因为有菌。