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.
> [web dev] is a bit like assembling IKEA furniture. There's no "full-stack" product with batteries included, you have to piece together and configure many individual services
> I'm relatively new to modern web dev and find the above a bit overwhelming
tbh, it kind of shows. This whole tweet just has a vibe for me of a junior moaning about how complex things are -- and suggesting we should build a fancy new framework to solve it all instead of having to learn about the individual components.
the modularity is a feature, not a bug. it means we can make customised systems out of re-usable components. one-size-fits solutions rarely work when you need to do that one special thing -- you can't do it because your AIO platform doesn't allow you to. there goes your chance at solving problem X for your customer (and getting paid more money).
The truth is, things are usually somewhere between these two edge cases, or on the extremes themselves
1. limited modularity -- low complexity, heavily opinionated and limited functionality outside of 'one-size-fits-all' (e.g. wordpress)
2. high modularity -- high complexity, less opinionated and high functionality (e.g. AWS/self-hosted)
Building a webapp being difficult for a junior is the exact problem he's pointing out, although pointing it out as a problem is probably not very fair. It's just the maturity of the technology.
The expectation has changed, and people expect webapps to be relatively sophisticated, but building a sophisticated webapp isn't easy. There are a lot of them just because there are a lot of reasonably competent webdevs. Joining that club is not impossible at all, but it's not like building a Rails app 10+ years ago (which did solve a lot of problems at the standard of that time, because of the different expectation level).
Web apps are complex beasts. A junior architect cannot design a safe and maintainable skyscraper (hell, they probably can't even design a proper two-story home without making mistakes) and architecture as a discipline has been with us for centuries.
A modern, new product is even harder because it's often uncharted territory (it's almost a miracle we can build them) not because of the maturity of the field but rather because if you're building an app instead of deploying an off-the-shelf solution it's because you need to explore the trail... If you want tried and tested just deploy WooCommerce or whatevs in a plain-old web hosting!
Designing something completely new is, by definition, off-limits for a junior in any field.
This guy's been building bunkers and dams for years and somehow expects to transfer his knowledge to design a skyscraper? Would he expect a webdev to be able to design and build a brand-new LLM and deploy it in a scalable fashion from scratch?
I understand the desire, but it's unrealistic, especially considering the ever-growing affordances that an app is expected to have in 2025.
> A lot of glory will go to whoever figures out how to make it accessible and "just work" out of the box
This path is already available. It's just incredibly boring from a VC/influencer perspective. Telling devs to go read the MDN docs and stay off the lawn has been the solution for about a decade now.
HTML/CSS/JS absolutely "just work" in 2025 if you'll give them a chance to. Piling a Rube Goldberg machine on top and complaining about how hopeless it all is looks like the stick-in-bike-wheels meme to me.
Amazingly, the AI does a lot better with vanilla web too. You just have to really encourage it to not use all of this vendor trash because of how biased its training data is.
I would say the even bigger problem is that the pieces you stitch together to make a web app will rot rather quickly.
He mentions supabase and vercel. It will only take so long, until the supabase code or the vercel service will have a breaking change. And those breaking changes add up throughout the stack. Making the cost of running a web app much higher than it would have to be.
Because eventually you end up rewriting a more brittle version of an established framework. Plus someone else may have to maintain it. Working out how your vanilla code works is worse than learning a framework because there's no help.
I lived this with an app made in 2012 that was all custom JS.
Plus how far do you want to take it? Write your own security modules? Create your own anti SQL injection code? The benefit of frameworks is you get free hardened code tested by millions.
But yes, I get it, gluing together Frameworks is depressing too. It just isn't fun.
JavaScript, HTML, and CSS have changed a lot since 2012.
I think the problem is folks tend to think like engineers with all their widgets (e.g desktop development in the browser). Even Microsoft is going full TypeScript mode.
Web development is DESIGN first. Think of it like a design project and suddenly the entire workflow changes.
The CSS spec today makes all this stuff super easy people just don’t spend the time actually learning.
In my opinion the Laravel and Rails developers get this right.
It also leads to the irony that eventually, you’ll build libraries that then have breaking changes and you’re managing both the library and all its versions and the applications that use it.
I think it is a balance. My current view on this is:
For the frontend, everything but plain HTML, CSS, JS is too much.
For the backend, an opinionated framework like Django is too much.
Even a less opinionated framework like Flask is too much.
Using modules that Flask uses - like Jinja templates - is the right choice for me. This way, I don't have the overhead of a full framework, but also don't have to write basics like a template engine myself. And I have the benefit that other developers (and AI) easily understand my code, as it has many similarities to a Flask project.
So instead of going for Flask when I need templates, all I do is
Web development is super simple as long you use a mature stack.
Just use HTML/Server side rendered templates, CSS and Vanilla JS. Then you need a mature backend framework, Spring Boot, Rails, Django and then you need a database, SQLite, MySQL or PostgreSQL.
With this, you can create powerful web applications, with minimal dependencies and a working back button for browsers.
At no point would I say web development is super simple. It's hard to get started, it's hard when something gets larger/more used, and it's hard when things are massive.
There are so many things to consider, as the original post shows. On top of that is:
- accessibility
- screen reader support
- testing
- usability
- animations/transitions can help and are another can of worms
- SEO
- consistent user elements -> interface components
- responsiveness
- performance
- minification
- lazy loading images
- optimizing images (eg serving a 200 kB webp/avif instead of a 5MB JPG)
- caching/scaling so your server doesn't go down when Hacker News/Reddit links to it
- hosting cost
- security
- CORS
- CSP
- forms
- validation
- feedback
- helping users fill it in correctly with as little friction as possible
- user content sanitization
- rate limiting
- licensing
- of the content you make
- images you use
- libraries you use
Your toolset might work for a simple website that nobody will visit, but if you actually care about providing the best experience you might want something more.
Half of these are literally an import and 2-5 lines away in .NET, Rails, Spring, etc.
Most of the others are a 2-3 npm installs away in the frontend, and a few are not used by extremely popular sites like archive.org, Wikipedia nor this very site.
> With this, you can create powerful web applications
As long as you are able to keep your requirements simple enough. I feel that it is not the tech stack that is getting complicated, it is the user and management expectations. For example, try building a web app like Google Docs, even a simple one, with Vanilla JS and CSS and other tech you mentioned. You can do it. But it will take you far longer than somebody who is not limited to this simpler stack.
The overwhelming majority of web apps are not Google docs.
The advantages offered by heavy frontend frameworks have to shrink over time as browser standards catch up.
The current deficiencies in the vanilla browser can mostly be mitigated with some simple web components. The ones that can't are things like date input, file uploads, lack of styling for many of the native elements, etc.
It's always the same.
Big internet giants having really unique issues: scaling with millions of users at the same time, micro optimizations as they have a big impact because of the scale. So they need to really complicate things like distributed systems, eventual consistency, and unique UX etc.
They do a good job about it and want to share it so they publish their story. Now people from other companies read this and think that this is now state of the art and they also should do this. But they don't even have the same issues.
I work with a Low Code framework from Oracle (APEX) that literally runs in the database and serves web apps. Want a report and form on a table? Click create new app and xreate page, select the table, customize labels, maybe move things around, maybe change an item from type text field to select list with another query and done in 5 minutes. With lost update detection, easy authorization control, automatic validations for your table constraints, etc. You can still code data processing procedures but why reinvent the wheel for another web UI?
People just choose to overengineer backend apps that only 50 people use...
> The reality of building web apps in 2025 is that it's a bit like assembling IKEA furniture
I don’t understand the analogy.
If the desire is to have a complete pre-built product (fully assembled furniture), then you’re not building but instead buying someone else’s SaaS offering.
It's easy to hate on the ways web development goes wrong, but I think it's really cool that our ecosystem has so many options for people to get started. New libraries, and thus new ways of doing things, push old established practices to become better. And it would be very ambitious to implement every capacity all by yourself (whether as a company or as a framework).
Having said that, I do think there's a false assumption that if you create a potluck of a technology stack, you've saved a lot of time. Every different technology you introduce adds a permutation, resulting in an exponentially growing way for things to go wrong. So in my opinion, if you've proven your MVP the next step is to find what technologies you could truly trust and potentially control long term (which often equates to powerful technologies with very small API surfaces), and then roll up your sleeves and build the rest of the integration stuff yourself. Specificity > power, when it comes to maintainable technology.
Every case will be different of course, but this approach is what worked well in my experience.
I don't think it's useless, it's just not "web development".
It's more "building the stack for the entirety of a company", but that's not web development, that's building the stack for the entirety of a company (minus HR, minus some accounting).
Filing everything a company does under web development feels a bit extreme. And if you don't, then this really isn't all that exciting, because building the software & hardware stack for a larger operation has never been a 10-minute-job.
It seems to me that the confusion stems from the fact that it's now feasible for a single person to do all of this by themselves within a reasonable time. Not super quickly, not without some frustration about narrow docs, but it's not going to be impossible or take a decade.
If we had a similar evolution in working with materials and a single person could build entire factories by themselves in 3 months, I'm sure we'd have similar complaints. But there are no complaints because no sane person thinks they can build a factory in 3 months by themselves.
Well, what's a web app? A lot of stuff on that list exceed what's usually thought to be part of the actual web app, like monitoring, CI/CD/staging, payment. If you use something like Django, Laravel, Rails a lof bases will be covered including frontend, backend, auth, social logins, email, basic analytics etc. Choosing a framework, library, CMS also depends on the level of customization you need or want to do.
For the given use case I would always choose a mainstream stack like Django, Laravel, Rails. Each has huge communities, lots of add-ons for everything, vast documentation etc.
Yeah, but Karpathy mentioned using Vercel, Supabase and NextJS, all of which are included with Kirimase. Django would definitely be more up his alley though, given he doesn't need to learn a new language outright.
To me web development is the one place where I do feel like there's a lot that "just works". If I had to make a native mobile app I would feel overwhelmed and confused. I wonder if this really just comes down to familiarity. It seems strange to me to assume a given domain should be easy.
The tweet is over generalizing things. It says "The reality of building web apps ...", but what he really is talking about is building a serious, scalable, production ready web app. Blob storage, email, background jobs, analytics, monitoring? Come on, you are taking about building a web based product that is often managed by several people, and if you are creating something that is serious enough to require analytics, you might as well actually understand what you are doing.
This isn't about what most people consider "web development" or "building web apps", too much a stretch.
Let's say e-commerce is 25 years old; Serious scaling should be a fundamental feature or available as an 'architecture kit' yet that still doesn't exist. Time after time, its
1. Architecture-via-developer-pet-interests
2. See what happens
3. If it doesn't fall down, begin adding features via above procedure.
4. If features are failing but business is not, hire someone else to begin at 1.
It is closer to 35. I know because I was running an e-commerce site in 1993. Yes, you could add items to a shopping cart, place an online order using a credit card back in 1993.
Couldn’t you just go like dot net stack on Azure? Or Rails on heroku? I feel like what you’re describing exists but there are trade offs you don’t want to make, or you want to piece together your own thing because it’s cheaper, but for everything but the top say 500 companies an off the shelf solution probably works fine.
(for other readers - Azure and .NET are not related (save for Azure using C#, among other languages, for their infrastructure), you can deploy it anywhere)
Or are you importing a hundred different modules, using a bunch of different services, and just reproducing the IKEA-like system Andrej is complaining about in a language you happen to like?
What’s strange is there are battery operated solutions right? Something like meteor.js or you could go with a mean stack, or be all in on AWS. Or he could just go with squarespace or Wix!
This feels like the whole 15 standards xkcd thing. I mean, I get what he’s saying, but I also feel like his proposed solution has as many if not more problems than the problem he is trying to solve. Like, you can somewhat have what he’s suggesting now, but either you get screwed on pricing or it would reduce innovation.
Within a couple of years we are going to start seeing AI generated and fully customized stacks. As in, database built specifically for your application and etc. You basically show inputs and you have a middle layer for debugging tools. At least that’s how I envision it.
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.