[ywain]

I'm working on a fairly recent Rails 7 code base. We initially started using Stimulus, but are now considering switching to React for a few reasons:

- if you're looking to hire frontend engineers, the candidate pool for React is a few orders or magnitude bigger

- it's getting harder and harder to find vanilla JS packages that you can wrap in Stimulus controllers for common tasks, compared to finding React packages

- Stimulus doesn't really offer a way to write unit tests for your controllers. With React, you can use jest and react-test-renderer like normal.

Additionally, the recent Turbo TypeScript debacle did not instill confidence in the long term stewardship of the Hotwire ecosystem.

We're still on the fence about it. Stimulus does feel like a very Railsy way to write frontend code, which is definitely a plus for small teams of people who're already familiar with Rails.

[azangru]

> if you're looking to hire frontend engineers, the candidate pool for React is a few orders or magnitude bigger

The trick is not to look for React developers, or Stimulus developers, but to look for frontend developers. Those who can competently write javascript/typescript, have a good understanding of browser apis, and are competent in css and html.

[JeremyNT]

Agreed, Stimulus is so simple that there's almost no prerequisite other beyond a basic understanding of HTML and javascript, both things that any "React developer" and even most "backend" web developers should already have.

Maybe I'm biased but I feel like rails + stimulus makes it incredibly easy for anybody with any kind of programming background to grok the entire project, and maybe you can reconsider even even having dedicated "frontend developers" at all. I know that specialization is a thing, but it's just so easy to be a "full stack" developer on such an app that I think almost anybody could pick it up.

[gls2ro]

> if you're looking to hire frontend engineers, the candidate pool for React is a few orders or magnitude bigger

Two comments on this - I know it will not change your mind, but maybe other people will read this:

1. Of course, the candidate pool for React is bigger, I think Hotwired - in its current form was released in 2021 (November or December). So this expectation is kinda “Planning to fail” right? If you put this as a criteria of course you are going to choose React. Are you sure you are not already decided to use React and then found reasons for the decision. It is totally fine if you did as we are all doing this constantly (first deciding and then finding reasons or explanations for the decision)

2. I think if you have a React developer (so a person who should know JS and HTML) who cannot write Hotwire code, that is a big problem. Anyone with a good foundation of JS and HTML should be able to write Hotwire code (Stimulus + Turbo)

Recommendation: Don't put in your job ad "Required skill: Hotwired". Just hire people who understand how the web works (browser + HTML ...) and they will be able to write Hotwire-compliant code.

> it's getting harder and harder to find vanilla JS packages that you can wrap in Stimulus controllers for common tasks, compared to finding React packages

I am not sure what packages are you trying to find. But I would suggest if you are trying to find an 1-on-1 corresponding React package to Stimulus package the way the UI and UX is designed is not for Hotwire. You should not choose Hotwire to replace React but keep the same page behaviour. You should think your UX web experience different - more back to basics with interactivity sprinkled around

> Stimulus doesn't really offer a way to write unit tests for your controllers

Again if you have an application like say Figma UI then probably you need unit tests. But if you think the UX to be Rails 7 + Hotwire, you will not write so much JS code that you need unit tests for it.

Testing an end-to-end feature should be enough.

Of course, this is just me talking about a product (yours) that I don't know what it is an I am making so many assumptions.

[technion]

Mastodon runs as a rails api with a react frontend. Last time I discussed this people mentioned it was the worst of both worlds and I get the argument.

But doing things that way means nearly every fronted dev can work with their favourite patterns and frameworks. I love that they can debate replacing create-react-app and i do not have to care beyond saying "as long you meet the openapi spec". Moreover, everything you've described along with most of what has changed recently in the ecosystem goes away. I don't have to care what is happening to hotwire, or the asset pipeline in general or around scss gems being deprecated.

[0xblinq]

> fronted dev can work with their favourite patterns and frameworks

And this is a big problem in my opinion. We should decide the stack that better solves the problem, and then hire people that are happy to work with that, not the other way around.

It's like saying you're in the business of putting screws into walls, but you do it always with hammers because most people like to use hammers.

[0xblinq]

TL;DR use React because everyone uses React?

> if you're looking to hire frontend engineers, the candidate pool for React

While this is true, I think you will also need less people to achieve the same, the amount of work is incredibly less. So maybe finding one or two developers with an open enough mind and a good salary will provide even more value than a full team of backend devs + a full team of frontend devs + all the coordination efforts.

> - it's getting harder and harder to find vanilla JS packages that you can wrap in Stimulus controllers for common tasks, compared to finding React packages

Any example of this? I don’t find this to be the case, given that any “vanilla” library will work out of the box and many of the react packages are there to solve react creates problems.

> Stimulus doesn't really offer a way to write unit tests for your controllers. With React, you can use jest and react-test-renderer like

This might be controversial, but I don’t find testing UI with unit tests useful at all. Tools such as cypress provide a lot more value for the effort it takes to write and maintain, and those tools work with any underlying implementation. Mocking browser APIs is not fun at all.

Regarding typescript, I honestly just don’t get the drama. It’s just a tool. If it solves a problem for you use it, if you don’t, don’t use it. And you can’t force others to use the tool you like the most.

Also, given how these tools work (mostly with data attributes and in the fly generated methods from those data attributes) I’m not convinced typescript or not will make any noticeable difference as the user of the library.

At the end of the day it’s all trade offs. But something I can guarantee is that going the React way is a ton more work, decisions, maintenance, people and headaches. If your app/project really requires react then you’ll have to bite the bullet and go for it. What’s sad to me is going with react just because everyone uses it.

[sibeliuss]

Comparing the two: I have a hard time understanding how one could write FE code using classes (Stimulus) in 2023, when simple functions with inputs and outputs are there for the taking. It's just asking for trouble and hidden complexity. Choose wisely!

[0xblinq]

> when simple functions with inputs and outputs

And the state library, and the hooks for side effects, and the SSR, and the hydration, and the VDOM, and... It's not that simple.

[mardifoufs]

I know react is moving towards SSR quite a lot but I don't think hydration or SSR are actually common for react devs to care about. You also have very similar issues with hotwire, so I'm not sure it makes React more complicated.

For all its flaws, React is still extremely "small" as far as front end and server side front end goes.

That might change with the increased push towards next.js and SSR though.

[sibeliuss]

Very true. For every day dev, all the framework bits are stuff the average dev doesn't need to know at all. Ie, none of the devs at my company know anything about that, and that's just fine. We get a ton of work done.

[pulse7]

Functional/OOP flamewar is starting...

[sibeliuss]

On the FE, this is already a settled topic. Who wants to go back to `this`? Um... nobody.

[bradgessler]

> if you're looking to hire frontend engineers, the candidate pool for React is a few orders or magnitude bigger

Can't these candidates quickly learn Hotwire? Seems like its much simpler than React (less moving parts)

[ulizzle]

No because every job wants you to hit the ground running. They’ll start asking for “10 years experience in Rails Hotwire” at some point

[gedy]

> Can't these candidates quickly learn Hotwire?

Main issue I've seen is Rails shops don't hire devs without Rails experience, or expect you to interview well with backend OOP type code.

I guess that's okay for someone wanting to get away from frontend and be "full stack", but it's not for a lot of people.

[brennopost]

Stimulus is considerably simpler than React, imo. Turbo, with frames and streams, might take a little time to get the hang of, but it's not overly complex either.

[technion]

You'd be surprised how many candidates would prefer to just take another job. If for no other reason than resume building with the word react.

[0xblinq]

Then that was not a good candidate from the get go? What about hiring people that really care about the product they're building and not just tool fanatics?

[mplewis]

One good reason to avoid a job doing Hotwire is so that you can take a job doing React for a similar amount, where your experience applies better and where you'll gain more transferrable experience.

In short, it's probably better for your career to work on React.

[0xblinq]

As a developer, I get it.

What I don't get is why as an owner/stakeholder/CTO/lead would pick the worse tool (in some context) just because everyone is using it. Well, I do get it... I just don't agree.

If you read between the lines here, everyone is just picking React because everyone else is picking React, that's the only reason apparently. It drives me mad, but honestly I do understand it.

[kurupt88]

Yeah, especially for crud apps when you get to implementing forms. So much easier with rails and hotwire.

But I would be tempted to go react and inertia js for MUI or EUI for the predesinged components and nice datagrids.

- https://eui.elastic.co - https://mui.com

[0xblinq]

Also, I'm not 100% sure it's for the "same amount". To me it looks like Rails jobs have higher salaries, at least around here. But that could be because most Rails devs have many years of experience, I don't know.

[0xblinq]

BTW, if you end up using React with Rails, consider https://inertiajs.com/. It works great with Rails.

[tarsinge]

If you have to hire dedicated frontend engineers maybe you have overgrown Rails or it’s not a good fit for your site? I find Rails is awesome when it fits in the model Fullstack engineers with designers, HTML-heavy with JS enhancements on specific views. It’s so simple and efficient when the views nicely match the URL routes and they are mostly HTML, even the designers can work on the codebase.