With AI, you barely need a frontend framework
15 points by dlants
15 points by dlants
I’m not sure binning static guarantees because LLMs can generate boilerplate is a very compelling argument to me
That argument made sense when humans were writing every line. It doesn't hold up when an AI agent is writing (or modifying) the code.
yes I too want to have to traverse extremely large amounts of boilerplate to try and spot the places where the agent inevitably screwed up.
What matters for AI isn't conciseness, it's explicitness, locality and predictability.
Beyond the obvious problem that it’s awfully nice if a human can read, review, and understand the output, that ignores context size and token budget. Giant blobs of boilerplate aren’t really efficient even if LLMs are reading and writing them, and it’s possible that conciseness is even more important in the long run when using LLMs extensively.
I think the problems in React as showcased in the appendix are overblown.
If an update happens while interacting with this input, you can often end up in a situation where the input loses the typed text, or loses focus. (see link for many, many examples of folks running into this sort of issue)
As far as I know, this only happens when you define functions within render(). A cursory glance through the link shows that to be the culprit in many cases. It's a well-known anti-pattern; if you're using eslint with eslint-plugin-react-hooks, you'll immediately get nagged on:
Error: Cannot create components during render
Components created during render will reset their state each time they are created. Declare components outside of render.
On hooks:
Because of this, the hook list must be deterministic - the hooks must always appear in the same order, and the list must always be of the same length.
I'm not sure what the problem with this is? This is just the nature of hooks—they need to be on the top level of render() with no conditionality. This is clearly laid out in the Rules of Hooks.
Another common problem with hooks is the dependency arrays. It’s really easy to get into situations where one effect updates another, updates another. It becomes difficult to reason about what the order of things is, and also possible to create infinite chains of hooks. Generally we shouldn’t need complex dependency chains like this and should default to using a dispatch / reducer pattern as with other more complex views, but these things tend to accumulate over time.
Just because React lets you use side-effects doesn't mean you have to use them to create an unholy dependency monstrosity. What you're describing is the result of a misunderstanding and overuse of useEffect, which is a common footgun for sure, but then again, not a compelling reason to start looking for alternative frameworks. (The rule of thumb here is to never use effects unless you have no other option.)
React's VDOM renders and diffing operations are notoriously costly. The solution that many teams reach for is tuning shouldUpdate calls, or pulling in libraries like immer to provide immutable state, so the framework can short-circuit updates based on object reference equality.
I don't think "many teams" are using class-based components anymore in the first place? I remember implementing these sorts of optimizations... in 2016. This is anecdotal, but our team has steered clear of any obvious performance issues since by using function components and by following best practices with the help of linting.
I'm not sold on ditching react or on this specific replacement, but i do think that the underlying principle is sound: now that ai agents are writing the code, we should optimize for the outcomes we want, and the things we optimize for will be completely different.
Reminds me of how the golang designers optimized for locality over expressive power, leading to verbose repetitive error handling, because they themselves were not their target audience.
The question is no longer, "how do i want my code to look?" but rather "what constraints do i want to put on their code to get the outcomes i want?" And the agents don't really have personal preferences.
I appreciate that you read it with a principle of charity! And I think you articulated it very nicely. I think I value transparency, explicitness, and not having to fight with framework internals and tooling, so this was the structure that fell out of that.
Ok, I'm convinced modern coding AIs can write web apps using minimal frameworks. But I'm unclear why this is better?
React has some problems, sure. But minimal frameworks have more!
AI might be able to write apps with minimal frameworks. But you lose out so much.
Plain javascript with jsdoc annotations and you get an LSP. I've never used a React Devtool in my life but I use the browser devtool all the time. The training corpus is absolutely chock full of javascript and dom stuff. the browser literally has everything you need the framework isn't providing much value over an opinionated way to use what the browser provides. This may be useful but it's not the advantage that is usually identified for a framework.
The other big advantage frameworks gave you is the speed of getting started and the speed of development. Coding agents remove that benefit entirely.
I've never used a React Devtool in my life
But do you use React? I do not use use it often enough but there are two features I used a lot: check what components rerender after a change, and getting a "fake DOM representation" based on components tree.
the framework isn't providing much value over an opinionated way to use what the browser provides
The biggest advantage React provided was an easy way to implement reactive programming, and even though it's not opinionated enough, it was surely stricter than having an own way for each project.
Only vary rarely do I use react. I tend to prefer a simple signals library and custom-elements. I was doing this without LLMs though. I just find it much easier to debug and reason about what my code is doing without react in the middle.
"Many frameworks require tools like JSX or are their own languages like Svelte, adding custom tooling which may not be compatible with [...] your IDE."
Yeah I don't undrstand what IDE they are referring to. There might be some bespoke editors not capable of making use of an LSP, but that's hardly a generalizable argument.
Did you use an LLM to co-author this piece? The structure really reads LLM to me, but some of the details make me think I'm either over-indexing a little bit or you've done something different with the prompt.
I write these in neovim with my AI coding plugin, so yes I do use the LLM for some things. I like to use it for throwing down ideas quickly and finding initial words, but I tend to go sentence by sentence at the end and edit things heavily once I get to a certain point.
The structure of the piece - building the framework up step by step from templates to bindings to slots, was my decision.