正好相反，从实现原理上说，Hotwire 比 React / Vue / Augular 简单多了。

可能是 turbo 和 stimulus 有太多和 DOM 还有 HTML 相关的东西，但现在的前端框架其实完全不 Care DOM、几乎不会 care HTML。就不太熟悉这俩。

还没用过。这个有类似 ant design 和 element ui 的东东吗？

Hotwire 本身并不复杂，跟前端相比简单非常多。Hotwire 本身是服务端渲染框架的一部分，跟服务端耦合非常紧密（因为本身就是全栈框架解决方案的一部分）不会有一个人专门写前端。换句话说用 Hotwire 就不是给前端工程师用的，要目的让使用者一个人完成一个 end to end 功能，尽可能少写 js 又能达到接近 SPA 的体验 (hey.com 的 js bundle 只有 40k)。

所以要用 Hotwire 就要会后端，后端知识 + 非主流前端的知识（其实经历过 jquery 跟 backone 时代的就还好）在新生代前端工程师看来就会复杂好多好多好多。。。。。。。但是对于已经有全栈基础的人来说（会后端，会基础 css+javascript），学 Hotwire 比 react/vue 生态轻松非常多。

现实情况是大家都提倡分工协作，全栈方案会越来越小众，所以 Hotwire 也注定不会很流行，只适合爱折腾追求单人工作效率的小团队。

我觉得不是复不复杂的问题，主要是没必要。这几年 nodejs 和 typescript 在海外发展非常迅猛，Prisma 作为 ORM 我觉得比 Rails 还要高效，而且 JS 前后端统一语言也有助于开发者在心智上更容易成为专家

并没有更讨厌 反而很喜欢 尤其是 esbuild + turbo

不会复杂啊 反而简单了

我前端开发了几年，更熟悉一些，就一直用 rails api+ react, 哪个用起来利索就用哪个，本想着再学学 Hotwire 和 Turbo，没时间精力学了。

我就是这样的，不愿意用 Hotwire 了

React/Vue生态在，我们也放弃Hotwire了。

没有，没人开发。其实相当于很多组件都要自己去开发。DHH 这类开发能力强，公司有专门的设计师，可还具备产品意识的人自己开发可能觉得没什么。但是我们日常可能还是脚手架直接堆逻辑的场景比较多，有良好的技术生态圈，能够减少自己造轮子的窘境。

PS： 用惯了组件库，突然裸奔的感觉真的很无助。

我觉得是国内的一些网站，特别是中后台，对复杂的前端组件无节制的依赖，导致最后你如果不用 React / Vue 这种声明式的库，就会特别难做，一个组件能开发你小半个月，还一堆 bug

Turbo + Stimulus 其实最大的痛点就是缺乏现成好用的组件库。我的选择是基于纯 CSS 库（bulma 和 weui）扩展和慢慢积累，感觉也就那么回事：https://github.com/work-design/rails_design/tree/main/app/javascripts，目前已经进入了一切尽在掌握中的阶段和感觉中。

从实际开发体验来看，每个组件用的 js 代码都蛮少的，大都几十上百行就解决问题了。以前的 UI 组件库，如 bootstrap 动不动一个 js 文件就上千行，让我很难理解。基于 Vue/react 的组件库就更复杂了吧

基于纯 CSS 库开发，最大的优点就是很容易 override . 我想这里的 vue/react 大佬们，如果基于 vue/react 组件库，UI 层面的 override 好搞么？

感觉楼主可以展开说说。

Rails 的开发者多数是后端或者是全栈，所以他们看问题，多数是从后端或者全栈的角度来看的。

但前端有前端看问题的角度和方法。所以具体聊聊，可能会很有意思。

和老哥差不多的方案。

表单多的页面需求，我会再加个 alpinejs，都比较轻量级，一切在掌控之中。

其实就是现在的新时代的前端，没怎么深入了解过 DOM 和 HTML 之类的，All in JavaScript 解决问题。但 Hotwire 这一套感觉和这些知识结合的很紧，所以都不太适应，如果是在 DOM 时代的前端可能觉得没啥。

总结下来是不是

1. Hotwire 依赖 DOM HTML，对新时代前端不友好
2. 导致上手成本高

hotwire 本身就不是给前端用，是全栈的神器，前后端分离的话就采用 api 模式。另外一个就是前端觉得 hotwire 难，其实是后端对他来说难

我没用过 hotwire，对这个技术也没做过研究，所以没有办法对此给出任何评价。

前端可能有自己的想法，有可能是觉得难，或者觉得没有学习的必要。不过这个还是前端来说比较好。

你这话说的 。。。毫无道理、武断、不客观，充满了主观臆断，无理无据。还顺带踩了一脚前端同学，透露出一股莫须有的“全栈优越”。

反对前后端分离 https://williamkennedy.ninja/javascript/2022/05/03/in-defence-of-the-single-page-application/

全栈是殊途同归，不信请看：

https://staging-cn.vuejs.org/guide/scaling-up/ssr.html

什么是 SSR？

Vue.js 是一个用于构建客户端应用的框架。默认情况下，Vue 组件在浏览器中生成和操作 DOM 作为输出。然而，我们也可以将相同的组件在服务端渲染成 HTML 字符串，直接返回给浏览器，最后再将静态的 HTML“激活” (hydrate) 为完全交互式的客户端应用。

一个由服务端渲染的 Vue.js 应用也可以被认为是“同构的”或“通用的”，因为应用的大部分代码同时运行在服务端和客户端。

区别是你愿意用 JS 全栈，还是 Rails 全栈。

作为一名 Ruby 转前端的菜鸡，我觉得 HotWire 相对现代前端来说本身并不算复杂，同时 Rails 在前端这条道路上的探索历程也很值得现代前端 er 们学习和反思。但仔细想想，一方面把这些东西写在简历上似乎并不如“有过后端开发相关经验”更加分。另一方我觉得“为什么现代前端一定要用 React/Vue 等框架却不肯尝试 HotWire？”这个问题似乎与“为什么国内用 xxx 语言做服务端的公司很多而用 Ruby 的公司却越来越少了”没有什么本质的区别。。。

没用过就对了，用了就知道咋回事，全栈的里面目前来说最优的（减少开发工作量）解决方案，前后端分离不考虑

扣帽子的名词那么多，有精力多了解一下技术相关的东西，别把心思弄在这方面。了解 rails7 的知道我在说什么

就我个人来看 hotwire 这一套 确实有很超前的地方，但是换一角度从团队和工程化的角度来看，vuejs 和 react 就我来看，他更适合。java 不是一门好语言，但是就团队工程化生态等等来评价，毫无疑问在国内它可以排第一

额……你要想说 hotwire 好，需要对比类似的技术方案，以及对比前后分离的方案，还有这个技术的试用范围。

如果是喜好，自己喜欢就好，喜欢什么好，大可不必让别人认同你。

你认为好的东西，别人可能连了解的想法都没有，但这并不影响你喜欢。

但要想让别人认同，就需要给分析了。

本前端是觉得没必要学，脱离 dom 才能走入更多平台。不过为了保持敏感度一般会了解一下

我下一个判断，前端以后会随着浏览器原生技术的发展，API 会越来越丰富和完善，各种语义化的 HTML 标签会越来越好。像下拉菜单、弹出框等各种常用的控件以后都是会有的。随便举几个例子，比如说

• 日期选择器 <input id="date" type="date"> 现在直接浏览器提供了，不需要额外的 JS 库了。
• 表单验证现在也越来越完善了，甚至都自行定制验证消息了。

像现在这些很多客户端 JS 的很多控件库，以后都没有人用了。有些 React 库，一个小小的控件文件，点进入一看，都上几百上千行代码了，我一点兴趣都没有。

我哪里说好了，我说的是 hotwire 针对场景和用户，是给全栈而非前端

全栈的里面目前来说最优的

stimulus 挺香，简单易用

turbo 初看有点晕，把工作原理搞清楚也不复杂的

我是用 hotwired + tailwindcss，丢掉 ui 框架，非常灵活，效率也不低

人家上来都是历史分析 + 用户群体分析 + 原因，你上来就“不是给前端用的，前端觉得难是因为觉得后端难”你这不武断、不拉踩吗？前端现在很多都要写 BFF 层的好吧。

国内组件库还是盛行于中后台网站啦，比如最火的 antd、element ui，而更具 2c 产品气质的 Material UI 反而国内没什么人用。

我以为可能是国内好多中后台开发的产品经理对于组件有着毫不节制的复杂需求 不用组件库就做不完了

这个有道理的，看起来目前的前端团队好像分成了两波：

一波人做多端打通，一组前端能够同时产出多个平台的客户端，比如桌面用 electron，移动用 React Native。

一波人做前后打通，前端同时负责 BFF 层和前端，也就是所谓的大前端，这种组里的后端就彻底下沉到基础组件去了。

其实还有一拨人，是在面向超出桌面，移动端的方向探索 (并不是一套代码产出多个平台), 比如在 hololens 上用 react 开发，虽然用的还是 react native, 但是 UI 的设计和交互语言和平面的完全不一致，不会用一组代码了。建立了 UI 层面的抽象才是 virtual dom 最靓的点

回答一下"Hotwire 依赖 DOM"的问题：答案是否定的。 Hotwire 的核心是 Turbo，使用 Turbo 不需要写 javascript，所以也不依赖 DOM。

The heart of Hotwire is Turbo. A set of complementary techniques for speeding up page changes and form submissions, dividing complex pages into components, and stream partial page updates over WebSocket. All without writing any JavaScript at all. And designed from the start to integrate perfectly with native hybrid applications for iOS and Android.

所谓依赖 DOM 的是 Stimulus，但是 Stimulus 只占 Hotwire 非常小的一部分

While Turbo usually takes care of at least 80% of the interactivity that traditionally would have required JavaScript, there are still cases where a dash of custom code is required. Stimulus makes this easy with a HTML-centric approach to state and wiring.

Stimulus 在 Hotwire 中是可以被 react/vue 等前端库替代的。Stimulus 本身就很轻量，也不难，是 Hotwire 需要的功能的最小集。

Hotwire 还有一个重要模块是 Strada，Strada 是 Hotwire web 应用可以转换成 hybrid 的 mobile app，加上 Strada 才是完整的 Hotwire，一套代码可以应用在 web/ios/android 三端。（但是一直跳票）

Hotwire 不仅不依赖 DOM，还是一种减少 javascript 使用的开发模式。

DOM 不是什么见不得人的事情，就好像一个人只用 ORM 不关心 SQL，我会怀疑他能否写出高效的查询，遇到问题能不能自己解决。

不依赖 DOM 是事实，无关好坏。

alpinejs 和 turbo 集成现在还有问题么？开始用的时候，这两样集成一起，不好用

没用 Turbo

rails 本身的定位

语义化标签会越来越面向功能，而不是传统 dom

感觉某些 railser 挺鄙视传统的前端方案 前后端分离 单页面应用 Vue React 这些的