Seems to me if you want an "equal" experience across the board, you make the clients responsible for the bare minimum functionality. Everything that can be is processed server-side. You should target the lowest common denominator wherever possible. Anything else is tantamount to digital elitism or simply bad customer service.
Assuming compute & bandwidth costs are fixed, are there any remaining justifications for doing SPA, et. al., especially if the server is required at all times in order to satisfy application requests? Is pushing a final compressed DOM over the wire really all that much worse than pushing 20 different JSON objects in order to recompose the same logical DOM client-side? Doesn't it seem like one of these approaches would be substantially faster and easier than the other in most cases?
I think we got off track somewhere around when cloud computing was introduced. I can see a huge motivating factor for pushing the "offload to client" narrative if your cloud compute portfolio provides 10% the relative cost-adjusted performance compared to a rack full of DL380s sitting in a colo. With the density of compute being offered today (e.g. 256 x86 cores in a 2U w/ 2TB ram), I feel a lot of businesses should start to look back to these approaches. The software and operating systems have vastly improved as well. Just take look at the performance you get with something like Kestrel in .Net Core:
Nearly 7 million HTTP requests per second on a single 10GBe host. For 99% of business applications out there, just 1 of these servers is probably all you would ever need... A decade ago we were putting the finishing touches on 10k/second. Why the hell are we not aggressively trying to leverage this 100x speedup? Is it because all of this extra margin is being spread thin by Amazon, et. al for purposes of maximum profit extraction? Or, is there a more nuanced game afoot?
SPA is overused to be sure. But people are also building far more complex things on the web now and some of them are difficult or impossible to do purely with SSR. So pick the right tool for the job but let’s not pretend that we can do everything with just one tool.
And you might say those kinds of applications shouldn’t be built on the web but I’d rather have them on the web than locked up in some proprietary app store with all the centralization and potential abuses of power that allows.
Assuming compute & bandwidth costs are fixed, are there any remaining justifications for doing SPA, et. al., especially if the server is required at all times in order to satisfy application requests? Is pushing a final compressed DOM over the wire really all that much worse than pushing 20 different JSON objects in order to recompose the same logical DOM client-side? Doesn't it seem like one of these approaches would be substantially faster and easier than the other in most cases?
I think we got off track somewhere around when cloud computing was introduced. I can see a huge motivating factor for pushing the "offload to client" narrative if your cloud compute portfolio provides 10% the relative cost-adjusted performance compared to a rack full of DL380s sitting in a colo. With the density of compute being offered today (e.g. 256 x86 cores in a 2U w/ 2TB ram), I feel a lot of businesses should start to look back to these approaches. The software and operating systems have vastly improved as well. Just take look at the performance you get with something like Kestrel in .Net Core:
https://www.techempower.com/benchmarks/#section=data-r18&hw=...
Nearly 7 million HTTP requests per second on a single 10GBe host. For 99% of business applications out there, just 1 of these servers is probably all you would ever need... A decade ago we were putting the finishing touches on 10k/second. Why the hell are we not aggressively trying to leverage this 100x speedup? Is it because all of this extra margin is being spread thin by Amazon, et. al for purposes of maximum profit extraction? Or, is there a more nuanced game afoot?