>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.
You‘re absolutely right, not every web page „should“ include interactive elements.
What I wanted to express is that web pages shouldn’t be forced into being only structured styled Text and instead should be encouraged to embrace interactivity.
Most React sites do the same thing. They put text and images on a page. And most of those don't do anything you couldn't have done without JS. (And most of them find a way to do it slower, on low end devices!)
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
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 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.
You don't need JS to do long-polling, just keep the main page's connection open without writing the trailing `</html>`
This does limit what you can do with the poll-added content, but simply allowing the refresh to take place is a strict improvement over refreshing eagerly.
I haven’t tried this yet, but if it works this would be a very smart solution to the problem, as it could potentially also reduce delays between turns.
> 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.
With any decent backend implementation, idle connections should be really cheap - measured in individual pages, and the hard part is figuring out how to count the kernel side.
> With any decent backend implementation, idle connections should be really cheap (...)
Not exactly. With sync calls each server instance can handle only a few hundred connections. With async calls each instance can in theory handle tens of thousands of concurrent requests but each polling response van easily spike CPU and network loads. This means your "it works on my machine" implementation barely registers any load whereas once it enters operation your dashboards start to look very funny and unpredictable, and your scaling needs become far greater just to be able to gracefully handle those spikes. This is a radical departure from classic request-and-response patterns where load is more predictable.
With long polling you don't have the application logoc handle the waiting part — that would be too expensive. You typically have a separate service that holds the open connections until notified to then call the actual backend
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.
Currently it looks like at least Firefox and Chromium both cache stylesheets and included files as you'd expect. In fact, you can use this to increase cacheability in general. e.g. when this site is having performance issues, it often works logged out/when serving static versions of pages. It's easy to make every page static by including a `/myuser.xml` document in the xsl template and using that to get the current logged in user/preferences to put on the page. This can then be private cached and the pages themselves can be public cached. You can likewise include an `/item-details.xml?id=xxxx` that could provide data for the page to add the logged in user's comment scores, votes, etc. If the included document fails to fetch, it falls back to being empty, and you get the static page (you could detect this and show a message).
> 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.
I realized this during my exercise: I had to completely disable pre-rendering in SvelteKit for the account system to work without JS, since I want to show the username for logged in users.
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.
>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 page this text is on, proves that isn't true!
You‘re absolutely right, not every web page „should“ include interactive elements.
What I wanted to express is that web pages shouldn’t be forced into being only structured styled Text and instead should be encouraged to embrace interactivity.
> 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.
Most React sites do the same thing. They put text and images on a page. And most of those don't do anything you couldn't have done without JS. (And most of them find a way to do it slower, on low end devices!)
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
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 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.
You don't need JS to do long-polling, just keep the main page's connection open without writing the trailing `</html>`
This does limit what you can do with the poll-added content, but simply allowing the refresh to take place is a strict improvement over refreshing eagerly.
I haven’t tried this yet, but if it works this would be a very smart solution to the problem, as it could potentially also reduce delays between turns.
> 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.
With any decent backend implementation, idle connections should be really cheap - measured in individual pages, and the hard part is figuring out how to count the kernel side.
> With any decent backend implementation, idle connections should be really cheap (...)
Not exactly. With sync calls each server instance can handle only a few hundred connections. With async calls each instance can in theory handle tens of thousands of concurrent requests but each polling response van easily spike CPU and network loads. This means your "it works on my machine" implementation barely registers any load whereas once it enters operation your dashboards start to look very funny and unpredictable, and your scaling needs become far greater just to be able to gracefully handle those spikes. This is a radical departure from classic request-and-response patterns where load is more predictable.
With long polling you don't have the application logoc handle the waiting part — that would be too expensive. You typically have a separate service that holds the open connections until notified to then call the actual backend
[dead]
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.
I'm sorry to hear that. Other level no JS solution for this - without "after" - but with caching, using XSL:
https://news.ycombinator.com/item?id=41104845
Currently it looks like at least Firefox and Chromium both cache stylesheets and included files as you'd expect. In fact, you can use this to increase cacheability in general. e.g. when this site is having performance issues, it often works logged out/when serving static versions of pages. It's easy to make every page static by including a `/myuser.xml` document in the xsl template and using that to get the current logged in user/preferences to put on the page. This can then be private cached and the pages themselves can be public cached. You can likewise include an `/item-details.xml?id=xxxx` that could provide data for the page to add the logged in user's comment scores, votes, etc. If the included document fails to fetch, it falls back to being empty, and you get the static page (you could detect this and show a message).
> 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.
I realized this during my exercise: I had to completely disable pre-rendering in SvelteKit for the account system to work without JS, since I want to show the username for logged in users.
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.
[flagged]