> To me, if a SPA is > 500kb of JS my assumption is it’s unnecessarily bloated.
I'm guessing you've never written something that can, for example, dynamically generate XLSX files out of filtered datasets in the browser. Sure, we could do it on the server - but our users value fast and regular turnaround time on feature updates far, far more than the site loading a little slower every few weeks when the cached JS is replaced.
> I'm guessing you've never written something that can, for example, dynamically generate XLSX files out of filtered datasets in the browser.
Guess again :)
> our users value fast and regular turnaround time on feature updates far, far more than the site loading a little slower
That might be acceptable, for a time. Particularly if you’re working on a product that doesn’t have many/any backend developers. Or a backend. Or a product where the developers are more specialized in frontend. Or a product where the backend does not have a mechanism for handling long running tasks
But at some point for features like various file exports in the browser, one might want to fix the “why can’t we build X feature and delight customers as quickly server side”
> one might want to fix the “why can’t we build X feature and delight customers as quickly server side”
Sure. It's just that there's a two- or three-year-long to-do list of features before we can get back to optimizing things that none of the users care about anyway.
If any of our users even notice that once or twice a release cycle the page for the web app takes a little longer to load, they haven't cared about it enough to actually mention it. By contrast, we get a constant flow of new feature requests.
I'm guessing you've never written something that can, for example, dynamically generate XLSX files out of filtered datasets in the browser. Sure, we could do it on the server - but our users value fast and regular turnaround time on feature updates far, far more than the site loading a little slower every few weeks when the cached JS is replaced.