The page this text is on, proves that isn't true!
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 does not have to do anything other than serve static content. That's hardly what most sites require nowadays.
Citation needed.
> And most of those don't do anything you couldn't have done without JS.
Please explain how you plan to develop a webpage that fetches data from an API without using JavaScript. Explain what alternative you think there is, what resources you need to develop them, and enumerate your tradeoffs.
After you do that exercise, you will be aware of why the world gravitated towards SPA-like, client-side WebApps.
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.
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).
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.
o11c•5mo ago
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.
YannickR•5mo ago
motorest•5mo ago
...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.
o11c•5mo ago
motorest•5mo ago
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.
nasretdinov•5mo ago
glroyal•5mo ago
o11c•5mo ago
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.