Moving on from React, a Year Later (link)

• Web
• Performance
• Javascript

Kelly Sutton shares their experience after a year of replacing React with a JavaScript-light approach.

One of the arguments for a SPA is that it provides a more reactive customer experience. I think that’s mostly debunked at this point, due to the performance creep and complexity that comes in with a more complicated client-server relationship.

While there are examples of well-built SPAs, the opposite are far more common. On the other hand, traditional server-rendered applications can provide great experiences by taking advantage of platform features like back/forward cache and view transitions. The reality is that most web applications don’t need the added complexity of managing everything with JavaScript. If you are not building something with Figma’s level of complexity, it’s probably not worth it.

These liabilities become realized costs when we need to change the code. Change comes with risk, and changing untested code has a higher regression risk. We can compensate for riskier changes with moving more slowly or methodically. Moving more slowly is fine in many cases. But when compared to a world where that change isn’t risky (server-rendered ERB), we are suddenly paying a very pricey tax for making changes in JavaScript.

I’ve frequently seen this on many teams, and I’ve experienced it myself. Changes in JavaScript are far more expensive and difficult to make than changes to the logic you have in your server-side code.

Original article: Moving on from React, a Year Later