[go: up one dir, main page]

Change and risk

Kelly Sutton on why his team views big front-end frameworks as a liability:

Maybe it’s the changing interest rates or political winds, but I think the “fat client” era JS-heavy frontends is on its way out. The hype around edge applications is misplaced and unnecessary for building many different flavors of successful businesses.

My translation here: what’s good for business often isn’t what’s cool or tracking at the top of the orange website or what has most likes on GitHub. A product can be extremely useful and interesting and still be on the most boring tech stack imaginable.

But also, this bit:

Change comes with risk, and changing untested code has a higher regression risk. [...] 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.

At most places I’ve worked at, any amount of change feels extremely risky and that sentiment at one point or another moves out of the codebase and into every meeting and discussion. So I think that as a small dev team, where every moment is precious, perhaps the most important thing is reliability in a codebase.

And big, overly complicated JS-heavy frontends are anything but reliable.