Static pages are the fastest there are. So if static pages are slow, CSR pages will suffer from the same consequences usually in an exacerbated fashion.
Everything else being equal an SSG blog (which could use something like netlify CMS) will always beat a (non-cached) WordPress based blog which has to access the database and generate the rendered page on every request. It's the same difference between a compiled language and an interpreted language - a compiler can do a lot of work ahead of time.
So, which one is faster?
Unless you control the client device it's unlikely that it's the CSR version.
On the server (which in theory you control) you can
use more powerful hardware
use a faster language/framework
and then use compression which will generate a minuscule payload
or start streaming/flushing the response early so that the browser will fill the view port with the first batch while the rest is still streaming.
Meanwhile you have no idea what level of computing power the client device has:
You are essentially blocking the UI thread from being able to do anything until you rendered all 10^6 nodes (and realistically you should be building the subtree separately before attaching it to document).
Aside: The RAIL model budgets 50ms of processing for any one input event irrespective of the computing power of the client device.
The page renders all content dynamically without any html.
The discussion isn't whether it's possible but whether it's desirable.
and took me only some hours to set up.
So it's desirable from the developer perspective - no argument there.
The JavaScript first/only mentality reminds me of The Free Lunch is Over—C++ developers stuck in the forgiving mental model of a single thread, unwilling to break the work into isolated but communicating, concurrent tasks. The web equivalent is to load all the work onto the UI thread (i.e. JS) while not delegating work that can be done by the HTML parser or layout engine (which run as native code rather than as JavaScript).
The full page load takes about 0.6s
WebPageTest puts it about 4.6 seconds for "Mobile, Fast 3G"
Just in the Chromium emulator: low 3G + low end mobile + no caching ~ 17s.
Performance breakdown:
but at least I could read what was already loaded while it was still loading (for 3.2 minutes).
It's clear you don't feel like you are trying to sit comfortably while balancing on a three legged stool with two legs sawed off …
But even all the popular JS frameworks, no matter how lightweight, had to concede that "client-side only rendering" isn't enough and eventually added SSR, further complicating applications. To my knowledge Marko is the only one that operates server-first using JavaScript to build on the server rendered HTML.
"Client side only rendering" is an idea that had its heyday some years back (AngularJS (2009), React (2013)) when the web was still primarily consumed through desktop browsers - where it worked "well enough" for a time.
The "optimized for mobile" HTML-first / just-in-time JavaScript approach is currently being used by Qwik.
Qwik is interesting not because it's new and shiny but because it seems to make an effort to respect the constraints of the (mobile) web.
It uses an entirely different architecture compared to any of today's popular JS frameworks.
It is squarely aimed at highly interactive eCommerce sites, not "web applications in general", to create something that works "well enough" to displace the need for device specific native (eCommerce) applications.
Strictly speaking Qwik does not concern itself with the "client-side application" as a whole but only the UI and its visual components. It's entirely possible that they want to leave the option open of putting the "non-visual client side application" in a web worker instead.
So, for every DOM element I get two Identifiers in my program: The ID and a variable. This doubles my effort compared to creating the elements from within JS.
It's unclear whether Qwik (or something like it) will be the "next big thing" but its approach seems to be a good fit for a certain category of next generation mobile web applications.
I feel this discussion is going a bit beyond the scope and it is not very polite to take over a post. So, maybe we should start a new thread about the future of webdesign somewhere else.
This post was about the advantages (or possibly disadvantages) of Javascript, not about slow networks. IF "JavaScript has become the largest bottleneck of web performance", this was real serious. It is just not what I currently can see.
Let be serious about JS performance. I had real concerns about that, and if the performance was just that bad, I never hat thought one second about using JS to build applications.
WebPageTest puts it about 4.6 seconds for "Mobile, Fast 3G"
Maybe you have heard that 3G was switched off (at least in germany)? We are also not supporting windows XP anymore, but who cares? I checked the page on the oldest devices I could get, a 10 year old mobile phone, my oldest tablet and others, but none of the devices was nearly as slow as mentioned. Indeed, the bottleneck is 3G, not the JS performance. But with a slow web, any interaction will be slow, regardless of the technology.
YES, we should care for poor performance. And YES, maybe QWIK is the next big thing in webdesign. But todays mobile devices are far from being slow, my daughters smartphone has more memory than my laptop. Why should we not make use of this power? You can do more with a browser than looking on websites.
(again: Please stay on topic. I really like to learn about new trends in web design and performance, but maybe we start a new post on that? Thank you very much!)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Static pages are the fastest there are. So if static pages are slow, CSR pages will suffer from the same consequences usually in an exacerbated fashion.
Everything else being equal an SSG blog (which could use something like netlify CMS) will always beat a (non-cached) WordPress based blog which has to access the database and generate the rendered page on every request. It's the same difference between a compiled language and an interpreted language - a compiler can do a lot of work ahead of time.
Unless you control the client device it's unlikely that it's the CSR version.
On the server (which in theory you control) you can
Meanwhile you have no idea what level of computing power the client device has:
document).The discussion isn't whether it's possible but whether it's desirable.
So it's desirable from the developer perspective - no argument there.
The JavaScript first/only mentality reminds me of The Free Lunch is Over—C++ developers stuck in the forgiving mental model of a single thread, unwilling to break the work into isolated but communicating, concurrent tasks. The web equivalent is to load all the work onto the UI thread (i.e. JS) while not delegating work that can be done by the HTML parser or layout engine (which run as native code rather than as JavaScript).
WebPageTest puts it about 4.6 seconds for "Mobile, Fast 3G"
Just in the Chromium emulator: low 3G + low end mobile + no caching ~ 17s.
Performance breakdown:
for a page that has largely static content.
Now lets not kid ourselves, for the 1.8MB one page HTML spec
but at least I could read what was already loaded while it was still loading (for 3.2 minutes).
It's clear you don't feel like you are trying to sit comfortably while balancing on a three legged stool with two legs sawed off …
But even all the popular JS frameworks, no matter how lightweight, had to concede that "client-side only rendering" isn't enough and eventually added SSR, further complicating applications. To my knowledge Marko is the only one that operates server-first using JavaScript to build on the server rendered HTML.
Reference to any reader:
Yes, i know, bumblebees cannot fly...
🤔
As somebody already pointed out that's a bit out of date.
"Client side only rendering" is an idea that had its heyday some years back (AngularJS (2009), React (2013)) when the web was still primarily consumed through desktop browsers - where it worked "well enough" for a time.
The "optimized for mobile" HTML-first / just-in-time JavaScript approach is currently being used by Qwik.
Qwik is interesting not because it's new and shiny but because it seems to make an effort to respect the constraints of the (mobile) web.
Qwik Todo Demo on StackBlitz
That's why Qwik will do that work for you.
It's unclear whether Qwik (or something like it) will be the "next big thing" but its approach seems to be a good fit for a certain category of next generation mobile web applications.
I feel this discussion is going a bit beyond the scope and it is not very polite to take over a post. So, maybe we should start a new thread about the future of webdesign somewhere else.
This post was about the advantages (or possibly disadvantages) of Javascript, not about slow networks. IF "JavaScript has become the largest bottleneck of web performance", this was real serious. It is just not what I currently can see.
Let be serious about JS performance. I had real concerns about that, and if the performance was just that bad, I never hat thought one second about using JS to build applications.
Maybe you have heard that 3G was switched off (at least in germany)? We are also not supporting windows XP anymore, but who cares? I checked the page on the oldest devices I could get, a 10 year old mobile phone, my oldest tablet and others, but none of the devices was nearly as slow as mentioned. Indeed, the bottleneck is 3G, not the JS performance. But with a slow web, any interaction will be slow, regardless of the technology.
YES, we should care for poor performance. And YES, maybe QWIK is the next big thing in webdesign. But todays mobile devices are far from being slow, my daughters smartphone has more memory than my laptop. Why should we not make use of this power? You can do more with a browser than looking on websites.
(again: Please stay on topic. I really like to learn about new trends in web design and performance, but maybe we start a new post on that? Thank you very much!)