We are excited about React Compiler, aren't we? I just remembered that my first OSS library in JavaScript was a JS-to-JS compiler! Funny how things come around.
Hearing about all the changes in #React19 is giving me anxiety. I've been working on #React apps at my past four or five jobs now, but I just have no interest in relearning #ReactJS for the upteenth time, and I'm worried that is going to impact my ability to get another job if I ever decide to go back to work.
What would be your practical advices/tips to avoid creating the worse app who will require 5 peoples to rewrite the codebase every 3y, when having to create a middle-sized SPA in ReactJS in 2024?
It’s needs to be :
an SPA (statically hosted)
As performant as possible and not a nightmare to maintain
I’m planning on using React-Aria to ensure myself to have accessible components on micro-levels (and so it’s requires react-dom)
@tixie My main suggestion would be to use some standard tooling like Vite or Next.js (statically exported), which has two main advantages:
You won't have a million-lines Webpack config to maintain.
You're forced to stay on the relatively beaten path, without using esoteric tools that are more likely to break and that future maintainers are more likely to not be familiar with.
Skew Protection solves two problems with frontend applications:
If users try to request assets (like CSS or JavaScript files) in the middle of a deployment, Skew Protection enables truly zero-downtime rollouts and ensures those requests resolve successfully.
Outdated clients are able to call the correct API endpoints (or React Server Actions) when new server code is published from the latest deployment.
"This reminds me of a hammer I had with a broken handle. Instead of replacing the handle, I attached the hammer to a helmet and whenever I want to drive a nail, I would wear the hammer and swing my head. But sometimes I miss and hit my head against the wall instead. So to fix that, I added some padding to my forehead and now it doesn’t hurt at all.