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.
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.
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...
We should be able to just deal with pure UX issues/tradeoffs; we shouldn't be running into technical issues.
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.
If there are going to be no standard for basic things like a combo box frameworks will still matter.
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
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.
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.
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?
> 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.
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.
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.
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.
No special issues with the UI itself. Took some care at the beginning to structure it with reusable components and that’s all.
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.