Whole different story but do we really have to insist on not delivering any first party frontend logic in 2024? It's minimal and most code is on the server. Also it's a small footprint and proven to be fast (Preact). This site has a 100 performance score on Google Pagespeed, JS doesn't mean bad UX.
Blocking third party scripts and cookies is one thing, but not wanting first party script just forces the developer to use server-side templating for their static content which means you either deliver everything from the same origin (bad for latency) or chain a CDN in front that picks out static content to cache (I don't think that's compatible with the web 2.0 ideology). So it's not ideal too
It's a super weird phenomenon. These people (who are mostly not web developers) have enough of a technical understanding of how websites work to disable a huge part of the browser, that they think shouldn't be needed, and then complain about websites not working.
From a web developer's perspective, it doesn't make any sense to me because JS is just one part of the web standard. If you're not going to support it, then why do you expect any websites to work?
It's like if I deleted gcc from a linux machine and then tried to build a package, and then complained that it wasn't building, because "it shouldn't use C." Well, C is an expected part of the operating system and so the package author has decided to use it. You've broken your system.
There is no good reason that this kind of content would need any client-side logic. Not being able to view it with tools like w3m is an unnecessary limitation.
It’s also ironic that the one thing HTML was designed for, namely presenting static content, is now deemed unworkable without having to run custom client-side code.
TL;DR: on that site, 77% of first-party bandwidth is Javascript. Serving HTML instead of Json would cut the bandwidth by 4.4.
> It's minimal and most code is on the server. Also it's a small footprint and proven to be fast (Preact). This site has a 100 performance score on Google Pagespeed,
Yes, it's nicely minimal in a number of aspects. Good point.
> JS doesn't mean bad UX.
For those who run their browser with scripts off by default it is.
Disabling JS and cookies by default has another nice benefit: on a number of sites, the stupid content-obcsuring cookie banner just does not exist (as well as ads, of course). And pages load time is much better.
> Blocking third party scripts and cookies is one thing, but not wanting first party script just forces the developer to use server-side templating for their static content which means you either deliver everything from the same origin (bad for latency) or chain a CDN in front that picks out static content to cache (I don't think that's compatible with the web 2.0 ideology).
That doesn't hold.
If a server can format data into a Json, it can format the same data into HTML and serve it the same. In the specific case of this site, the generated HTML has the same lifetime as the generated Json.
From the site: "It is updated every 2 hours."
Ironically, because this site is nicely minimal in a number of aspects, one can play with statistics. Not counting cloudflare beacon js, I measure
By serving HTML instead of Json (at the same price), the bandwidth cost would be divised by 4.4:
p=(1.16+1.56+1.05+1.61) ; j=18.44 ; (j+p)/p = 4.4
Think about it: running custom code on each browser of each visitor to perform exactly the same computation and yield the same DOM each and every time is totally useless.
All in all, serving a full HTML page instead of a HTML shell + custom JS + Json totally makes sense.
The good news is, for the past year I have started to hear seasoned web developers complain more about the sad state web development has been for years, and longing for some simplicity. Wait and see.
Kudos to the author for embracing minimalism. You can go a step further.
7moritz7|2 years ago
Blocking third party scripts and cookies is one thing, but not wanting first party script just forces the developer to use server-side templating for their static content which means you either deliver everything from the same origin (bad for latency) or chain a CDN in front that picks out static content to cache (I don't think that's compatible with the web 2.0 ideology). So it's not ideal too
MatthiasPortzel|2 years ago
From a web developer's perspective, it doesn't make any sense to me because JS is just one part of the web standard. If you're not going to support it, then why do you expect any websites to work?
It's like if I deleted gcc from a linux machine and then tried to build a package, and then complained that it wasn't building, because "it shouldn't use C." Well, C is an expected part of the operating system and so the package author has decided to use it. You've broken your system.
layer8|2 years ago
It’s also ironic that the one thing HTML was designed for, namely presenting static content, is now deemed unworkable without having to run custom client-side code.
david_draco|2 years ago
Yes. Not all users may be able-bodied, or humans.
uKVZe85V|2 years ago
> It's minimal and most code is on the server. Also it's a small footprint and proven to be fast (Preact). This site has a 100 performance score on Google Pagespeed,
Yes, it's nicely minimal in a number of aspects. Good point.
> JS doesn't mean bad UX.
For those who run their browser with scripts off by default it is.
Disabling JS and cookies by default has another nice benefit: on a number of sites, the stupid content-obcsuring cookie banner just does not exist (as well as ads, of course). And pages load time is much better.
> Blocking third party scripts and cookies is one thing, but not wanting first party script just forces the developer to use server-side templating for their static content which means you either deliver everything from the same origin (bad for latency) or chain a CDN in front that picks out static content to cache (I don't think that's compatible with the web 2.0 ideology).
That doesn't hold.
If a server can format data into a Json, it can format the same data into HTML and serve it the same. In the specific case of this site, the generated HTML has the same lifetime as the generated Json.
From the site: "It is updated every 2 hours."
Ironically, because this site is nicely minimal in a number of aspects, one can play with statistics. Not counting cloudflare beacon js, I measure
1.16k HTML, 1.56k CSS, 18.44k JS, 1.05k favicon.svg, 1.61k JSON payload.
Therefore 77% of bandwidth used is Javascript:
By serving HTML instead of Json (at the same price), the bandwidth cost would be divised by 4.4: Think about it: running custom code on each browser of each visitor to perform exactly the same computation and yield the same DOM each and every time is totally useless.All in all, serving a full HTML page instead of a HTML shell + custom JS + Json totally makes sense.
The good news is, for the past year I have started to hear seasoned web developers complain more about the sad state web development has been for years, and longing for some simplicity. Wait and see.
Kudos to the author for embracing minimalism. You can go a step further.