> 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.
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.
The problem with React apologetics is that you need to only take a cursory look at literally every production app written in React to see it's terrible and must be abandoned in the long-term.
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.
Well yeah, most software is bad. In fact it's so bad that's its almost unbelievable.
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.
GMail is becoming the Lotus Notes of the 21st century. It uses half a gigabyte of RAM, for evey tab. God forbid you need to handle several accounts, i.e., for monitoring DMARC reports across domains.
And IT IS SLOW, despite your experience, which is highly dependant on how much hardware can you throw at it.
> [most used web framework, powering innumerable successful businesses]
> [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.
My friend, it renders at 15 fps on a literal supercomputer. It takes 30 seconds to load. The time between clicking a button and something happening is measured in seconds. It may be successful, but it is not good.
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?
> clearly the horrid performance of modern web apps has /something/ to do with the 2 frameworks they’re all built on.
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.
Enshitification, I've been using Gmail for decades and it was significantly faster and more responsive in the past. It still works fine tbh, but it did work better. Whether or not something is successful has little to do with its quality or performance these days.
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.
That's not quite true. There are a number of languages which compile to JavaScript, e.g., Elm, and provide an API for interacting with the DOM, as well as some kind of FFI.
Couldn’t you use WebAssembly? I think (?) GP’s point is that it would make more sense to use a different language that compiles to WebAssembly. (Or transpile to Javascript I guess, but I don’t know why you’d do that.)
WebAssembly still doesn't have direct DOM bindings. That's at least two levels deeper and several more standards to go after the very basic Wasm GC that was only just recently standardized. For the moment you basically have an FFI/IPC bridge that you can send TypedArray buffers and attempt to UTF-8 decode them and then JSON.parse that on the JS side. (We don't even have strings agreed upon yet, mostly just arrays of bytes. Wasm Strings is a possible standard still in the process.)
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.
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.