> The New York Times has published millions of articles with hundreds of different components and tens of thousands of custom embedded interactives. Of course we wanted to fix all of our hydration mismatches, but how could we do so safely?
I don't think that alone is a good reason to use React everywhere, but it's probably easier to just hire for that one stack than to try to maintain a vanilla JS stack and shim React into just the visualizations.
IMO React generally makes life easier for developers (at the cost of bundle bloat for end-users). The Times probably found it an acceptable tradeoff. Their website seems pretty fast to me, FWIW, even throttled down to 3G.
It's the same reason companies with tiny apps in the cloud default to kubernetes even though it could have been done with something simpler like AWS lambda.
I believe React/Vue will ultimately be replaced by recent modern developments using websockets to trigger the delivery of server side static async views. This is how Github/Shopify now does it, ala Elixir's LiveView, and Rails itself also has ActionCable+Turbo/Hotwire. It is far superior as it keeps logic in one place in the backend and in one language. But that is far from mainstream yet like React is and there will always be legacy features that need to be supported.
But hopefully it will become the standard and JS will limited to necessity.
For ex: some components on pages like charts/graphs, multi select boxes with autocomplete, etc will still require JS that websocket/ajax triggered views can't replace. But those are easier to package into standard libraries. Whether reactive vDOM will still be needed for that idk.
Consider that backbone.js was developed by Jeremy Ashkenas to solve problems the NYT had with its layout. Perhaps the problems they have are more complex than what you suspect?
I monitor the first paint on many sites, and the more js the later the paint. None can beat a normal site with some js niceties that trigger on dom ready.
Selling React as “fast” has got to be one of the greatest bamboozles of all time. I know I thought it was fast when I first started.
It’s reasonably fast for what it does, but the overhead of virtual DOM diffing has real performance costs compared to vanilla.
React makes it really easy to make things slow. At my job it isn’t uncommon for a single list item component to take 2ms to render on a fast machine. Multiply that by a few dozen list items, and suddenly your feature is taking hundreds of ms to rerender. Sure, you can improve things with virtual rendering and targeted optimizations, but the default case is not fast.
It’s especially insane when you consider that video games can render a high fidelity 3D scene in under 16ms.
If your company’s front end that happens to have react is slow, I’m willing to bet removing react will make it even slower.
So, we can only hire artisans who hand tailor every event handler, who writes bespoke careful updates that never conflict and always handle every corner case of the dom right? And you and your 63 clones that NYT has hired will all work in harmony & concordance doing your bespoke vanillajs practices.
Reacts vdom is pretty sweet. Even the old iterations of React can go eliminate a lot of paints. Old websites used to have plenty of write-read-write loops that internally block the dom, that react's lifecycle generally helps guard against. The article here talks about even further improved batch updating that React 18 can help with.
Apologies my attitude, but it's just remarkably how much rancis ass attitude there is about React & how fucking stupid it sounds. I know it's the internet, that people will forever be springing up to spout off, but it's so sad having such miserable negativity hounding such perfectly respectable tech.
NYT site is fast, but is broke as hell. Even turning off uBlock it downloads 10mb of assets before the fold and still doesn't work.
This is more salt of the earth reality, maybe you're projecting the snooty nose-in-the-air boutique'ness of React.
I generally agree that most sites are pretty bad, are way too big & usually with poor data-architectures (over fetching, re fetching, poor or no data caching). Data storage is notably something React nor very few other things have tried to tackle. GraphQL made a forray & for a while seemed ascendant but it's moment seems to be passing. The core issue of client-server model is still pretty informally handled.
But even that has nothing to do with the very obvious & bad issue, that many sites are loaded with obnoxious & heavyweight & surveiling ad payloads. But it's unclear to me again what React has to do with this. (Especially as few of these as systems use React.)
And like they said, for complex interactive parts they are not even using React!
Any other interactivity can be solved with few vanilla js snippets.
You can easily do no refresh behavior with turbolinks like approach.
I would understand if it was an actual web app, with tons of complex crud and other things.