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 really fun thing is that it requires work to break this.
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.
99% of client-side rendered pages would provide a superior user experience with server-side render. SSR is what the web was designed for after all. CSR is merely fashionable, not better.
99% of client-side rendered pages would provide a superior user experience with server-side render.
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.
Two things: Ajax is a good idea and I have no problem with it. CSR for updates is not an issue. My problem is with using it for whole pages that cannot render at all until a huge JS program has been run. When you're building a SPA, this is fine. But most web pages (like the original blog post here) shouldn't be SPAs.
Second, I didn't remember that clause from TBR's memo, so thanks for the reminder.
it's not a webpage. It's an application that happens to run on browser platform.
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)
It depends what you can do with it. Downloading a full 5MB app just to be able to scroll down and show text and a few images can be seen at big. Why not use a webpage ?
Took me some good 20 seconds. All i could see was the spinner, but the page had a long scroll, meaning that the content was there. What was it still trying to load?? And in the end it loads this fugly website full of massive pictures. Where have we gone wrong as developers?
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)?