Dead Framework Theory

I don't buy this. The big problem with React is that the compilation step is almost required - and that compilation step is a significant and growing piece of friction.

Compilation and bundling made a lot more sense before browsers got ES modules and HTTP/2. Today you can get a long way without a bundler... and in a world where LLMs are generating code that's actually a more productive way to work.

Telling any LLM "use Vanilla JS" is enough to break them out of the React cycle, and the resulting code works well and, crucially, doesn't require a round-trip through some node.js build mechanism just to start using it.

Call me a wild-eyed optimist, but I'm hoping LLMs can help us break free of React and go back to building things in a simpler way. The problems React solve are mostly around helping developers write less code and avoid having to implement their own annoying state-syncing routines. LLMs can spit out those routines in a split-second.

In front-end as well—I've been able to go much farther for simple projects using alpine than more complex frameworks. For big products I use Elm, which isn't exactly the most common front-end choice but it provides a declarative programming style that forces the LLM to write more correct code faster.

In general, I think introspectible frameworks have a better case, and whether they're present in training data or not becomes more irrelevant as the introspectibility increases. Wiring the Elm compiler to a post-write hook means I basically have not written front-end code in 4 or 5 months. Using web standards and micro frameworks with no build step means the LLM can inspect the behaviour using the chrome dev tools MCP and check its work much more effectively than having to deal with the React loop. The ecosystem is so fragmented there, I'm not sure about the "quality because of quantity of training data" argument.

I think LLMs, despite already being trained massively on React, can easily adapt their output to suit a new framework's-specific API surface with a simple adjustment to the prompt. Maybe include an abbreviated list of type/function signatures that are specific to your new framework and just tell the LLM to use JSX for the views?

What I think will definitely be a challenge for new library authors in the age of LLMs is state management. There are already tons of libraries that basically achieve the same thing but have vastly different APIs. In this case, new lib-authors may be forced to just write pluggable re-implementations of existing libraries just to enable LLMs to emit compilable/runnable code. Though I dont know of any state management library that dominates the web like React does with the view layer.

More broadly, obviously there is some pressure to use a framework/library/programminglang/editor that has better LLM training. But even before LLMs.. you'd want to choose the one that has more SO questions, more blog posts and books published about it. The one where you can hire experienced programmers.

New players has a certain activation energy they need to overcome - which is probably good. B/c it slows down the churn of new shiny with incrementally improvements. I think a paradigm shift is sufficient though. Programmers like new shiny things - especially the good ones that are passionate about their craft

Also, React was extremely popular before any LLMs were out there. I would not ascribe much of the growth to vibe coding.

This too shall pass.

In the meantime real engineers still use the proper tools.

Now, about the incentives? Probably less inference costs for llms, which probably means that they are more legible than the current state of the art for humans as well.

Less API changes than let's say react also means that the generated code as less branching although llms can adapt anyway. Cheaper.

Will probably be closer to the platform too (vanillaJS).

Poking client reqs is such a high value skill, most freelancers will just build what the client asks, "ok here's a react frontend with a postgres db and a crud app for your ecommerce website" instead of asking what the functional requirements are, maybe it can be a shopify thing, or just post it on amazon, or maybe a plain html app (optionally with js)

It can be valid to ask for a brick house if you know what the other ways to build a house are, but if you just asked chatgpt for a house plan and it said "bricks", because it's the most housey thing and you said ok because it rings a bell and sounds housey, having a dev that asks and tells you about wooden houses or steel beams or concrete is the best that can happen.

I appreciate when it happens the other way around, I go to a lawyer and tell them I want a corp, they start off assuming I know my shit, and after 5 minutes we are like, oh I don't want a corp

Should have made graphs testing LLMs with different frameworks.

It will be interesting to see how durable these biases are as labs work towards developing more capable small models that are less reliant on memorized information. My naive instinct is that these biases will be less salient over time as context windows improve and models become increasingly capable of processing documentation as a part of their code writing loop, but also that, in the absence of instruction to the contrary, the models will favor working with these tools as a default for quite some time.

It's fine. I've been using codex on some code bases with this with pretty alright results. I also use codex to generate typescript/react code. I'm getting similar results. I had a little wow moment when I asked it to add some buttons and then afterwards realized that it had figured out the localization framework (one of my creations) and added translations for the button labels. All unprompted. It clearly understood the code base and how I like things done. So it just went ahead and did them. The syntax is not a problem. The obscurity of the library is not a problem as long as you give it enough to work with. It does less well coding something from scratch than working on existing code.

IMHO, things like react are optimized for humans. They aren't actually that optimal for LLMs to work with. It's actually impressive that they can. Too much expressiveness and ambiguity. LLMs like things spelled out. Humans don't. We're still doing things manually so it helps if we can read and edit what the LLMs do. But that won't stay like that.

I think in a few years, we'll start seeing languages and frameworks that are more optimal for Agentic coding tools as they will be the main users. So, stronger typing. More verbosity and less ambiguity.

I try to filter out such people in hiring nowadays but sometimes you miss, or come into an existing team with these issues

I had to ditch the whole thing and rewrite it in Vue when it got big enough that I couldn’t debug it without learning React.

Vibe-coding something in a stack you know or want to know means you can get off your high horse and peek into the engine.

I still agree with the sentiment that React is winning; if the competition of volume. But other frameworks won’t stop existing unless you believe that people exclusively choose what is dominant. But there will always be artisans, even after all old people who learned the alternatives were flushed out.

I absolutely wouldn't be swapping because the output 'isn't good enough'.

Worse, with LLM's easily generating boilerplate, there's less pressure to make old framework code concise or clear, and the superior usability of a new framework won't be a big draw.

But coding is a primary application/profit center, and you can be sure they'll reduce the latency between release and model support, and they'll start to emphasize/suggest new frameworks/paradigms as a distinguishing feature.

My concern is about gaming the system, like SEO. If LLM coding is the gatekeeper, they'll be corrupted by companies seeking access/exposure. Developer uptake used to be a reasonable measure of quality, but in this new world it might only reflect exposure.