Anyone else think this client-side app trend has gotten in the way of recognizing a great case for a server-side render (or even a cached page)?
Anyone else think this client-side app trend has gotten in the way of recognizing a great case for a server-side render (or even a cached page)?
10 - 15 seconds to load a page is the result of poor code rather than 'because it's a client-side app'. Consequently you need to compare a poorly built client-side app with a poorly coded server-side app, or a poorly configured cache, for it to be a fair comparison. And, sadly for us all, there's every chance it'll be just as slow if was rendered somewhere else.
The answer to slow pages is to build them better no matter what tech is being used to drive them.
In the case of this page specifically, loading 17.3Mb of gifs is the main problem.
The main problem is that for some inexplicable reason the text of the page isn't shown until those gifs are loaded.
By default, pages on the web progressively load gifs and images. You have to put in more work just to make your user experience worse.
It's the same thing I see on some sites that use `div`s as links instead of normal `a` tags. Someone had to go to all of the trouble of adding click handlers, tab indexes, extra styling and classes, just so the page would be less semantic for screen readers.
edit: Took 93 seconds to load a couple of the gifs which seems to have blocked rendering of the entire page. <sigh>
If you're loading a single page and then unloading it that's right. If you're interacting with a page it's often a lot faster to make a small request to fetch new data and just update the part of the DOM that needs to change rather than unloading everything, fetching the new page and all the associated resources that aren't cached, parsing the new page, and repainting everything.
SSR is what the web was designed for after all.
That's plain wrong. Using a browser to launch an application was one the use cases in Tim Berners-Lee's original memo about the web in 1989 - "If one sacrifices portability, it is possible so make following a link fire up a special application, so that diagnostic programs, for example, could be linked directly into the maintenance guide." (https://www.w3.org/History/1989/proposal.html). There's no suggestion that the user would have to leave their browser when they clicked such a link.
Fast forward 10 years from Tim's proposal and Microsoft added XMLHttpRequest (via ActiveX) for fetching fragments of data to IE5 in 1999. We've had 20 years, which is 2/3 of the time the web has existed, of client-side applications. You may well have a preference for server-side rendering but you don't get to claim the web was designed for server-side as a fact. It's not true.
Second, I didn't remember that clause from TBR's memo, so thanks for the reminder.
If you downloaded a regular software and the exe file was 5MB that would be considered small nowadays, yet if a web application fetches that in JS it's considered large.
(sidenote: not defending the gifs they're just idiotic)