Nobody Argued For Your Stack
11 points by nolan
11 points by nolan
From "Why Gumroad Didn't Choose htmx" (2024):
It's worth noting that AI tools are intimately familiar with Next.js and not so much with htmx, due to the lack of open-source training data. […] While not a dealbreaker, it did impact our development speed and the ease of finding solutions to problems. When we encountered issues, the wealth of resources available for React/Next.js made troubleshooting much faster.
See also: "AI is stifling tech adoption" (2025).
i think this is a bad argument against htmx
because htmx is mostly html and REST, which LLMs understand very well and htmx is like 3k lines of code, which you can just stick in every context window
to be fair, context windows were smaller and would confuse models more in 2024. these days, you can have it use your own htmx-like it's never seen before, and it'll do fine
Not sure if I agree that the issue is particularly new and catastrophic.
If today's machinery had existed in 2013, models trained on a web that was all jQuery and Backbone, [...], do you think it could have gotten past that stage?
I think it would.
If today's machinery is good enough to efficiently do the stack decisions for those who don't care about them, it's also good enough to free time for innovating on the stack for those who do care.
Also, I don't think putting a dubious /batch migrate from solid to react
example on the Anthropic Docs is "that bad." They're just trying to show off a
decently impressive LLM ability, with an example that highlights the model's
strength. We shouldn't expect better from them. But also, I don't think this
sort of semi-official favoritism is much worse than it's ever been.
If today's machinery is good enough to efficiently do the stack decisions for those who don't care about them, it's also good enough to free time for innovating on the stack for those who do care.
Why? What is the connection between those things?
Is every human who can write decent React/Java/Python capable of making a serious comparison of their preferred language to the alternatives? Capable of inventing the alternatives?
Sorry, that was badly phrased.
I'm not saying they are the same people. I'm saying the same machinery (AI) empowers both groups independently:
I think the drive and the fundamental need to innovate (plus the extra AI help mentioned above) are enough to offset the monoculture tendencies that AI enables, when it comes to giving space for innovation.
The article links a tweet about Cursor migrating to React, and this is a first for me, hearing about migrating from Solid to React, partially because of performance reasons? I wonder what the numbers are here.
The tweet mentions:
it is actually quite easy to create perf footguns for yourself in signal based approaches when reactivity causes a large amount of accidental fan out in large and complex apps.
Depends? I need some more explanation on how that's possible in Solid.
I suspect it's mostly because of Reactisms being hallucinated into SolidJS codebases - it's definitely a problem I've experienced.
To give a concrete example, in React, the component function is called every time a component's state changes and should generate a VDOM tree that can be diffed against the real DOM. Everything inside curly braces is evaluated once eagerly during that call. So something like
<ul>
{arr.map(i=> <li id={i.id} />)}
</ul>
makes perfect sense as an idiom.
On the other hand, in SolidJS, the component function is called once per instance, and should generate a real DOM node with all its reactivity and event handlers hooked up, ready to be inserted into the page somewhere. And in particular, anything inside curly braces becomes a reactive "thunk" that will get called every time the data is uses changes. So the code above now means that every time arr or any of its contents changes, the whole array of <li> nodes is recreated from scratch, even if none of them changed.
In this specific case (mapping over arrays) the solution is to use a specific function that diffs the old and new arrays and decides whether to create a new node, reorder nodes, etc. There is a linter that explicitly catches this case as well, so it's usually fairly easy to spot. But it's harder to write a single clear rule for the general case of doing unnecessary node creation - you really just need to take the time to understand how signals and reactive data flow work, and then it becomes intuitive.
I suspect this is basically what's happening here, but writ large and not as easy to lint for or notice without understanding what your framework actually does. The LLM generates a mix of SolidJS and React idioms, and where that generates errors, it can fix those errors automatically, but where it generates low-level performance issues, nothing really gets done about it. Whereas if you just switched to React, you accept a certain performance baseline, but you also don't have as many issues with hallucinations.
That sounds like a reason for new things to try to be as facially unlike their competitors as possible.
Yeah, I think it's probably SolidJS's biggest weakness - both for LLMs and for people coming from React, it's often hard to recognise when you're doing something wrong just because that's how you'd do it in React. On the other hand, React really gets a lot of DX stuff right, particularly in terms of being able to easily split apart components (a component is just a function, not an entire file), and being able to encapsulate logic into convenient mixins (i.e. hooks). And JSX is very well supported in the ecosystem, whereas creating your own custom templating language is not.
So I can see the reason why Ryan made SolidJS look the way it does, and personally I quite like it being that way, but yeah, it does cause issues when it looks so much like React but the internal reactivity model is so different.
(FWIW, I think SolidJS is a fantastic framework, and it's typically my go-to for anything where I need a lot of reactivity in the frontend -- i.e. where vanilla JS isn't enough. It's also been the source of a lot of innovation in the frontend, and I suspect Ryan's new Suspense stuff will probably also be copied and adopted in other places in different forms. But it's also not the world's most popular framework, and I think a lot of that is to do with the difficulty in switching your head over from React to SolidJS when coming in for the first time.)
On the other hand I can imagine it would also be an uphill battle if it strongly diverged from React, because then it is up there with Vue/Svelte or things from other languages like Elixir's LiveView.
I still like React(it's things like Next.js that sours me), but I found Astro or Svelte(or even preact) all better options in terms of ease-of-use and DX.