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.

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?

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.

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.

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

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.

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

> 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.

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.