Can someone who's worked in an org this large help me understand how this happens? They surely do testing against major browsers and saw the performance issues before releasing. Is there really someone who gave the green light?
replies(8):
Todays version is: "You will get fired unless you use React".
So every site now uses React no matter if the end result is a dog slow Github.
Bad developers looks at "what are everybody else using?".
Good developers looks at "what is the best and simplest (KISS) tool for this?"
Good ol’ SSR - but eventually users and PMs start requesting features that can only be implemented with an SPA system, and I (begrudgingly) accept their arguments.
In my role (of many) as technical architect for my org, and as an act of resistance (and possibly to intentionally sabotage LLMs taking over), I opted for hybrid SSR + Svelte - it’s working well for us.
We had/have a similar problem where things began with "a sprinkle of js here/there" and then over time those islands became much bigger and encompassed more and more functionality. Entire backend templates were ported to the JS framework and then the page with load and then stuff would pop in after the DOMReady event was fired and the JS booted.
I've been working backwards to remove many of these changes and handle them server side if possible or at least give a better UX while the frontend is getting ready. It's not easy!
In a perfect world, we could run the output of the PHP backend through a JS SSR endpoint and hydrate the few necessary components into full HTML, but unfortunately, many of today's JS SSR tools are only available if you use the meta framework as well.
What's going to be fun over the next year is finally deciding if we should go "all-in" on a JS frontend (using Inertia.js for the communication with the backend) or go back to PHP entirely and try to leverage more browser capabilities. There's not really a right/wrong answer but if marketing want's to keep adding flashy features, having the flexibility of JS would be handy.