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