So is the rise of AI coding, the end of frameworks?
Frameworks were created to reduce boiler plate ( at the expense of new abstractions which occasionally leak ) - boiler generation is less of an issue for AI, and the underlying platform is very well specified?
I guess the only problem with vanilla is if the sheer volume of text overwhelms the context?
I’m not really sure that most web frameworks reduce boilerplate. There is a lot of boilerplate involved in setting up routes, and builds, and so on. As far as I can tell they only really make sense for very large teams (who need a uniform shared data model, design language, processes, etc.) and people who really want to run server side js/do a lot of SSR.
The thing about web “frameworks” is that they’re not that different in structure from what you’d build to do SSR and a repeatable way to add pages/dirs and shared assets, in any language. You can build a minimal version of something that does that in less than an hour, at least in Go. go:embed and a factory method for handlers :)
I think we’ll all end up with more bespoke “frameworks” (specialized web servers) with less gravitational pull towards dysfunctional (IMO, the node ecosystem) tooling, and still have many people using the best major frameworks. Truly large projects will still need to use react and svelte and co unless they can train a model on their own framework. But that’s really hard
And if you are looking at it - do you insist on certain patterns or structure to allow yourself to more easily navigate it?
Basically I invested a lot of time in learning how CSS, browser apis, and modern html work and figuring out how to do tricks with them that eliminate or greatly reduce the need for SSR and JS. Even though this took several months and a LOT of specs/docs and tedious design work, it was worth it because now I actually understand the foundational abstractions that all these web UIs actually are implemented against, and which don't change. Now I only need LLMs and a way to communicate those tricks (and I know the right language and terms to use to get them build on the right foundations).
But I'm working towards training my own preference set and training pipeline/tools so that I can get models to output things the way I like without all the process/styling/etc. steering that I still need between and across sessions. This is why I think coding agents are long-term only going to be used for vibe coding or to replace less skilled SWEs. You can't get them to consistently do things the way you want or build new devtools/abstractions that get fully internalized and baked into the weights unless you trian them. And a very useful thing about vanilla css/html is that they are much more easily verifiable and something you can generated/search synthetically vs SSR-npm style output.
Even more fundamentally, frameworks were created to reduce the developer time and skill required to build applications. This has been a pipe dream many have chased since COBOL replaced assembly language.
LLMs are probably the first technology that actually approaches doing that. And yes, they don't need frameworks, they're indifferent to the amount of code or boilerplate needed, don't care about the developer "experience," and will write vanilla JS and HTML just as well as anything else you ask them to do, maybe better.