Been there, done that. Then dropped dark mode entirely. Strong filtering of blue light (use redshift or whatever your OS provides) beats dark theme IMHO, without the downsides.
I default to light mode these days. Astigmatism does not goes well with small, bright details against a dark background. Then I can turn the brightness of the display way down.
Probably a "compatible" card that would behave like the standard of the era only after being setup by a DOS driver. Linux, like DOS programs, would find it only after such a setup. Perhaps even the card setup would not survive a reboot.
> Then I personally don’t care about needing JS to view the site (it’s 2024…)
In 2024, shouldn't hacker news visitors get that receiving a passive document to display locally is a thing, and having to run unaudited code from random strangers on your machine all the time is quite another? Then reopen the conversation about browser security?
Or, instead, get that simplicity is our ally, but unneeded complexity is the root of much evil?
Visit e.g. any stackexchange site with script disabled and be enlightened.
Not even certain this will be enough. Hawking radiation encodes the information that was thrown in. Sure at present it's a perfect mess, but who knows?
Not really aligned, but somehow reminiscent of this other dystopian future of what happens when a platform makes money not on products but on ads https://www.smbc-comics.com/comic/2012-01-12
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.
> There is no good reason that this kind of content would need any client-side logic.
One such reason might be that it allows the developer to host their frontend statically, which usually is much simpler to set up and operate.
I would find it fair to appreciate that the author provides their service for free to the world. So while it might be true that their website isn’t fully compatible with certain client-side tools, that kind of support doesn’t come for free, and it also may not align with the goals of the author. (Which in this case apparently are educational ones, and not to maximise accessibility for a broadest-possible audience.)
If the commenter had said, "I can't view this with w3m," I'd understand that more. What's frustrating is that most of these comments are from people using an extension like NoScript or who have disabled JavaScript in their browser settings, based on (misguided IMO) privacy or security fears.
There's nothing wrong with tampering with your browser by disabling JavaScript, but you have to understand that what you're doing is unsupported by websites. It's unreasonable to complain that the website is broken when you disabled the technologies that the web developer chose to use.
> 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.
Because the content here is dynamic. It changes every 30 minutes, even if it's just the scores. HTML was not designed to serve dynamic content.
That’s not dynamic content. It’s okay to have some optional JavaScript to dynamically update the scores or whatever. But that’s no reason not to show the main/initial content without JavaScript. As a user I certainly prefer regular content to not update by itself, though.
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.
