Having a build step more than pays for itself just in terms of detecting errors without having to execute that codepath. The friction is becoming less and less as the compilation step is increasingly built into your project/dependency management tool and increasingly faster (helped by the trend towards Rust or Go now that the required functionality is relatively well-understood)
> 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.
An LLM can probably generate the ad hoc, informally-specified, bug-ridden, slow implementation of half of React that every non-React application needs very quickly, sure. But can the LLM help you comprehend it (or fix bugs in it) any faster? That's always been the biggest cost, not the initial write.
To see how fast a properly engineered app can be if it avoids using shitty js frameworks just look at fastmail. The comparison with gmail is almost comical: every UI element responds immediately, where gmail renders at 5 fps.
> [literally unusable]
> [one of the most successful web apps]
> [look at how bad it is]
Your standards might be uncalibrated with reality
I use gmail every day and it's fine, apart from when they push AI features I don't want, but I can't blame that on the framework
The problem is that you’ve (and we all have) learned to accept absolute garbage. It’s clearly possible to do better, because smaller companies have managed to build well functioning software that exceeds the performance of Google’s slop by a factor of 50.
I’m not saying RETVRN to plain JS, but clearly the horrid performance of modern web apps has /something/ to do with the 2 frameworks they’re all built on.
Tried a cleared cache load, open and usable in 3 seconds, loading my work inbox which is fairly busy and not clean.
I'm not sure what FPS has to do with this? Have you some sort of fancy windows 11 animations extension installed that star wipes from inbox to email view and it's stuttering??
I click and email it shows instantly, the only thing close to "low FPS" is it loads in some styles for a calendar notification and there's a minor layout shift on the email.
What / how are you using it that you apparently get such piss poor performance?
Nonsense. Apps from all frameworks and none show the same performance issues, and you can find exceptionally snappy examples from almost all frameworks too. Modern webapps are slow because the business incentives are to make them slow, the technology choices are incidental.
We're all used to it and that's fine. But it's still bad. We're still wasting, like, 10,000x more resources than we should to do basic things, and stuff still only works, like, 50% of the time.
And IT IS SLOW, despite your experience, which is highly dependant on how much hardware can you throw at it.
The past couple of weeks I've been having loading times up to 1 minute to open gmail.
No idea what they are up to. Loading google workshop or something like that, takes eons.
> [literally unusable]
It's gotten a lot of critique over the complexity it has over the years, the same way how Next.js also has. I've also seen a frickload of render loops and in some cases think Vue just does hooks better (Composition API) and also state management better (Pinia, closer to MobX than Redux), meanwhile their SFC compiler doesn't seem to support TypeScript types properly so if you try to do extends and need to create wrapper components around non-trivial libraries (e.g. PrimeVue) then you're in for a bunch of pain.
I don't think any mainstream options are literally unusable, but they all kinda suck in subtly different ways. Then again, so did jQuery for anything non-trivial. And also most back end options also kind of suck, just in different ways (e.g. Spring Boot version upgrades across major versions and how verbose the configuration is, the performance of Python and the dependency management at least before uv), same could be said for DBs (PostgreSQL is pretty decent, MariaDB/MySQL has its hard edges) and pretty much everything else.
Doesn't mean that you can't critique what's bad in hopes of things maybe improving a bit (that Spring Boot config is still better than Spring XML config). GMail is mostly okay as is, then again the standards for GUI software are so low they're on the floor - also extends to Electron apps.
There was also a time where once a website or application loaded, scrolling never lagged. Now when something scrolls smoothly it's unusual, and I appreciate it. Discord has done a really good job improving their laggy scroll, but it's still unbelievably laggy for literal text and images, and they use animation tricks to cover up some of the lag.
Anyone doing serious HTML rendering with WebAssembly today A) has a build step, B) still has a bunch of JS to do memory buffer FFI/IPC and decoding/encoding, C) is usually using some form of Virtual DOM in the Wasm side and the JS side is some version of JSON-driven React/Preact-Lite. It is not today more efficient than React's build process nor React's runtime experience.
Anyone shipping production code will one way of another have some kind of build step, whether that's bundling, minification, typechecking, linting, finger printing files, etc. At that point it makes little difference if you add a build step for compilation.
I'm sympathetic to not wanting to deal with build processes I try to avoid them where I can in my side projects. The main web project I've been working on for the last year has no build step, uses Vanilla JS & web components. But it's also not a consumer facing product.
I think there's friction for sure, but I just can't see this being an issue for most cases where a build step is already in place for other concerns. And Developers are fairly familiar with build steps especially if you do anything outside the web in C/C++ or Java/C# or Rust or whatever.
If you've got a huge project, even very quick bundlers will end up slowing down considerably (although hot reload should still be pretty quick because it still just affects individual files). But in general, bundlers are pretty damn quick these days, and getting even quicker. And of course, they're still fully optional, even for a framework like React.
Unfortunately there isn't any one preferred alternative convention. But if you ignore his and roll your own it will almost certainly be better. Not great for reading other people's code but you can make your own files pretty clear.
If you're thinking of _Redux_, are you referring to the early conventions of "folder-by-type" file structures? ie `actions/todos.js`, `reducers/todos.js`, `constants/todos.js`? If so, there's perfectly understandable reasons why we ended up there:
- as programmers we try to "keep code of different kinds in different files", so you'd separate action creator definitions from reducer logic
- but we want to have consistency and avoid accidental typos, especially in untyped plain JS, so you'd extract the string constants like `const ADD_TODO = "ADD_TODO"` into their own file for reuse in both places
To be clear that was never a requirement for using Redux, although the docs did show that pattern. We eventually concluded that the "folder-by-feature" approach was better:
- https://redux.js.org/style-guide/#structure-files-as-feature...
and in fact the original "Redux Ducks" approach for single-file logic was created by the community just a couple months after Redux was created:
- https://github.com/erikras/ducks-modular-redux
which is what we later turned into "Redux slices", a single file with a `createSlice` call that has your reducer logic and generates the action creators for you:
- https://redux.js.org/tutorials/essentials/part-2-app-structu...
E.g., if most developers are telling their LLMs “build me a react app” or “I want to build a website with the most popular framework,” they were going to end up with a react app with or without LLMs existing.
I’m sure a lot of vibecoders are letting Jesus take the wheel, but in my vibecoding sessions I definitely tend to have some kind of discussion about my needs and requirements before choosing a framework. I’m also seeing more developers talking about using LLMs with instructions files and project requirement documents that they write and store in their repo before getting started with prompting, and once you discover that paradigm you don’t tend to go back.
My actual long term hope is that in the future we won't need to think about frameworks at all: https://paul.kinlan.me/will-we-care-about-frameworks-in-the-...
Yes! That's exactly what I was trying to get at.
Is there something about the web — with its eternal backwards compatibility, crazy array of implementations, and 3 programming languages — that seems like it's the ideal platform for a framework-free existence?
Maybe if we bake all of the ideas into JavaScript itself, but then where does it stop? Is PHP done evolving? Does Java, by itself, do everything as well as you want out of Spring?
I sincerely doubt that either of JSX's syntax or its semantics under React's transforms would make it into a W3 or WHAT spec as they exist today.
Not exclusively. SolidJS, for example, transforms the syntax into string templates with holes in them. The "each element is a function call" approach works really well if those calls are cheap (i.e. with a VDOM), but if you're generating DOM nodes, you typically want to group all your calls together and pass the result to the browser as a string and let it figure out how to parse it.
For example, if you've got some JSX like:
<div>
<div>
<span>{text}</span>
<div>
<div>
const template = parseHtml(`
<div>
<div>
<span></span>
<div>
<div>
`);
template.children[0].children[0].innerText = text
It's really not slow. It might seems slow if you're using react behavior which re-invokes the "render function" any time anything changes. But eventually they get reconciled into the DOM which creates the elements anyway. And most other code bases are not based on this reconciliation concept. So I don't think that's a given.
Also, there's no reconciliation happening here. In SolidJS, as well as in Vue in the new Vapor mode, and Svelte, the element that is returned from a block of JSX (or a template in Svelte) is the DOM element that you work with. That's why you don't need to keep rerendering these components - there's no diffing or reconciliation happening, instead changes to data are directly translated into updates to a given DOM node.
But even if you don't need to worry about subsequent re-renders like with VDOM-based frameworks, you still need to worry about that initial render. And that goes a lot quicker if you can treat a JSX block as a holistic unit rather than as individual function calls.
The difference shrinks even further with `<template>`/HtmlTemplateElement, its secondary/content `document`s for `document.createElement` and `document.importNode` being faster for cloning+adoption of a `template.contents` into the main document than string parsing.
I've got work-in-progress branch in a library of mine using JSX to build HtmlTemplateElements directly with `document.createElement` and right now `document.createElement` is the least of my performance concerns and there is no reason to build strings instead of elements.
(ETA: There are of course reasons to serialize elements to strings for SSR, but that's handy enough to do with a DOM emulator like JSDOM rather than need both an elements path and a string path.)
The library [0] I wrote that uses JSX converts expression attributes into parameter-less lambdas before providing them as function parameters or object properties. This is a different behavior than react's build tools or any of typescripts jsx options. But it's not inconsistent with the spec.
The space that the Babel/Typescript JSX options describe is a constructive space for more than just React.
I can't find the author making that argument. Can you point to where they're declaring that React has permanently won?
> 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.
This is orthogonal to what the article is addressing.
> 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
If you didn't read the article, I think you should. Because this is generally the conclusion that the author comes to. That in order to break out of React's grip, LLM's can be trained to use other frameworks.
So I guess I'm in agreement with the author: let's actively work to make that not happen.
I'd note that people learn and accumulate knowledge as new languages and frameworks develop, despite there being established practices. There is a momentum for sure, but it doesn't preclude development of new things.
(For the AI-sceptics, you can read this as models are equally bad at all code)
Like, if you really believe that in the future 95% of code will be written by LLMs, then there can never be a Python 4, because there would be no humans to create new training data.
To me, this is evidence that LLMs won’t be writing 95% of code, unless we really do get to some sort of mythical “AGI” where the AI can learn entirely from its own output and improve itself exponentially. (In which case there would still wouldn’t be a Python 4, it would be some indecipherable LLM speak.) I’ll believe that when I see it.
Most programming languages are similar enough to existing languages that you only need to know a small number of details to use them: what's the core syntax for variables, loops, conditionals and functions? How does memory management work? What's the concurrency model?
For many languages you can fit all of that, including illustrative examples, in a few thousand tokens of text.
So ship your new programming language with a Claude Skills style document and give your early adopters the ability to write it with LLMs. The LLMs should handle that very well, especially if they get to run an agentic loop against a compiler or even a linter that you provide.
OK, it wasn't a Claude Skill, but it was done using Claude.
That said, part of what he did with Cursed was get LLMs to read its own documentation and use that to test and demonstrate the language.
I think that’s correct in terms of the surface-level details but less true for the more abstract concepts.
If you’ve tried any of the popular AI builders that use Supabase/PostgREST as a backend, for instance Lovable, you’ll see that they are constantly failing because of how unusual PostgREST is. I’m sure these platforms have “AI cheat sheets” to try to solve this, but you still see constant problems with things like RLS, for instance.
Is it better to specify the parameters and metrics —aka non-functional requirements —that matter for the application, and let LLMs decide? For that matter, why even provide that? Aren't the non-functional requirements generally understood?
It is the specifics that would change—scale to 100K monthly users, keep infrastructure costs below $800K, or integrate with existing Stripe APIs.
As a recovering C++ programmer the idea that a basically instant compilation step is a source of friction is hysterical to me.
Try waiting overnight for a build to finish. Frontend devs don't know they're born. It takes like 5 minutes to set up vite.
React and TS people are making sure that is not the case anymore, allegedly for our own benefit.
Similarly with TypeScript, having worked with and without it, I get so much from it that is a no-brainer for me. But maybe I'm just in the pocket of Big TypeScript and this is more of that gaslighting you were worried about... ;)
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.