You just described every framework. Frameworks are great if your application is fairly simple and aligns with its way of doing things. Libraries are where to look if you need a more complex, flexible setup.
As a result, projects are frozen in time because everyone's afraid of touching anything, less it triggers Armageddon.
Maybe AI can help? Instead of copilot writing new code, or chat systems explaining a couple of lines, there could be an app that ingests a huge code base at once (spanning multiple languages and subsystems) and
- explains what each part does
- is able to spot potential side effects for each new addition
- suggests simpler ways of doing things / nice refactoring
There are some startups trying to address this but none seems to be there yet (I think); the market is huge though and people would pay through the nose for this.
1. Longevity of Engineers: Attrition is a killer from a knowledge perspective. Teams that keep their engineers have healthier systems
2. Avoid Over Abstraction: Simple understandable code is easier to maintain. Too many mid level engineers go overboard with abstraction and bad abstraction is worse than no abstraction.
3. Choose tech that is likely to be well maintained decades later. It's better to pick tech that will be well maintained than to pick tech that is better in some way but more obscure and more likely to poorly maintained in decades.
The fix for this is pretty easy though. Keep employees and avoid the churn.
The usual explanation is inversion of control—you call into a library, but a framework calls you. But now that pretty much every language has closures, it's a lot harder to use that as a distinction: is React a library since it all starts with createRoot/render (you called it), or is it a framework because from that point on it's calling you? There are tons of people who are highly opinionated in both directions, which suggests that this dichotomy is artificial and doesn't reflect a deeper reality.
If doing things exactly the way you envision involves building the world from scratch, it's often better business to go with a "less elegant" solution that can be rapidly pieced together from mainly ready-made components.
I've often earned long-lasting trust and cooperation of clients by asking whether they would like to adjust (or forego entirely) that one feature, if the project ended up being 20 or more % cheaper/faster to deliver. And given that choice, it's surprising how flexible businesses can be.
- 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.
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.
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.
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.
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.
Can't these candidates quickly learn Hotwire? Seems like its much simpler than React (less moving parts)
In short, it's probably better for your career to work on React.
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.
But I would be tempted to go react and inertia js for MUI or EUI for the predesinged components and nice datagrids.
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.
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.
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.
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.
I either do SSR with slim or do API only with a separate frontend.
Rails changed direction too many times trying to do JS (coffee script, asset precompiling, webpack, etc)
There's also SSR with react and other js frameworks, but I don't think that's what they meant.
n.b., I've been building Rails apps since 2007. I was a diehard Haml user up until about 2021 when I made an all-in bet on Tailwind and had to switch back to ERB because Haml with Tailwind felt too obtuse.
The only downside is I am now spoiled.
You can of course just drop to `markdown:`.
Still, I use it where I can on personal stuff, but tend to opt for Erb when collaboration with others is needed.
Rails 5 & 6 were rough, you forgot yarn! That was my biggest pain point. I still have Coffeescript code, we have been slowly converting as needed.
Rails 7 has been a lot better to deal with, we use vanilla JavaScript (outside the coffeescript lol). Makes it pretty easy tbh. We load partials as needed (via js) and the site is fast and light.
My recommendation is to stick close to html with rails or as mentioned, a separate front end. What we have works super well for us, but definitely custom
The youngins always learn the hard way.
The field is extremely diverse these days, and tools that are appropriate for small data science teams may not work as well in enormous monorepos maintained by thousands of developers (and vice versa). What's missing from most discussions of static/dynamic typing is context—each career is unique and what projects you've worked on will have a huge impact on your perception of which is preferable.
Given different parameters, I'm sure the decisions would be different as well.
For writing an application or something that actually require design and libraries? Why bother? You need to be meticulous anyway, why not be meticulous in code?
The focus for me is on the tools and frameworks, not the underlying language. Show me a Typescript-based or Go-based language that can go from zero to production as fast as Rails with the same-sized team with no productivity loss, and I'd happily use it.
Yeah, that is one way of phrasing it. Another way to phrase it is that Amazon took it over, turned it into an ingestion funnel to their book store, and has done as little as possible after that.
The Goodreads dev said "the site was originally built as a giant pile of Rails spaghetti with views mixed with business logic and such and then a fuck ton of weird features built and left to sit there". I'm not sure why you think that is or ever was "the Rails way", but it seems more like the classic "move fast and break stuff" startup engineering than anything resembling rails to me.
Here is a competitor build with Rails https://thestorygraph.com/
Seems kinda cool. So I think Rails is not the problem here.
That’s only because this can turn into a real rabbit hole in my experience. But at that size maybe it won’t be so bad.
Best of luck!
Maybe it's just me but I just don't like DHH's governance lately. Not in a bad way, but following him on Twitter I just no longer respect him.
1. all data flow through the rails app (no pre-signed s3 upload or download links for direct uploading).
2. no support for CDNs (I think newer rails versions added support)
3. blobs and attachments were unnecessary abstractions.
3a. Querying was annoying (extra joins) and easy to add n+1 queries.
3b. In my app, images are moderated and it was unclear where to put the moderation metadata (on blobs? attachments? create a new table? why so many tables?) or `deleted_at` type columns.
4. GraphQL gem didn't support it: https://github.com/rmosolgo/graphql-ruby/issues/1777
2. What do you mean? Point whatever CDN you want at your origin
3. Maybe
3a. Yes
3b. Metadata or a new table
4. GraphQL is the single worst technology that has ever been adopted. We adopted at my company...twice. Twice we made the same mistake now we're stuck with it for mobile clients. In fact we're stuck on the old Graqphl RB gem that used a DSL instead of classes, which also blocks our Rails upgrade. We've been able to revert everything back to good ole Rest for another part of the app. Be cautious adopting technologies of large companies.
2. CDN support is via monkey patch: https://github.com/rails/rails/issues/44136
3. yep
4. yep
It's not really governance, that's kinda the problem. To be fair, he never claimed that he was providing governance. Rails was extracted from basecamp. The impression I get is that he sees Rails as a gift to the community created from the profit-making Basecamp. Which is great; and I appreciate the fact that I've been able to build a career using Rails.
But there is no governance really. Rails goes in the direction that 37signals wants it to, which is largely pretty good. You and I don't get much of a say in it though; especially if DHH disagrees.
It was almost a drop in replacement for webpack for me
FWIW the Rails 7+ way of doing single page app JS is also more reasonable than it used to be. You pretty much just use whatever build tool you want in isolation from your rails app. You have to run something like `yarn build --watch` alongside `rails s` in development but IMO that's not so bad and makes things a lot simpler.
My company builds software to automate Rails upgrades, and offers a full service where we'll upgrade Rails for you. steve (at) infield.ai if that's interesting or you can generate a free rails upgrade plan at https://app.infield.ai/users/sign_up (no cc required). https://docs.infield.ai/docs/creating-an-upgrade-path for some more details.
Rails is great when you stick with the defaults and a land of pain as soon as you leave them.