[poorman]

Stimulus and Hotwire are the "rails way" now. I've read the docs and they still confuse the hell out me. Seems like you're reinveting your own javascript components over and over again.

In my opinion Rails 8 + Intertia.js + React so much less "reinventing the wheel" (especially if you use shadcn components).

[0xblinq]

This. We replaced Hotwire frontend with Inertia and it's night and day.

Unless you work 100% alone (and for a smallish project) hotwire leads to a real mess nobody can work on way before anything else I've ever seen in my life.

[padseeker]

this ^^^

I've used turbo/stimulus/hotwire. It's best suited for STATELESS interactions withe the browser/web page. The problem is not all desired user experiences and use cases are stateless. And the ecosystem for hotwire is a minuscule fraction of all the other popular js frameworks.

If you're searching for inventory available its perfect. However if you want to update one thing based on the most recently touched input it becomes more complicated and in all honesty more trouble that it's worth.

Honestly if you're a solo Rails dev, use whatever you want. However the React ecosystem, and really all of the other popular JS ecosystems (vue, ), are very strong and you have so many available options. Stimulus is 2 steps back from jQuery, it inverted the Event delegation pattern. No one else outside of the rails community is using it.

[hahahacorn]

I think the fundamental misunderstanding (for the majority of devs who dont "get hotwire") is that you can very often delegate the statefulness of a given interaction to A: The Server via the database or B: The Browser via localstorage.

If your page can be written with it's state being "reasonably" delegated to one of these two, hotwire is _all you need_. (To be clear, it's more common that you're just doing a bunch of work to duplicate state that already exists in the database/on the server, or handled natively by the browser, and by "delegate" I mean don't-duplicate-for-no-good-reason.)

There are many (but fewer than those who "don't get" hotwire believe) cases where it's more of a headache to delegate state to A or B. In which case you should absolutely pull in react/vue/<insert_js_framework>/etc. My go-to is: https://github.com/skryukov/turbo-mount + react because it minimizes it's footprint on the "omakase-ness" of your rails app.

[digianarchist]

Stimulus is basically a very small event system with HTML hooks that integrates well with the Rails request lifecycle. I'd love to know if anyone has built anything sophisticated with it because I found it difficult to do anything remotely complex.

[madebylaw]

What complex thing were you trying to do with it?

[digianarchist]

Anything that requires state syncing between client and server.

[rco8786]

I'm a huge rails fanboi but the state of Stimulus and Hotwire make me sad. The concepts are awesome, and I think the execution might even be good. But the documentation is so incredibly horrible that I have a hard time even getting started, and I can't learn enough about it to answer the question of whether or not using it in any given project will end with me painted into a corner.

[matltc]

I feel so validated! When I started learning web dev, I was working through The Odin Project's Rails course. All smooth sailing til I hit the Turbo/Stimulus/Hotwire sections.

I thought I was stupid or just terrible at JS/front-end stuff, because I would read and re-read the same chapter in the Stimulus docs and become more confused.

Now I'm mainly in TS-node/React land, and boy do I miss Rails.

[troad]

Going against the grain here, but I liked Stimulus so much I lifted it out of Rails and plopped it into a Phoenix app.

I think the problem here is a disconnect of assumptions. Stimulus isn't meant to be an alternative to React.

If your app is (tens of) thousands of lines of JS, and that is all you know a web app to be, then React may be a sensible, battle-tested approach for you.

But if all you need is a few dozen lines of JS to polish the UX of an overwhelmingly server-side app, then Stimulus is a neat way to encapsulate and surface it when desired. In Phoenix, it slots nicely between static HTML views and dynamic LiveViews.

I don't think anyone has ever suggested you should use Stimulus to try to replicate a SPA, and I imagine you'd have a very bad time if you tried.

[conradfr]

I use Stimulus with Symfony for small interactions and I quite like it, small and well designed api IMHO.

Didn't try the whole Turbo/Hotwire thing though. I usually use Vue for complex pages / need of state.

[baggy_trough]

Personally I'm liking Rails 8 + Tailwind + Stimulus. No node.

[skinnymuch]

Are you familiar and adept with React/Vue/Svelte? I haven’t looked at Stimulus or Hotwire much yet. Just picked Rails up again a few weeks ago. Tailwind and Shadcn (or similar ui) are standard for me now.

[baggy_trough]

No I'm not. I've been happy with a server side rendering approach with a few interactive sprinkles from Stimulus. Tastes great, less filling!

[0xblinq]

That's the only good reason to use Hotwire. Being a JS hater.

[dismalaf]

You know Stimulus is for writing JS, right?

[0xblinq]

Yes. It's also recommended to not use much of it and do almost everything else with turbo drive, or turbo frames, or with turbo streams, or with whichever convoluted magic you can do to avoid it until you can't anymore. Then you use Stimulus. Yes, I know it.

The fact people can't escape JavaScript doesn't stop people from being JS haters.

[LanceH]

> The fact people can't escape JavaScript doesn't stop people from being JS haters.

It just creates more of them.

The nice thing about stimulus is that it binds the pages I'm making to the javascript. It's all easy to find.

90% of what I want react for is to update just part of the page. This is simple with Hotwire now. There is no added marshalling/unmarshalling of json -- just regular crud requests the same as everywhere else. There is no second programming language. There is no added toolchain.

Adding in Stimulus and I can do most of the other things I've been wanting to do -- like modifying dropdowns.

The one place I can see React perhaps being better is when something happens on the page and I don't talk to the server. For most of my business applications, this doesn't come up as much. But say I was organizing a schedule, only to submit it to the server at the very end, React might be better at dragging things around, labelling them, then one big update at the end. Maybe it's easy in Hotwire also, I don't know yet.

[array_key_first]

It's not that people are JS haters, it's that JS is an incredibly unsafe and overly complex language.

It's the C++ of scripting languages. I love C++.

But would I use C++ to write a modern application? Uh, no. Not unless I'm forced to.

[hashbig]

Most of the reason I've started losing interest in Rails and the DHH cult is their insistence that their homemade JS solutions (Stimulus, Hotwire, JS import maps) should be the default choice instead of industry standards like Intertia and Vite.

I am maintaining a Rails app with Vite + Interia + Vue, and it's many times easier to manage, develop, especially when working with LLMs that haven't been trained on DHH's new frontend experiments du jour.

[multiplegeorges]

> their homemade JS solutions (Stimulus, Hotwire, JS import maps) should be the default choice instead of industry standards like Intertia and Vite.

Funny you should list those out. JS Import Maps (https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...) are literally an industry standard while Inertia and Vite are decidedly NOT standards in any way, shape, or form.

[hashbig]

Industry standards are not platform standards. React (enabled by Inertia) is in many ways is an industry standard for building UIs on the web today, yet it's not part of the platform. Same with Vite, it's the standard way to bundle on the web.

Decidedly, Import Maps are not used as a standard for dependency management in the web dev industry.