The "refresh causes load" issue can be solved by doing long-polling instead of short-polling.
Note that the http-equiv refresh will only trigger after the page is fully-loaded, which long-polling does not allows to happen, so you do have resilience for the case where the long-poll is interrupted mysteriously.
> The "refresh causes load" issue can be solved by doing long-polling instead of short-polling.
...and now you have to greatly scale up your backend infrastructure to be able to handle all those open connections to handle each and every single active user.
The point of the refresh (which can be activated with a meta tag) is that JavaScript is disabled in the game's server-rendered mode, so AJAX/Comet is out of the question.
>Whether websites have to work without any JavaScript at all is a question almost as old as the web itself. By now, the answer is clear: No, they don’t. It’s firmly established that websites should be more than just structured and styled text. JavaScript execution is an integral part of (almost) every browser.
The trend to CDNs serving static content means that Javascript becomes far more important than before, so "no-javascript" sites are at a huge disadvantage.
For instance, you can load up the same static page for everybody, then after it's loaded, serve some small personalized Javascript that refers to your particular user account which then customizes the page.
Maybe you can hydrate the HTML with a server side function in the same network as your CDN? Though I suppose that limits how close to the edge you can serve your cache.
> The trend to CDNs serving static content means that Javascript becomes far more important than before, so "no-javascript" sites are at a huge disadvantage.
I don't follow. How does serving static content imply a requirement for JavaScript?
If anything, serving static content through a CDN means the exact opposite: just have the site point to the resource and let the CDN how the resources are handed over to clients.
Thanks, a nice trip down the memory lane! All this stuff and more (remember server-side "sessions"?) used to be the norm :). I do genuinely believe that because the speed of light is limited and you can't put backends too close to users the only practical option to speed up the website load is active server-side loading, and the modern fully-client-side-rendered web sites would eventually be looked down upon essentially the same way we view server-only pages now
10 comments
[ 3.2 ms ] story [ 50.1 ms ] threadNote that the http-equiv refresh will only trigger after the page is fully-loaded, which long-polling does not allows to happen, so you do have resilience for the case where the long-poll is interrupted mysteriously.
...and now you have to greatly scale up your backend infrastructure to be able to handle all those open connections to handle each and every single active user.
The page this text is on, proves that isn't true!
The page does not have to do anything other than serve static content. That's hardly what most sites require nowadays.
For instance, you can load up the same static page for everybody, then after it's loaded, serve some small personalized Javascript that refers to your particular user account which then customizes the page.
I don't follow. How does serving static content imply a requirement for JavaScript?
If anything, serving static content through a CDN means the exact opposite: just have the site point to the resource and let the CDN how the resources are handed over to clients.