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

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

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.

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.

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.

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) and it's so easy to create new features. It's just pure UX work. By contrast, with standard framework, I have to spend a lot of time debugging coding problems and keep running into regressions.