React: The Perils of Rehydration

In the Next.js/Vercel world, this hybrid architecture is primarily (I believe) an issue of cost savings (for them and you). For $20/mo Vercel will host your hybrid Next.js side, yet do all of the backend configuration and maintenance on your behalf, configuring not just NPM but Lambda and Cloudflare Workers, along with nginx and caching and CDN mirroring and invalidations, all seamlessly.

So as a dev you can just code against the Next.js docs and not have to play devops. That's a LOT of time savings for $20/mo, and you can afford way more page hits this way than a barebones $20/mo NPM VM would get you. Yes, backend it's super complex and fanned out to different providers, but Vercel manages all of that for you.

I imagine Gatsby and Netlify are similar, but not sure. Next.js was designed around Vercel specifically (sadly) and there's a lot of vendor-specific lock-in features.

It seems somewhat unlikely for a number of reasons. The article was quite long, so I didn't read it all, but a key takeaway seemed to be "Gatsby only uses the server-side rendering APIs when building for production". SvelteKit does SSR rendering in development as well, so you wouldn't have the issue of dev and production being different in that way. Also, Svelte's hydration works a bit differently than React's.

This is a hilarious idea, bonus points if you somehow wrap it in electron with its own local sql lite instance and pitch it as a cross platform desktop app development toolkit.

I completely get that this ease of configuration is a huge selling point. Yet I don't think that precludes the possibility of pre-loading information and injecting it at runtime. My main qualm here is probably one where the meaning behind terms like "server-side rendering" are drifting to favor artificial limitations imposed by framework providers.

> Next.js was designed around Vercel specifically (sadly) and there's a lot of vendor-specific lock-in features.

I ran into this while playing around with their middleware. It surprised me that native Node APIs weren't supported which significantly diminishes its utility.

Didn’t read the article, but I have to rant a little bit.

Working with `useEffect()` is so fucking miserable. It’s a bit like owning a car where the gaps between the panels are just slightly too far apart; there’s always the possibility that some data is out of sync because React inexplicably decided to run a thing a tick later than you expected. “Effects” don’t actually mix with with the old class component methods, insofar as you’ll never be able to get an effect to run before component methods, so you end up having to gasp do side-effects in render against a bunch of “refs” to achieve some semblance of object permanence.

The implication behind the naming of “synchronous effects” as `useLayoutEffect()` is laughable, as though the only time you would ever want to run some code synchronously is for “layout” purposes. My guy, JavaScript’s security model is based on execution, you can’t copy to the clipboard, request full-screen/picture-in-picture, do countless privileged operations outside the synchronous execution of a native click handler, for instance, and we’re going to place all these use-cases under the umbrella term “layout?”

React applications are weird, shuddering messes, where callbacks fire senselessly based on “dependency arrays.” Heaven forfend you turn off linting which helps you not violate “the rules of hooks,” and even when it’s on there are countless gotchas about default parameters and callback functions which are recreated every render. At no point will you ever be able to correctly source the initiator of a “render,” because someone in their infinite wisdom decided to unroll the JavaScript call stack as a queue. Stepping out of a component in a debugger always places you in the same `while` loop and you’re left wondering where on Earth did this execution start. I don’t understand how programmers could be so ignorant of how useful a call stack is, and the React team essentially has to recreate call stacks in error messages and Devtools. Seasoned React developers have all seen “React minified error #185,” or “Maximum update depth exceeded.” This is essentially a stack overflow error, except of course they did away with the stack. It’s not normal for stack overflow errors to be happening as frequently as happens in React applications, and this is just when you’re lucky enough to get a warning; a lot of times the page will just hang and no one except your poor users will know.

I find it truly disturbing how professionals can make their and everyone’s lives so difficult, how deeply disconnected React is from the actual practice of programming, which is all about understanding how your code executes. My mind is boggled by 5 by 5 zoom calls of well-paid “staff engineers” chatting about React and writing tutorial upon tutorial like any of this normal. And these are the loud ones. I pray for the entry-level programmers, the contractors, the voiceless, who aren’t beefing on Twitter, who do not have a sense of how strange this kind of development is and don’t have the courage to speak up.