Given the choice, I think I would prefer to go as browser native as possible.
Library code is useful for abstraction but browser native APIs are always going to be more stable over the long term.
If I have to vibe code now then at the very least I should be able to take advantage of agents to reduce the number of external "moving parts" involved by going native.
Also for CSS? I really like how Tailwind puts the CSS in the same place as my HTML, and also I like how well LLMs write it.
Also my JS is very "contained" as I write SSR web applications. I also really like how Alpine.js makes my use of JS very "close to the HTML". I'd say using Alpine helps my LLM to deliver more maintainable JS code (in case of SSR web apps).
I'm thinking about this right now. I only need a marketing site and I'd love to go back to pure HTML, which the following site believes is a good idea:
Frameworks, linters, compilers.. they contain codified lessons you'd be silly to not leverage in your work - agentic or otherwise. Using what others have built before you helps you get there faster.
Making your own framework is great if you're in no hurry at all - maybe you want to learn, or maybe that's part of what you're selling. For everyone else, use the approach that gives you the most leverage.
You'll have to pry Django from my cold, dead hands.
Like others, I use AI to write code these days, but that makes it all the more important that I can make sense of it quickly. The conventions of a framework help with that.
Also, the boat may be leaving, but I still have one foot on the shore. I'm holding on to my independence - even if I might be kidding myself and it turns out I'll be dependent on AI from here on out. I just can't shake the feeling that the rug (or maybe more appropriately - flying carpet) might be pulled out from under me.
(For what it's worth, I gave up on React over 5 years ago)
Frameworks function the same in the agentic era as they did prior: as guardrails to prevent people from doing silly things and to keep implementations focused and bounded. Yes, they still matter.
But IMO, React didn't go as far as it could have; partly because it is backend-agnostic. You still have to re-implement a lot of the same wiring over and over and you keep running into the same issues and vulnerabilities. Also React offers too many ways to do the same thing; it just confuses the LLM as it mixes all different approaches, it lacks a clear philosophy to provide the guardrails you mentioned.
We should be able to just deal with pure UX issues/tradeoffs; we shouldn't be running into technical issues.
There has never been a better time to write frameworks that constrain how things have been done.
Almost all of our work is on our framework internally. The latency, guarantees, build time errors, and feedback that can enable vibe coding individual implementations.
I find myself constantly wishing for more framework code; I wish we had built our original framework in something that threw angrily when we abused it more.
I wish our type system were more expressive, I wish our threading story were better, I wish I wish I wish.
It’s never been easier to rework the whole thing, and I still am happiest when our framework is artisanal.
Frameworks matter, but they should be focused on minimizing the amount and complexity of code per feature.
The more feature-dense your code is, the less unnecessary hurdles and complexity, the more reliable your software is and the easier to extend and maintain. The more code can fit into the LLM's context window, the more complex your application can become whilst remaining reliable.
I built my own framework which is declarative HTML web components with a serverless backend (similar to Firebase but optimized for AI so that the AI can interact with the control panel, impersonate users and test access controls by itself) and it's so easy to create new features. It's just pure UX work. Just telling the AI what the problems are. Once fixed, it's fixed for good. By contrast, with a standard framework, I have to spend a lot of time debugging technical problems and keep running into regressions and it takes way longer to fix anything and requires coding knowledge.
LLMs work really well with custom frameworks provided that they're well documented via agent skills.
React doesn't provide optimal abstractions for safe and efficient LLM coding IMO; when building applications, React still makes you duplicate a lot of work and create a lot of custom components. A lot of the wiring has to be re-created over and over. If you really think about the essence of a web UI; it's just sections with lists of records, single records (loaded based on ID), single fields of specific records, forms... And each one requires access control rules which should be enforced by the backend; ideally in a declarative way so that it's easy to audit. IMO, the backend access control rules should be exhaustively auditable so that the AI can impersonate all the roles and access all possible resources in all possible states to verify that access control is enforced correctly in all possible situations. Anything less than that is not suitable for vibe-coding IMO. A user who doesn't even know what access control means cannot possibly build a secure application.
We need different kind of frameworks now. The ones that make agent's coding easier and more robust etc. Human ergonomics will be given secondary to no consideration on those frameworks.
I found that what me/ my project/ my LLM needed to arrange this was very elaborate architecture tests: tests that check if some architecture rules are still upheld on the main (and test!) codebases.
If I find a violation of a arch rule (e.g.: a db query defined in HTTP-handler code), I codify that arch rule in the architecture tests.
Libraries exist to help writing arch tests, but you can also let your LLM come up with something custom.
I think the architecture, language framework etc need a completely different view now that programming is not limited by human constraints like speed, effort and thinking. May be something like compilers. A programming language or framework which is built specifically for automated and non-deterministic behaviour.
We might need different kind of rules/constraints because at the end we rely on LLMs to respect or use those rules. Frontier labs are best placed to build something like this making it part of LLM speak.
Do they matter? Yes. Should you use them? No. (Mostly)
This is going to be opinionated from an extreme "vibe code" viewpoint, but I think the future is "GAD" Governed Agentic Development. Designing constraints that agents must follow, and therefore different forms of frameworks. What the agents need is lines in a coloring book, the human is responsible for drawing those lines. So frameworks of the future should be focused on constraining an agent to develop properly, or designing what is and is not permitted.
> So frameworks of the future should be focused on constraining an agent to develop properly, or designing what is and is not permitted.
Frameworks have always done this. Make it easy to do the right thing, add friction to doing the wrong things. Swapping s/programmers/agents/ doesn't make this some brand new earth shattering idea.
If anything agents make the job of designing frameworks or leading architecture easier because they at least have the patience to read the docs even if they don't always have the working memory to follow it all. As opposed to most humans who both don't have the working memory and don't even bother to read.
Even though I'm not a web developer I resonate with this a lot, but in the more generic way of "Does understanding the code even matter anymore ?". And it makes me kind of sad.
I just graduated (and was very lucky to get a junior job), and I'm someone that likes to dig deep when I'm having issues with a software. I care about correctness, I prefer to use strongly typed languages, I never used Haskell professionally, but I do all the advent of code with it. I like reading precise documentation.
But yesterday, my father showed me an app he made using Mistral's Vibe and android studio. He's in IT support, he knows computer science even though he never learned Kotlin or anything, but he was able to "make" an app, and he was excited, and I was happy for him as well, but only happy because he was happy basically.
I used this opportunity to ask him lots of questions about how he approached it, does he care that his only source for "how the code works" is the AI's own explanations. And basically we ended up at "if it's not critical" (it was just a launcher app for his phone) "it's fine".
But then, even though I myself never "vibe coded" an app or anything, I feel like I am always underestimating what AI can do now with all of the projects popping up. It seems almost magical, because I have no idea of the process behind it.
And it makes me think about when (not if) we'll just stop reviewing the AI code collectively, like 90% people stopped verifying compiler outputs except in very special cases.
I don't like the non-deterministic/fuzzy nature of AI coding, and I can't really bring myself to use it more, and I don't like the fact that I'm kind of drifting away from the software development scene.
But maybe I'm thinking about the future too much, I'm selfishly hoping we will hit a bottleneck, and it's not right to be selfish about something like this.
I'm a software engineer with nearly 10 years of professional experience and I feel the same as you and I still think it's a good thing.
But: You have to unblock yourself (I was blocked, too) and dive into using AI as it is a tool that, even if it stays on the level it is right now, won't go away and is useful.
What blocks me still though is, imho, for professional work, as long as it's not possible to let an AI take on some work, be it green field work or searching for a nasty bug in an existing project, and know it will come out with a proper solution in the end, one or more humans should know the code. If a productive application doesn't work and this burns money of your employer you're going to burn, not the AI. There's no process of blaming an AI as it's just a tool and instead the human stays responsible.
Until then whatever AIs implement should be constrained and guidelined as much as possible, covered with tests, to reduce the space in which they operate which in turn reduces the space of potential garbage. Essentially the same as for human developers. If you just tell one "I want an app" he can build you whatever he wants, telling him in detail what you need, want and expect results in useful work. Same for AI.
One thing I tend to urge developers to do is to think about any experience they have of working with team members, or leading a team. In all but the smallest collaborative situations you end up not knowing the entire system and needing to trust your co-workers. So most of us already have worked on systems where we don't know the entire system.
We're comfortable with that - or at least accept it - because there isn't an alternative that would let us built large systems.
This isn't to suggest that any specific current AI system is good enough for us to bypass human oversight, but the concern about giving up control is the same general concern we have for a new co-worker, not about the concept of giving up control and oversight over part of the system because we already regularly do that.
I have preferred not using a framework for a while, pre-LLM, because frameworks would introduce many new failure modes into my codebase, including:
- bloat and assumptions I didn't ask for
- constraints that I otherwise wouldn't encounter
- failure modes related to the framework making breaking changes in updates
However, this basically meant implementing my own framework in a project. Which was fine.
I have now, over time, constructed a framework for agentic coding, because I found myself using the same prompting patterns...
I added a REPL in my software for internal use by Claude. I _really_ wanted it to be Clojure. I had it perform increasingly more complex benchmarks... and they kept coming a wash.
I know it's a small example, but it's a real effect that languages/libraries/frameworks become less and less important, when intelligence and code generation get better and cheaper.
Put into 4chan lingo, the thing can IMO be reduced to
> Inflammatory Headline
> Time-wasting text
Which is even more confusing to me, given that multiple people proof-read this, and it still turned out to be this sprawling stream of consciousness?
I suppose the charitable interpretation is "engineer trying to make sense of the noise that is AI hype and marketing", but it reads to me more of a hexdump of a checkpoint in that process, instead of an actual result.
It would also do a lot better with a different headline I think.
Like "I've been thinking about things people say about AI and frameworks" or similar. Something that is not reproducing the noise the author (apparently?) tries to calm and cut through.
The idea is of course to have a hook to get people to click, but that is exactly the kind nonsense our current hellworld is made of. We should not be reproducing what the industry that is devouring reality does just because it works well within their metrics.
__
So googling the guy tells me that the occupation is "Remix Developer Relations Manager". ._.
The point of a framework is to provide structure - a uniform pattern. A shared language. A way of thinking about the problem space. Maybe a shared set of chunks in congitive science parlance. I think how you handle composition, state, network, routing, etc is also fundamentally a part of the framework - it's not just the view layer.
My take is that frameworks matter less the more it is just agents, emitting code. The frameworks were just tools supposedly making the job easier. We have much better tools now.
Take web environment. It matters a little to your large coding buddies, whether they emit React or vanilla JS. For this particular instance, the learning set was pretty much similar, consisting of both React version of given app, and vanilla version (or even C/C++ version, since going thru wasm is a viable approach). It is possible that some core concepts (such as virtual DOM or redux-like store) are less likely to disappear, but the chances are that there is just no sound need for React-like framework in already pretty mature vanilla JS world.
Somewhat of a sidenote, take reverse engineering. It is a common thing nowadays to have your favorite closed source library / app "disassembled" and put together "anew". Any frameworks used for creation of the original app are irrelevant.
the ai agent is forced to follow some kind of structure you can comprehend. without a framework you don't even have an idea how to refactor this LLM ball of mud
It would be great of AI could surface some learnings/pain points from its daily work in a centralised fashion, just like humans sometimes do. This leads to development of good libraries and frameworks. Right now AI just leads to many siloed sessions that keep solving and resolving same problems in isolation.
I very strongly agree though that we do need to summarize all the human metadiscussion and somehow map that to all the possible ways to express those ideas as code. This mapping is at least one of the reasons we are all still employed.
We have no such tools today. What we have instead is a NLP search engine that sloppily spits out fragments like sucking from a straw that has a hole in it.
Just a few years ago, before the LLM-assisted-coding-era, I already did not like frameworks as much as I used to.
I liked Rails. But that was more because through Rails I learned the MVC pattern, learned the layer-middelware pattern from Rack (and the ActiveRecord ORM -- but I now no longer like ORMs but that's a different story). Those 2 pattern I still use today in some way or form, and I find them in many modern (Rust) web development frameworks/libs.
So I now no longer use Rails for new projects. These projects were all SSR web apps (traditional server-side rendered web apps that use JavaScript sparingly), built with Kotlin+http4k. Http4k is a web library, so no framework there and it feels very good.
The article is very frontend/JS-focussed. I prefer to keep things simpler and just use SSR for the UI. This is because above all (1) I dont like JavaScript (not even when my LLM writes it for me) and (2) for the type of application it is not needed to do state management again in the browser (IMHO it's just more code for the same features).
Sure, a little JS is needed in my apps too. But I (assisted by LLM) use it sparingly and when I use it it's with Alpine.js.
CSS with Tailwind and JS with Alpine makes for pages that are mostly "self contained" (the CSS and JS defined in the same place as the HTML that relates to it), which makes reasoning about them so much easier. For HTML building i use kotlinx.html (an HTML eDSL in Kotlin; HTML as Kotlin code).
I'd say http4k, Tailwind and Alpine are not frameworks. Maybe Alpine is most framework-like of all of these. At least they are not frameworks in the sense that they do not dictate my project folder structure and "how everything ties together".
With http4k the "how everything ties together" answer is in your own project's code, NOT in "the framework" or in 3rd party library code.
In my latest projects (all LLM assisted) I make heavy use of architecture tests: tests on the shape (e.g.: folder structure) of my codebase. These tests check that my architecture rules are adhered to. Think of enforcing the MVC pattern; only the pattern that I use is way more split out (instead of M-V-C, it more like: boot - contract - db - domain - filter - handler - job - lib - path - presentation - routing - workflow).
I'd say framework matter more when:
1. you are learning something, or
2. when the team needs to have shared code hygiene values, or
They matter as much as the author asking the question 10 times over and over in this article. Not much.
It's not worth your time to try to get Claude to use something that isn't what he recommends given the goals of the project. If I'm barely going to read the code, why would I force Claude to choose something that he thinks doesn't fit?
I think frameworks are more important than ever in this AI/vibecoding world if you want to keep any chance for your code to be readable again and not become just a pile of machining that nobody quite gets what it does. The more optioned the framework is the better. The more familiar you are with the framework the better chances you can actually deliver a working thing not just some slop that looks like working.
Source: experience. I decided at some point just to vibecode a fairly complex project with gpt 5.5 sol and Fable.Burned several max subscriptions and it ended up a pile of machinery, impossible to make it work in the end.
Rewrote it/vibecoded it with my framework(s), skills, lab conventions etc and it works flawlessly.
Even better I can figure out immediately if Claude or codex goes off the rails just by seeing the snippets. It just shows the AI models are just not ready to build things “unattended” without proper “steering”. Frameworks and other constrains are a way to steer the AI. Of course bloated frameworks would just make things worse.
This made me understand there are very low chances to just vibecode whatever “business” you want to try and succeed. You still need to know your “s**t”.
Not sure we need any kind of framework any more. I think for web we can get by with bespoke. I’ve made (put agents to make it) a small but not necessarily simple project[1] recently and decided to go raw dom … and it worked quite well.
No special issues with the UI itself. Took some care at the beginning to structure it with reusable components and that’s all.
I think there is still a place, even if they have to adapt.
If one thinks of frameworks, particularly ones like Rails, as higher-level languages, it makes sense. Why aren't we coding everything in assembly? Models know how humans use programming languages and existing frameworks. Some languages are becoming even more popular (rust, go) because of their performance, and because agents can write the boilerplate without the user needing to be an expert.
Frameworks are (ideally) distilled, opinionated best practices that both humans and agents can understand and implement as another layer of abstraction. I don't think that goes away entirely.
Given the choice, I think I would prefer to go as browser native as possible.
Library code is useful for abstraction but browser native APIs are always going to be more stable over the long term.
If I have to vibe code now then at the very least I should be able to take advantage of agents to reduce the number of external "moving parts" involved by going native.
e.g. https://developer.mozilla.org/en-US/docs/Web/API/Web_compone...
Why bother with an external framework when it's built in? My familiarity with React no longer matters.
I'll probably move towards using library code only for things like cross compatibility shims, to be removed over time, but that's about it.
Also for CSS? I really like how Tailwind puts the CSS in the same place as my HTML, and also I like how well LLMs write it.
Also my JS is very "contained" as I write SSR web applications. I also really like how Alpine.js makes my use of JS very "close to the HTML". I'd say using Alpine helps my LLM to deliver more maintainable JS code (in case of SSR web apps).
I'm thinking about this right now. I only need a marketing site and I'd love to go back to pure HTML, which the following site believes is a good idea:
https://modernmotherfuckingwebsite.dreamstation.systems
Frameworks, linters, compilers.. they contain codified lessons you'd be silly to not leverage in your work - agentic or otherwise. Using what others have built before you helps you get there faster.
Making your own framework is great if you're in no hurry at all - maybe you want to learn, or maybe that's part of what you're selling. For everyone else, use the approach that gives you the most leverage.
For example, this blog may have had syndication (RSS/atom/jsonfeed) by default if a blogging framework was leveraged.
You'll have to pry Django from my cold, dead hands.
Like others, I use AI to write code these days, but that makes it all the more important that I can make sense of it quickly. The conventions of a framework help with that.
Also, the boat may be leaving, but I still have one foot on the shore. I'm holding on to my independence - even if I might be kidding myself and it turns out I'll be dependent on AI from here on out. I just can't shake the feeling that the rug (or maybe more appropriately - flying carpet) might be pulled out from under me.
(For what it's worth, I gave up on React over 5 years ago)
Frameworks function the same in the agentic era as they did prior: as guardrails to prevent people from doing silly things and to keep implementations focused and bounded. Yes, they still matter.
But IMO, React didn't go as far as it could have; partly because it is backend-agnostic. You still have to re-implement a lot of the same wiring over and over and you keep running into the same issues and vulnerabilities. Also React offers too many ways to do the same thing; it just confuses the LLM as it mixes all different approaches, it lacks a clear philosophy to provide the guardrails you mentioned.
We should be able to just deal with pure UX issues/tradeoffs; we shouldn't be running into technical issues.
There has never been a better time to write frameworks that constrain how things have been done.
Almost all of our work is on our framework internally. The latency, guarantees, build time errors, and feedback that can enable vibe coding individual implementations.
I find myself constantly wishing for more framework code; I wish we had built our original framework in something that threw angrily when we abused it more.
I wish our type system were more expressive, I wish our threading story were better, I wish I wish I wish.
It’s never been easier to rework the whole thing, and I still am happiest when our framework is artisanal.
So much this. For all the things where speed and reliability matters, and you have a clear cut interface - frameworks.
Closer to the surface frameworks tend to add complexity and restrictions, not remove it.
Frameworks matter, but they should be focused on minimizing the amount and complexity of code per feature.
The more feature-dense your code is, the less unnecessary hurdles and complexity, the more reliable your software is and the easier to extend and maintain. The more code can fit into the LLM's context window, the more complex your application can become whilst remaining reliable.
I built my own framework which is declarative HTML web components with a serverless backend (similar to Firebase but optimized for AI so that the AI can interact with the control panel, impersonate users and test access controls by itself) and it's so easy to create new features. It's just pure UX work. Just telling the AI what the problems are. Once fixed, it's fixed for good. By contrast, with a standard framework, I have to spend a lot of time debugging technical problems and keep running into regressions and it takes way longer to fix anything and requires coding knowledge.
LLMs work really well with custom frameworks provided that they're well documented via agent skills.
React doesn't provide optimal abstractions for safe and efficient LLM coding IMO; when building applications, React still makes you duplicate a lot of work and create a lot of custom components. A lot of the wiring has to be re-created over and over. If you really think about the essence of a web UI; it's just sections with lists of records, single records (loaded based on ID), single fields of specific records, forms... And each one requires access control rules which should be enforced by the backend; ideally in a declarative way so that it's easy to audit. IMO, the backend access control rules should be exhaustively auditable so that the AI can impersonate all the roles and access all possible resources in all possible states to verify that access control is enforced correctly in all possible situations. Anything less than that is not suitable for vibe-coding IMO. A user who doesn't even know what access control means cannot possibly build a secure application.
We need different kind of frameworks now. The ones that make agent's coding easier and more robust etc. Human ergonomics will be given secondary to no consideration on those frameworks.
I found that what me/ my project/ my LLM needed to arrange this was very elaborate architecture tests: tests that check if some architecture rules are still upheld on the main (and test!) codebases.
If I find a violation of a arch rule (e.g.: a db query defined in HTTP-handler code), I codify that arch rule in the architecture tests.
Libraries exist to help writing arch tests, but you can also let your LLM come up with something custom.
I think the architecture, language framework etc need a completely different view now that programming is not limited by human constraints like speed, effort and thinking. May be something like compilers. A programming language or framework which is built specifically for automated and non-deterministic behaviour.
We might need different kind of rules/constraints because at the end we rely on LLMs to respect or use those rules. Frontier labs are best placed to build something like this making it part of LLM speak.
Do they matter? Yes. Should you use them? No. (Mostly)
This is going to be opinionated from an extreme "vibe code" viewpoint, but I think the future is "GAD" Governed Agentic Development. Designing constraints that agents must follow, and therefore different forms of frameworks. What the agents need is lines in a coloring book, the human is responsible for drawing those lines. So frameworks of the future should be focused on constraining an agent to develop properly, or designing what is and is not permitted.
Building Autonomously, Open Source: https://github.com/pullboard-dev/pullboard
> So frameworks of the future should be focused on constraining an agent to develop properly, or designing what is and is not permitted.
Frameworks have always done this. Make it easy to do the right thing, add friction to doing the wrong things. Swapping s/programmers/agents/ doesn't make this some brand new earth shattering idea.
If anything agents make the job of designing frameworks or leading architecture easier because they at least have the patience to read the docs even if they don't always have the working memory to follow it all. As opposed to most humans who both don't have the working memory and don't even bother to read.
That's the wrong way of thinking of it. It should be Governed OAgentic Development, a.k.a GOD
Even though I'm not a web developer I resonate with this a lot, but in the more generic way of "Does understanding the code even matter anymore ?". And it makes me kind of sad.
I just graduated (and was very lucky to get a junior job), and I'm someone that likes to dig deep when I'm having issues with a software. I care about correctness, I prefer to use strongly typed languages, I never used Haskell professionally, but I do all the advent of code with it. I like reading precise documentation.
But yesterday, my father showed me an app he made using Mistral's Vibe and android studio. He's in IT support, he knows computer science even though he never learned Kotlin or anything, but he was able to "make" an app, and he was excited, and I was happy for him as well, but only happy because he was happy basically.
I used this opportunity to ask him lots of questions about how he approached it, does he care that his only source for "how the code works" is the AI's own explanations. And basically we ended up at "if it's not critical" (it was just a launcher app for his phone) "it's fine".
But then, even though I myself never "vibe coded" an app or anything, I feel like I am always underestimating what AI can do now with all of the projects popping up. It seems almost magical, because I have no idea of the process behind it.
And it makes me think about when (not if) we'll just stop reviewing the AI code collectively, like 90% people stopped verifying compiler outputs except in very special cases.
I don't like the non-deterministic/fuzzy nature of AI coding, and I can't really bring myself to use it more, and I don't like the fact that I'm kind of drifting away from the software development scene.
But maybe I'm thinking about the future too much, I'm selfishly hoping we will hit a bottleneck, and it's not right to be selfish about something like this.
I'm a software engineer with nearly 10 years of professional experience and I feel the same as you and I still think it's a good thing. But: You have to unblock yourself (I was blocked, too) and dive into using AI as it is a tool that, even if it stays on the level it is right now, won't go away and is useful.
What blocks me still though is, imho, for professional work, as long as it's not possible to let an AI take on some work, be it green field work or searching for a nasty bug in an existing project, and know it will come out with a proper solution in the end, one or more humans should know the code. If a productive application doesn't work and this burns money of your employer you're going to burn, not the AI. There's no process of blaming an AI as it's just a tool and instead the human stays responsible.
Until then whatever AIs implement should be constrained and guidelined as much as possible, covered with tests, to reduce the space in which they operate which in turn reduces the space of potential garbage. Essentially the same as for human developers. If you just tell one "I want an app" he can build you whatever he wants, telling him in detail what you need, want and expect results in useful work. Same for AI.
One thing I tend to urge developers to do is to think about any experience they have of working with team members, or leading a team. In all but the smallest collaborative situations you end up not knowing the entire system and needing to trust your co-workers. So most of us already have worked on systems where we don't know the entire system.
We're comfortable with that - or at least accept it - because there isn't an alternative that would let us built large systems.
This isn't to suggest that any specific current AI system is good enough for us to bypass human oversight, but the concern about giving up control is the same general concern we have for a new co-worker, not about the concept of giving up control and oversight over part of the system because we already regularly do that.
I think as we move forward the answer to the question ‘is it critical?’ will just move to support vibe coding everything.
I have preferred not using a framework for a while, pre-LLM, because frameworks would introduce many new failure modes into my codebase, including: - bloat and assumptions I didn't ask for - constraints that I otherwise wouldn't encounter - failure modes related to the framework making breaking changes in updates
However, this basically meant implementing my own framework in a project. Which was fine.
I have now, over time, constructed a framework for agentic coding, because I found myself using the same prompting patterns...
I added a REPL in my software for internal use by Claude. I _really_ wanted it to be Clojure. I had it perform increasingly more complex benchmarks... and they kept coming a wash.
I know it's a small example, but it's a real effect that languages/libraries/frameworks become less and less important, when intelligence and code generation get better and cheaper.
Is it?
When you have to understand something yourself, do you rather read C, JS or C#?
In the end of the day I have to be able to read it, in anger, when things go south...
Some libs have amazing APIs (many in C# and Kotlin are well done); some libs have horrible APIs (many libs in PHP and JS look horrible to me).
In the end of the day I have to be able to read it, in anger, when things go south...
Put into 4chan lingo, the thing can IMO be reduced to
> Inflammatory Headline
> Time-wasting text
Which is even more confusing to me, given that multiple people proof-read this, and it still turned out to be this sprawling stream of consciousness?
I suppose the charitable interpretation is "engineer trying to make sense of the noise that is AI hype and marketing", but it reads to me more of a hexdump of a checkpoint in that process, instead of an actual result.
It would also do a lot better with a different headline I think.
Like "I've been thinking about things people say about AI and frameworks" or similar. Something that is not reproducing the noise the author (apparently?) tries to calm and cut through.
The idea is of course to have a hook to get people to click, but that is exactly the kind nonsense our current hellworld is made of. We should not be reproducing what the industry that is devouring reality does just because it works well within their metrics.
__
So googling the guy tells me that the occupation is "Remix Developer Relations Manager". ._.
So it works exactly as it is supposed to. Oh man.
The point of a framework is to provide structure - a uniform pattern. A shared language. A way of thinking about the problem space. Maybe a shared set of chunks in congitive science parlance. I think how you handle composition, state, network, routing, etc is also fundamentally a part of the framework - it's not just the view layer.
My take on this is vamp: https://dlants.me/vamp.html
I've been using it with joy on all of my side projects, and feel quite miserable when I return to react.
My take is that frameworks matter less the more it is just agents, emitting code. The frameworks were just tools supposedly making the job easier. We have much better tools now.
Take web environment. It matters a little to your large coding buddies, whether they emit React or vanilla JS. For this particular instance, the learning set was pretty much similar, consisting of both React version of given app, and vanilla version (or even C/C++ version, since going thru wasm is a viable approach). It is possible that some core concepts (such as virtual DOM or redux-like store) are less likely to disappear, but the chances are that there is just no sound need for React-like framework in already pretty mature vanilla JS world.
Somewhat of a sidenote, take reverse engineering. It is a common thing nowadays to have your favorite closed source library / app "disassembled" and put together "anew". Any frameworks used for creation of the original app are irrelevant.
they matter even more.
the ai agent is forced to follow some kind of structure you can comprehend. without a framework you don't even have an idea how to refactor this LLM ball of mud
point an ai at it.
It would be great of AI could surface some learnings/pain points from its daily work in a centralised fashion, just like humans sometimes do. This leads to development of good libraries and frameworks. Right now AI just leads to many siloed sessions that keep solving and resolving same problems in isolation.
LLMs are the not the future on that.
I very strongly agree though that we do need to summarize all the human metadiscussion and somehow map that to all the possible ways to express those ideas as code. This mapping is at least one of the reasons we are all still employed.
We have no such tools today. What we have instead is a NLP search engine that sloppily spits out fragments like sucking from a straw that has a hole in it.
To refine this further, I think we can more confidently say cross-platform frameworks do not matter anymore.
Just a few years ago, before the LLM-assisted-coding-era, I already did not like frameworks as much as I used to.
I liked Rails. But that was more because through Rails I learned the MVC pattern, learned the layer-middelware pattern from Rack (and the ActiveRecord ORM -- but I now no longer like ORMs but that's a different story). Those 2 pattern I still use today in some way or form, and I find them in many modern (Rust) web development frameworks/libs.
So I now no longer use Rails for new projects. These projects were all SSR web apps (traditional server-side rendered web apps that use JavaScript sparingly), built with Kotlin+http4k. Http4k is a web library, so no framework there and it feels very good.
The article is very frontend/JS-focussed. I prefer to keep things simpler and just use SSR for the UI. This is because above all (1) I dont like JavaScript (not even when my LLM writes it for me) and (2) for the type of application it is not needed to do state management again in the browser (IMHO it's just more code for the same features).
Sure, a little JS is needed in my apps too. But I (assisted by LLM) use it sparingly and when I use it it's with Alpine.js.
CSS with Tailwind and JS with Alpine makes for pages that are mostly "self contained" (the CSS and JS defined in the same place as the HTML that relates to it), which makes reasoning about them so much easier. For HTML building i use kotlinx.html (an HTML eDSL in Kotlin; HTML as Kotlin code).
I'd say http4k, Tailwind and Alpine are not frameworks. Maybe Alpine is most framework-like of all of these. At least they are not frameworks in the sense that they do not dictate my project folder structure and "how everything ties together".
With http4k the "how everything ties together" answer is in your own project's code, NOT in "the framework" or in 3rd party library code.
In my latest projects (all LLM assisted) I make heavy use of architecture tests: tests on the shape (e.g.: folder structure) of my codebase. These tests check that my architecture rules are adhered to. Think of enforcing the MVC pattern; only the pattern that I use is way more split out (instead of M-V-C, it more like: boot - contract - db - domain - filter - handler - job - lib - path - presentation - routing - workflow).
I'd say framework matter more when:
1. you are learning something, or
2. when the team needs to have shared code hygiene values, or
3. when you do not use architecture tests yet!
I asked pretty much the same question in another thread and someone told me abstractions allowed for better use (less) of tokens.
They matter as much as the author asking the question 10 times over and over in this article. Not much.
It's not worth your time to try to get Claude to use something that isn't what he recommends given the goals of the project. If I'm barely going to read the code, why would I force Claude to choose something that he thinks doesn't fit?
You think claude is a person, animal, or even alive in any way?
If there are going to be multiple browsers with different implementation of the same standard frameworks will still matter.
If there are going to be no standard for basic things like a combo box frameworks will still matter.
Interfaces and their proven abstractions are highly valuable. The implementations themselves, however, are completely replaceable.
In web development:
Frameworks- possibly.
TypeScript, and other metalanguages- probably not.
I think frameworks are more important than ever in this AI/vibecoding world if you want to keep any chance for your code to be readable again and not become just a pile of machining that nobody quite gets what it does. The more optioned the framework is the better. The more familiar you are with the framework the better chances you can actually deliver a working thing not just some slop that looks like working.
Source: experience. I decided at some point just to vibecode a fairly complex project with gpt 5.5 sol and Fable.Burned several max subscriptions and it ended up a pile of machinery, impossible to make it work in the end. Rewrote it/vibecoded it with my framework(s), skills, lab conventions etc and it works flawlessly.
Even better I can figure out immediately if Claude or codex goes off the rails just by seeing the snippets. It just shows the AI models are just not ready to build things “unattended” without proper “steering”. Frameworks and other constrains are a way to steer the AI. Of course bloated frameworks would just make things worse.
This made me understand there are very low chances to just vibecode whatever “business” you want to try and succeed. You still need to know your “s**t”.
Not sure we need any kind of framework any more. I think for web we can get by with bespoke. I’ve made (put agents to make it) a small but not necessarily simple project[1] recently and decided to go raw dom … and it worked quite well.
No special issues with the UI itself. Took some care at the beginning to structure it with reusable components and that’s all.
[1] https://tinker3d.app/
What problem does your project solve?
Yes because they give AI agents direction and so they can do better work.
Look into architecture tests. By leveraging those you can get any project to have those benefits.
I think there is still a place, even if they have to adapt.
If one thinks of frameworks, particularly ones like Rails, as higher-level languages, it makes sense. Why aren't we coding everything in assembly? Models know how humans use programming languages and existing frameworks. Some languages are becoming even more popular (rust, go) because of their performance, and because agents can write the boilerplate without the user needing to be an expert.
Frameworks are (ideally) distilled, opinionated best practices that both humans and agents can understand and implement as another layer of abstraction. I don't think that goes away entirely.
React came up in a time where little to no attention was paid to what HTML, CSS JS, WebComponents, etc could increasingly do out of the box.
Frameworks have their benefits, some are just way more complex to output the same html/css at the end of the day in some cases.