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.

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.

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.

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

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

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

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.

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?

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/

Yes because they give AI agents direction and so they can do better work.

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.