瞎扯淡 Stimulus + SJR + Turbolinks 真的超级好用
之前一直前后端分离，偶尔写写 react,
最近因为想偷偷懒，小项目就还是走了 rails web 端，
现在真心 rails web 端改变了很多，
webpacker 解决了以前绝大多数前端库问题。
以前特别迷信前后端分离，后端 rails api, 前端 react, 干啥先上一套全家桶，
现在再来看，中小型项目其实用 stimulus 来写也非常方便，stimulus + sjr + turbolinks 一样效果非常好，
关键的是操作一点都不复杂。纯粹的 js + html + ror 知识。
原来觉得 js 生命周期啥的不好控制，现在看准一块，写个 stmulusjs controller 隔离出来，在小范围随便瞎折腾就好。
当然也不是说 react 全家桶不行，
在复杂界面上，我觉得 react 还是挺好用的，
关键是怎么定义 "复杂" 界面的概念，
在状态变化低于 3 个左右的一个界面中，使用 react 我觉得反而不如 timulus + sjr + turbolinks 方便
另外我以前的误区就是 要上就上全家桶，啥都还没干，先搭前端项目架子。
其实很多时候并没有想明白为啥要上全家桶
react-router 在非 app 类 web 的情况，完全可以使用 server 自身的路由，
redux 在组件关联性少的情况下，作用不算太大
在逻辑复杂的地方，单独引入一个 react 控件即可，在 head 里加载一下 react.js , 处理具体的某个节点，也不算丢人
未必就非得 body 底下插个空 div 纯 react 网站
cqcn1991
回复
"在状态变化低于 3 个左右的一个界面"
这是我自己的一个使用惯例
就是 一个 UI 模块中，有包含 3 个以上的状态，任何一个状态的变动都会引起新的 ui 变动
其实这个的定义是来自 react 的本质，就是 数据 决定 UI,
比如登录窗口 一个地方，有 用户名 清空 有 密码控制显示 有没填写密码警告 没填写用户警告 , 这种状态就比较多 (>3), 比较复杂，用 react 组件写，逻辑就比较清晰，只需要关注 state 就好. 当然 你用 stimulus 去操作这些也可以，只是会疲于在各个 dom 里去隐藏或者显示啥的，比较麻烦一点 逻辑中混用的 ui 操作比较多
但是类似于 点击后加载一个数据，或者点击之后加载个报表，点击之后读取 搜索条件 去搜索 这种状态就只有加载和未加载，直接上 stimulus + SJR + turbolinks 就特别轻松，无脑写就好
我觉得 Elixir / Phoenix LiveView 比起 stimulus + SJR + turbolinks 更加简单好用。问题是 High Latency 情况下怎样处理我还没有时间去研究
Stiumlus 是 Rails 前端最后一块拼图：以服务端渲染为底，轻型交互用 Stimulus，重型交互用 Webpakcer + 任何前端框架，可以满足大部分的需求。
webpacker+stimulus+jQuery 确实不错，小步创新，用的舒服，jQuery 可以去掉，但是目前我用 bootstrap 4，依赖 jQuery 的，不用白不用啊。。
用过一段时间，没有想象中的好，比较鸡肋。
简单应用，用不用 stimulus 区别不大，大不了把 turbolinks 去掉，省的调试起来麻烦，还要写模板标记。
复杂一点的，由于担心越做越复杂，估计都会考虑用 react 之流。
nine
回复
stimulus 和 turbolinks 本身都是轻量的框架，但是组合起来实现了 SPA 类似的体验，并且可以重用服务端渲染的很多优点。为了可能的复杂性直接上 react 这类框架，相对需求本身往往增加了巨大的复杂度，在我看来很多应用都过度工程化了。
Rei
回复
了解，我也是一直想把 Stimulus+Turbolinks 用起来，但是一直也没有找到合适的使用场景，可能新闻站、博客、论坛这种会比较适合，但是除了个人练手，现在哪家公司也不会花人力重头写一个这样的应用。做活动页模板的话，通常也不需要后端或者全栈的参与，主要是前端在工作。做后台应用的话，就是复杂项目了，这本身也是 Rails 拿手的，然而复杂应用的前端，可能就要上 react 之流会合适点。
至于复杂，前端现在确实很恶心，但可能也没想象的那么复杂，可能只是 Rails 社区对前端研究不多，不太会组织资源。
nine
回复
我觉得后台界面就很适合 Rails 开发自己做，前端人力一般不会用在后台上。不知道别人系统怎么样，我遇到的后台交互都比较简单，但是简不简单可能在不同人眼里不一样。
像 @jasl 一直问我有没有兴趣用 stimulus 做个后台 UI 库，我觉得用不着，按具体场景自己写就好了。然后他给了个例子，支持 nested field 的交互——一个 nested form 表单，点击一个按钮增加一列子级表单的内容。这个交互还有人做成了 gem（https://github.com/nathanvda/cocoon），但用 stimulus 写，核心 js 代码其实就十几行（https://www.driftingruby.com/episodes/nested-forms-from-scratch-with-stimulusjs）。当然写成 gem 的附加功能多很多，例如很多钩子方法，但是自己写根本不用实现这么多附加功能。
总的来说，我觉得简单和复杂在很多人眼里不一样，很多人高估了复杂度。
Rei
回复
嗯，主要还有一点原因比较重要，忘了写了。
是作为一个从 IE6 一路 hack 过来的伪前端，SJR 我一直用的不是太顺畅。SJR 把很多东西划分的太碎了，控制起来太费劲，需要记忆和查找，修改后容易相互影响。Stimulus 虽然把 js 作用域分开了，但 CSS 还是没有解决（因为它诞生的目的也不是为了解决 CSS 的问题），而且多了 SJR。
这样 JS，HTML，CSS，SJR，就分别散落在各个角落，支离破碎的感觉，很糟糕。
而组件化的颗粒度是我想要的。把 CSS JS HTML 封装到一个组件（甚至文件）里，而组件之间样式、行为互不干扰，修改微调起来相当方便，安心。
monsterooo
回复
我是用 stimulus 解决了以前困扰我的各种 turbolinks 的问题 以前遇到各种重复绑定的，现在都靠 disconnect 解耦
没用透
Rei
回复
项目很久了，没线上 demo。不过打算新项目的后台使用这套组合，如果一套由 Stimulus + SJR + Turbolinks 写的类似 iview 的东西，那就牛了···
Escaping the SPA rabbit hole with modern Rails https://medium.com/@jmanrubia/escaping-the-spa-rabbit-hole-with-turbolinks-903f942bf52c