Last week, it came to light Cursor had mostly finished migrating from SolidJS to React. This migration happened about seven months ago. But it beca...
For further actions, you may consider blocking this person and/or reporting abuse
This is exactly what I'm affraid of. I even wrote about it a few months ago in this article. AI is slowly reinforcing what already works.
I mean, haven’t we all noticed that every AI-generated idea seems to be React + Vite + supabase shipped on Vercel? 😂
I wonder why this keeps happening.
Of course, part of it is the sheer volume of existing examples. AI is heavily influenced by what it has seen before. If there are 50 examples using React, 10 using Vue, and 2 using Angular, it’s not surprising that React becomes the default recommendation.
The problem is that people who are vibe coding often don’t know these nuances. They don’t necessarily know that the AI is giving them the most common solution, and not the best solution for their particular problem.
And if you don’t know enough to question the recommendation, the default becomes the decision.
Cursor's unintentional migration of “a verdict” is probably the scariest part of this.
All it takes is one big tech company picking a questionable stack, and suddenly models start recommending C++ for frontend because “Google did it,” complete with a convincing explanation.
Then every least-technical person happily clicks Generate or Approve simply because the AI said it, big-tech documentation mentioned it, and it somehow came up with a good-sounding reason.
I think that, just like when Rust first came out, there were questions about its performance and whether it could compete with established languages. But after years of development and hard work, here we are with Rust gaining adoption all over the world.
Solid is solid, and I believe we’ll see a future with clear, light-blue skies!
A stack choice needs an explicit owner and an expiry date for its assumptions. The costly part is rarely picking the wrong tool on day one; it is letting an unexamined choice become architecture after the original constraint has disappeared.
Well said. As AI makes development faster, choosing the right technology and understanding its trade-offs become even more important. I also agree that strong verification and feedback can often matter more than simply having more data. Technical judgment will definitely become a key skill as AI continues to shape software development.
Hmm yeah:
/batch migrate src/ from Solid to ReactI can certainly imagine that that hurt a bit - while:
/batch migrate src/ from React to Solidwould be so much more logical :-) ... maybe you can suggest that to them?
P.S. I really hope that AI isn't gonna lead to a "monoculture", be it in programming languages, frameworks, or even in fields outside of programming/development ...
The buried Claude docs tip existing months before the Cursor story broke is the part that reframed the week for me. Once migrations are cheap, a verdict with no argument travels farther than a careful writeup, because nothing is left to slow it down. Bun published bug classes people could disagree with in public. A Solid to React tip in a tip sheet cannot be checked, only repeated. The TanStack RSC posts that measured, reversed, and explained why are the habit I wish more agent migration demos copied.
The stacks nobody argued for are usually fine until an agent starts making changes to them, because a human picking the path of least resistance still has some intuition for where the edges are. An agent inherits none of that intuition unless the boundary is written down somewhere it actually reads.
You already say that optics and politics beat technical merit, so I want to add the economic side rather than argue with you.
There is a reason this homogenisation is convenient for the people at the top, and Joel Spolsky named it in Strategy Letter V: commoditize your complement. If you sell the platform, you want the layer above it to become cheap, interchangeable and boring. You never have to beat the better small library — you only have to make the choice stop mattering. Verdicts generated at scale do that work for you, for free.
What worries me more than the monoculture itself is what travels inside it. A verdict still carries values even when it carries no argument: ergonomics and speed first, maintainability and legibility later. Those values get absorbed as if they were technical facts, because nobody sees them being argued.
Nobody cares about my stack, and that is fine. What we are all quietly relying on is that somebody keeps feeding the infrastructure with actual ideas. That part does not scale with training data.
wild that cursor switched back to react, thought the performance gains from solidjs would be too good to pass up for an ide
This is becoming more important with AI making implementation cheaper. The scarce skill shifts from “how do we build it?” to “why is this the right decision for this system?”
The situation is becoming increasingly difficult
I think the bigger story behind Solid’s evolution is that the era of heavyweight frameworks is ending — not because Solid is “another framework,” but because the browser finally became the framework.
For years, React, Angular, Vue, and others existed to compensate for missing browser capabilities: slow DOM, no components, no module system, no async primitives, no encapsulation, no routing, no streaming. Solid’s fine‑grained reactivity was a brilliant response to that era — but the landscape has changed.
HTML5 and modern browser APIs now cover almost everything frameworks originally had to reinvent. The DOM is fast. Web Components exist. ES modules are native. Shadow DOM, container queries, async/await, Streams, Navigation API — the platform is finally the stable substrate we always wanted.
That’s why composition matters more than ever. When you build on HTML instead of abstracting away from it, you get automatic compatibility with everything that exists today and everything the browser will gain tomorrow. Solid’s direction makes sense precisely because it embraces the platform instead of fighting it. Its reactivity model feels less like a “framework” and more like a capability you attach to native elements — almost like injecting behaviors at runtime into the HTML ontology itself.
If the browser is the rock, then Solid’s job isn’t to replace it. It’s to make composition ergonomic, predictable, and fast. And that’s exactly where the future is heading: capability‑driven architecture, not framework‑driven architecture.
Solid is evolving in the right direction because it’s aligned with the platform, not competing with it.
I love the optimism from the web platform folks. Things have improved significantly in the past 15 years since I started paying attention to this. That being said, from my perspective, the gap hasn't really closed. As a framework author, I keep my eye on the progression of these standards, but I also need to acknowledge many will take half a decade to show up — or even longer. So while this can influence design space the practicality of it all lags.
I think the biggest gap, if there is one, between my positioning and the platform, is that my scope is beyond just the web platform. I think even SSR pulls us into that before looking at native. While certain standards bodies can paint a good over-the-wire story, they aren't responsible for managing both sides which is why things like Web Components on the server, Declarative Shadow DOM, etc... can be done but rarely take a shape I'd consider optimal from an interop perspective. My long-held position is that Web Components are just architecturally a miss, and cause the wrong grouping of responsibilities. Which is difficult position because outside of them and their related features I am very much a big supporter of the web platform's direction.
Agreed, I'm a little more steadfast on the goodness of HTML5 and the continuous improvements it's making. After all, it's the only standard there is, it must succeed. This is the project I'm working on now to demonstrate "pure composition". Simply inject the behaviors needed. github.com/CieloVistaSoftware/wb-s...
This is a solid breakdown of React patterns. In my experience, the real challenge emerges when you need to optimize re-renders in complex component trees — have you explored React's concurrent features for this use case?
This is a really thoughtful perspective. I especially agree with the distinction between a technical verdict and an actual technical argument.
As AI makes migrations and implementation dramatically cheaper, I think the scarce skill increasingly becomes evaluating why a technology is appropriate for a particular problem—not simply knowing how to implement it. The point about verification being an alternative to sheer volume is particularly interesting; deterministic feedback can sometimes matter more than how much training data exists for a technology.
I also appreciate that you applied the same standard to React, Solid, Rust, and the broader ecosystem rather than turning this into a framework-vs-framework argument. The question of how new ideas emerge when AI increasingly influences technical defaults is definitely worth thinking about.
I think stack is no more important. The stack is sevice for consumer, the consumer needn't to know what it is, just want the web page is fast, beautiful, that's ok. Just after a few days, AI can generate binary machine code, no more framework need. The computer reback their origin appearance.
When AI become powerful enough, it will not only good at popular frameworks, but also good at minority ones, then personal taste may hold the upper hand. github.com/J-F-Liu