This is an understandable reaction to the ecosystem, but it also misidentifies the reason for the reaction.
Rails, Laravel, and Django exist. Elixir's Phoenix exists, and LiveView gives it even more of a full stack feel than the others historically have had. These frameworks have robust and well-defined ecosystems for all the essential bits of a typical web stack, and while yes, you have to install plugins for some of those things, that's by design and there are "canonical" options.
The real reason for his reaction is that he's recognizing that to build stuff to full production grade you have to make trade-offs and decisions and is surprised by that. This is a bit like being surprised that there isn't one standard bridge design that can be just copy/pasted across every river. On the surface every web app looks the same, but there are subtle trade-offs that have to be made: not every web app will need every feature and the total space of features that might be required is enormous, so every attempt to build an all-encompassing product or framework that covers all use cases has just ended up creating another option that you have to consider to decide if it covers your needs—each attempt at a cure all just further complicates decision making.
If AI is struggling to build a Rails app out of the enormous number of gems that are available and ready to be plugged in, that might be an AI problem and not a Rails problem.
> The real reason for his reaction is that he's recognizing that to build stuff to full production grade you have to make trade-offs and decisions and is surprised by that.
That's one interpretation. Another is "this is so hopelessly over-engineered that the reasons for doing so are impenetrable."
In comparison vanilla web development seems much easier to figure out, and with a few select web components one can get maybe 80% of what the impenetrable alternative offers.
I really disagree with this relatively-new outlook on web development.
I got into web dev in 2009, though I mostly shifted to other things around 2016. But I remember what web development back then was like.
You're completely missing the reason that all these "hopelessly over-engineered" frameworks were created (assuming that's what you're talking against). Angular, which was the first very popular SPA framework, made creating front ends far better, as their rising complexity made the "vanilla" solutions a mess to deal with.
It's possible (though I'm not yet convinced) that nowadays, for various reasons, "vanilla" web dev is better than things like React, despite almost everyone choosing React. But it's possible. But that doesn't mean things were hopelessly overengineered for no reason. That's kind of like saying that Math before we humanity invented Hindu-Arabic numerals was overengineered and why didn't they just use proper positional notation, which are far simpler. Making simpler things work is part of the job of engineering and often takes more time and effort, and is in fact a good end result of "more engineering".
> You're completely missing the reason that all these "hopelessly over-engineered" frameworks were created
They were created in a very different time, to solve very different problems in a very different runtime environment.
Today's browser environment does not have many of the problems these frameworks were created to solve, and the clear majority of usage in the wild solves the existing problems in a way that locks you in to the framework anyway.
When I say over-engineered I don't mean that they were not necessary in the past, I'm saying that right now, in 2025, a lot of what you get from these frameworks is disproportionate to the cognitive burden they bring.
I agree that they solve problems, I'm just saying that perhaps it is time to consider that the point of diminishing returns has passed.
Yeah I think we agree; historically necessary, less clear if necessary now. My feeling as a not-very-in-the-loop person is that React is still the correct default choice nowadays, but it's complicated because of how entrenched it is - that is its own kind of reason to choose a solution.
Vanilla web dev is great if that meets your needs, and that's still an option for people like Karpathy. But for many use cases 80% isn't enough, you need that last 20% in order to be viable.
Most of the complaints about overengineering on the web are like this one from Karpathy: they come from people who are new to the field and who legitimately don't need the big-ticket tools because they're building the equivalent of a doghouse in the backyard. That's fine, there's nothing wrong with doghouses, but it's silly to take your doghouse as proof that steel I-beams are clearly unnecessary complexity and high-rise engineers should really just use 2x4s and nails.
I'd like to think that we're mostly in agreement in principle. We disagree on the specifics, like, for example:
> That's fine, there's nothing wrong with doghouses, but it's silly to take your doghouse as proof that steel I-beams are clearly unnecessary complexity and high-rise engineers should really just use 2x4s and nails.
What I am seeing is doghouses engineered with high-rise (or space-elevator) tech.
I don't don't dispute that these technology stacks serve a purpose, but I disagree that they serve a purpose in the doghouses that I see being built with them.
We (web developers, both front-end and back-end) spent the last few years in the feast phase of the cycle.
Business doesn't care that the back-end can scale to facebook levels of performance yet resume-driven developers yanked in all these stacks at huge cost to enable that.
Business doesn't care that the front-end can manage 100k individual elements on the page without flickering when the difference between using a VDOM and direct DOM modification results in a <1ms improvement, and yet I see react used for these doghouses.
The free-money run is over for now, and those engineers focusing on the minutiae of development are going to be outperformed by those focusing on business goals.
I say this knowing full-well that I am one of those engineers, so I've tried very hard to move away from deep-delves into the tech stack when they aren't relevant. I mostly do Line-of-Business applications now (biggest client has 10k employees) and...
What I found over the last two years is that almost all of what business actually wants can be done on a single VPS without K8, PaaS, IaC, terraform, lambda/edge workers, git[hub/lab/whatever] runners, AWS/GCP/Azure-specific services, ansible/chef/puppet, etc.
What I found is that the type of front-end that business wants is mostly AcceptUserInput -> DisplayProcessOutput. Two-way data binding? That's a minority of the UI elements/components. SPA f/end routing, client-side includes? Multiple webcomponents (of various quality) for those exist which can be used directly on the page in question without even stepping into javascript. Writing those webcomponents aren't particularly difficult or time-consuming, and 1) they work without needing a build step, 2) they are easier to debug directly in the browser without 3rd party tools, and 3) They have no dependency on anything other than the vanilla-js implementation.
Now, fine, that approach isn't for every project, but a large number of projects I see don't even have 7k concurrent users, with a few thousand highly granular different business requirements.
I think, now that the good times are over, there is going to be a forced return to Pascal-Cased Functional Requirements: "This is what the software needs to deliver: A, B and C. Why are you spending extra time to implement A, B and C via $FRAMEWORK when the velocity and maintenance burden is higher with $FRAMEWORK?"
Dependencies are by choice. It should be a considered choice. I don't see the trade-offs being made when these dependencies are selected; what I see is "this is the default proceeds to move directly into the highest cognitive burden tool".
I guess what I am saying is that there are too many doghouses being built with space-elevator materials, at space-elevator costs, requiring space-elevator maintenance.
Rails, Laravel, and Django exist. Elixir's Phoenix exists, and LiveView gives it even more of a full stack feel than the others historically have had. These frameworks have robust and well-defined ecosystems for all the essential bits of a typical web stack, and while yes, you have to install plugins for some of those things, that's by design and there are "canonical" options.
The real reason for his reaction is that he's recognizing that to build stuff to full production grade you have to make trade-offs and decisions and is surprised by that. This is a bit like being surprised that there isn't one standard bridge design that can be just copy/pasted across every river. On the surface every web app looks the same, but there are subtle trade-offs that have to be made: not every web app will need every feature and the total space of features that might be required is enormous, so every attempt to build an all-encompassing product or framework that covers all use cases has just ended up creating another option that you have to consider to decide if it covers your needs—each attempt at a cure all just further complicates decision making.
If AI is struggling to build a Rails app out of the enormous number of gems that are available and ready to be plugged in, that might be an AI problem and not a Rails problem.