Rails apps are rare and getting replaced. Most web apps are static builds where the tools listed are not used all at once and largely irrelevant outside the dev environment.
> John runs a single command. The app boots instantly, working forms, instant loading times, blazing fast navigation.
I think there is a much-better-than-merely-non-zero chance that the rise of coding agents will also mean a rails renaissance. All of the complexity identified in the article really gets in the way of LLMs.
and the problem is that if you apply for a job in this area you have to know them all +10 years experience with all the frameworks and backend stuff, sql, docker
I sorely miss the sheer amount of utility that you can get from Rails out of the box for free compared to anything in the JS universe. Most JS devs don’t have the faintest idea how much they’re missing out on. Then again reinventing wheels is the JS way of life.
I think some people are so fixated with keeping up with the latest tech and prepare their project to scale infinitely that they have forgotten how good barebone setup is, especially with Rails. I get it, it's boring, unentertaining and might be understimulating to some. But it just works, Rails is truly batteries-included. Stop with the overengineering
I agree with the sentiment on this. I'm building applications that are easily converted to native mobile apps with minimal code and engineers left and right are telling me I should use 60 different libraries and frontend tools to reach the same goal.
Meanwhile Rails is becoming easier and easier to run complex apps with much smaller teams.
This scenario is worse now than it used to be, but the concept isn't new. I remember wanting to tear my hair out learning Django 15 years ago: The tutorial had you install Vagrant, VirtualBox, and Chef in specific versions, all of which were broken and/or a pain to install!
I still use and love Django, and don't bother with that stuff. Django Rest Framework was another distraction.
Minification... how many times have I seen devs claiming that adding a whole toolchain for saving a few kilobytes is crucial to performance and simultaneously failing to serve assets with proper compression and cache headers ? Heck, how many times have I seen "web" devs with no basic understanding of the HTTP protocol ?
And they look at me like I'm the lunatic when I tell them their 3 text fields 2 buttons "app" is over-engineered and needs no build step.
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).
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.
If you're gonna rant about the JS ecosystem at least get it right. You can set up a Vite + React + Tailwind setup with two commands
npm create vite
npm i @tailwindcss/vite tailwindcss
If you want automatic code formatting and linting install biome, that's one more command.
You don't need to think about React Refresh or babel or typescript, it's all handled by vite. I've never even seen a .babelrc file. And why does the author add husky?
Like, if you want to criticize JS fine, but chose valid criticisms. This just sounds like the author hasn't actually used modern js.
I've been writing Rails code since 2007. There's a reason the stack has gotten more complicated with time, and virtually no team has ever done it right by this definition.
The trouble with an omakase framework is not just that you have to agree to the initial set of choices but that you have to agree with every subsequent choice that's made, and you have to pull your entire dev team along for the ride. It's a very powerful framework, but the maintainers are generally well-meaning humans who do not possess a crystal ball, and many choices were made that were subsequently discarded. Consequently, my sense is that there are very few vanilla Rails apps in the wild anywhere.
(I'm old enough to remember what it was like to deploy a Rails application pre-Docker: rsyncing or dropping a tarball into a fleet of instances and then `touch`ing the requisite file to get the app server to reset. Docker and k8s bring a lot of pain. It's not worse than that was.)
I just woke up from a nap and I see "You're Doing Rails Wrong" and then I wonder... is it still 2008, did I imagine Brexit and why does my macbook's screen look soooo good?
Any project that doesn't need 30 or more devs with various specialties working on it all at the same time doesn't need the complexity that frontend/backend separation introduces. I learned this the hard way through years of over-architecting 1-2 person projects as a freelancer. Nowadays, it's just Django with a little bit of Tailwind on top.
This is the fundamental weakness of Rails. You can't just "do Rails" because the UI out of the box isn't usable. You've always had to add something on whether that was Bootstrap 10 years ago or React today. It's always been a bolt on and always has been changing.
This article has been re-written for over a decade.
The so-called "complexity" is just a list of tools that each solve a specific problem.
Tooling isn't the problem: The complexity is inherent to modern web development. You see similar "hidden" complexity in other frameworks like ASP.NET, and GUI desktop frameworks as well.
If you're using Rails as an API backend with React handling the frontend, it's almost a completely different application architecture than a traditional Rails monolith. So the list of tools (Vite, React, Prettier, etc..) is almost for a completely different problem (again, unless you use Rails for FE; if you want to use Rails for Frontend, use Rails for Frontend; not a fan of the mash-up at all.)
The real issue is learning methodology:
A lot of developers today start their careers with frameworks (point 4) before learning the fundamentals of the web (points 1-3).
HTML for markup.
CSS for styling.
Learning server-side logic (e.g.: <forms> can POST and can return a completely different page at the same URL) and databases for dynamic content.
Then, JavaScript for interactivity.
Embrace the tools: Each tool on the list (Vite, Tailwind, etc.) exists for a reason, and they're all necessary for a modern web application.
Saying there are "too many" is an amateur take on the reality of the ecosystem.
I think the pushback isn't so much against the existence of the tools per se, more against the pervasive idea that everyone needs them.
When every other learning resource is titled something like "Ten reasons you need to be using the MONGOOSE stack right NOW!", it's no wonder we've got people trying to shove redis into their baking blogs.
Matter of fact is, the average website would be fine without a "stack" of any kind, but no YouTuber sells sponsorships telling their viewers that. Ergo, many junior devs genuinely don't know that.
While I agree that people should be primarily learning the core tech, it's a difficult message to deliver amongst the cacophony of corporations trying to promote their services.
When you write "The complexity is inherent to modern web development" you are describing the problem, not a requirement. When you are pulling in a thousand npm packages just to make a simple transactional website that is a wrapper over a database and a few SQL queries, you're doing something wrong.
You're saying each tool solves a problem. That's true. But is it a problem that you have? And is the pain of that problem larger than the pain of introducing another tool that you need to debug when things go wrong?
Also, browsers have really stepped up their game. Now there is native CSS nesting[0], cross-document view transitions[1] and much more. So the above calculus is continuously shifting. So much that I think it's best to start with a really simple stack nowadays.[2]
what’s interesting is how every few years we circle back to the same conversation with new names for old problems. the industry keeps rebranding the same complexity as innovation, but it’s mostly the same tension between abstraction and control. every new framework promises to simplify things, but each simplification hides an entire new layer of assumptions that developers eventually have to learn anyway. maybe that’s just the cost of building software at scale now: we’re layering human preferences and historical context into the codebase as much as we are logic. in that sense, modern stacks aren’t complicated because of bad design choices, they’re complicated because they’re living artifacts of collective compromise.
63 comments
[ 4.5 ms ] story [ 65.6 ms ] threadRails apps are rare and getting replaced. Most web apps are static builds where the tools listed are not used all at once and largely irrelevant outside the dev environment.
> John runs a single command. The app boots instantly, working forms, instant loading times, blazing fast navigation.
Same with node? npm run build && npm start
Meanwhile Rails is becoming easier and easier to run complex apps with much smaller teams.
I still use and love Django, and don't bother with that stuff. Django Rest Framework was another distraction.
If I'm making a typical website, all I'm using is a few PHP files, a single CSS file and maybe some JavaScript.
There are no build steps. No minification. No compilation. No frameworks.
I just can't understand even using Rails for web dev.
And they look at me like I'm the lunatic when I tell them their 3 text fields 2 buttons "app" is over-engineered and needs no build step.
In my opinion Rails 8 + Intertia.js + React so much less "reinventing the wheel" (especially if you use shadcn components).
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.
You don't need to think about React Refresh or babel or typescript, it's all handled by vite. I've never even seen a .babelrc file. And why does the author add husky?
Like, if you want to criticize JS fine, but chose valid criticisms. This just sounds like the author hasn't actually used modern js.
The trouble with an omakase framework is not just that you have to agree to the initial set of choices but that you have to agree with every subsequent choice that's made, and you have to pull your entire dev team along for the ride. It's a very powerful framework, but the maintainers are generally well-meaning humans who do not possess a crystal ball, and many choices were made that were subsequently discarded. Consequently, my sense is that there are very few vanilla Rails apps in the wild anywhere.
(I'm old enough to remember what it was like to deploy a Rails application pre-Docker: rsyncing or dropping a tarball into a fleet of instances and then `touch`ing the requisite file to get the app server to reset. Docker and k8s bring a lot of pain. It's not worse than that was.)
(sorry, it was just too obvious)
Tooling isn't the problem: The complexity is inherent to modern web development. You see similar "hidden" complexity in other frameworks like ASP.NET, and GUI desktop frameworks as well.
If you're using Rails as an API backend with React handling the frontend, it's almost a completely different application architecture than a traditional Rails monolith. So the list of tools (Vite, React, Prettier, etc..) is almost for a completely different problem (again, unless you use Rails for FE; if you want to use Rails for Frontend, use Rails for Frontend; not a fan of the mash-up at all.)
The real issue is learning methodology: A lot of developers today start their careers with frameworks (point 4) before learning the fundamentals of the web (points 1-3).
HTML for markup.
CSS for styling.
Learning server-side logic (e.g.: <forms> can POST and can return a completely different page at the same URL) and databases for dynamic content.
Then, JavaScript for interactivity.
Embrace the tools: Each tool on the list (Vite, Tailwind, etc.) exists for a reason, and they're all necessary for a modern web application. Saying there are "too many" is an amateur take on the reality of the ecosystem.
When every other learning resource is titled something like "Ten reasons you need to be using the MONGOOSE stack right NOW!", it's no wonder we've got people trying to shove redis into their baking blogs.
Matter of fact is, the average website would be fine without a "stack" of any kind, but no YouTuber sells sponsorships telling their viewers that. Ergo, many junior devs genuinely don't know that.
While I agree that people should be primarily learning the core tech, it's a difficult message to deliver amongst the cacophony of corporations trying to promote their services.
Also, browsers have really stepped up their game. Now there is native CSS nesting[0], cross-document view transitions[1] and much more. So the above calculus is continuously shifting. So much that I think it's best to start with a really simple stack nowadays.[2]
[0]: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_nesting...
[1]: https://webkit.org/blog/16967/two-lines-of-cross-document-vi...
[2]: https://mastrojs.github.io/