If a website makes heavy use of a JS framework like Vue/React/Angular and does client-side rendering as opposed to server-side rendering, as an increasing number of sites do, then you run into issues. This isn't all that uncommon when checking out websites here on HN, both as submissions and within comments. I don't keep a running list of sites I'm not able to visit as that's a rather pointless list to maintain. I do encounter them frequently while browsing HN. So I did a search on HN for "blank when javascript is disabled" and you'll get a number of results. Here's the first few I came across:
You also can't sign into a Google account anymore [0]. Though to be fair if you're someone browsing with Javascript disabled you're probably not using Google and don't have a Google account to sign into.
I frequently browse only four websites. Three if you don't want to count my own. It's the sites I discover/find from these three websites where I encounter issues. HN is a frequent source of "this site has no content when JS disabled" and it's becoming increasingly more common since 2012-2013. Given how few people browse with Javascript disabled, many of these sites (rightfully IMO, even if annoyingly) file it into the "such a small amount of users it doesn't matter" cabinet.
I'm the creator of Price Hipster, which you linked to. It's not just that pretty much no one disables JavaScript. It's also that the website is very interactive and responsive and would have to be designed very differently to avoid JavaScript. Much more data would be consumed if every action resulted in a call to the server and a fully rendered page returned each time, and the website would be a lot less snappy and less nice to use.
That sounds like a great line to put in your <noscript> tag! For the three or four people who hit your site with JS disabled each decade. ;)
"Price Hipster is a modern website and requires JavaScript to be enabled."
This tells me nothing about what the site does, why the site needs Javascript enabled, or gives me any incentive to whitelist Javascript for the site since I don't know why or what it will be doing with Javascript.
Now, I happen to know what your site does because of your (previous) post here on HN. So I understand that what you are doing more or less requires Javascript and that's fine. On the plus side, at least you have a message instead of literally-a-blank-page! :)
Didn't mean to pick on you, as I mentioned in the post it was basically the first five hits on HN for "this website is blank with Javascript disabled" since I don't keep a personal list.
I apologise that he used your site as an example. Nice work, BTW.
The question we were discussing is whether a user who "just wants to read an article" needs to keep Javascript enabled for every website she visits, or whether she could keep it off by default and whitelist a smaller number of sites where she wishes to turn on Javascript for whatever reason (such as Price Hipster).
I would not question whether anyone should enable Javascript when using the web to do shopping online.
However I think "just reading an article" online is a different category of use entirely. The costs of enabling Javascript in that case may outweigh the benefits.
Your site did it right, though. It gives a message about how javascript is necessary and then, when enabled for that domain, didn't force me to enable tens of domains to make it actually work. I'm getting very weary of the "determine which minimum set of domains js must be enabled for in order to browse your site" game. So thank you for that.
If the issue is exploring new websites posted to sites like HN, then occassionally you do see these framework driven client-side rendered designs (let's call them "blank pages"). I agree it is depressing to see when people post blank pages to HN, but I think it is still a small minority.
A list of those sites is not pointless; a user could use it for whitelisting.
Even if not actively whitelisting, does it make sense for a user to enable Javascript by default for all websites just to make sure these few blank pages can run Javascript on her computer to send an HTTP GET or POST (that could easily be done without using Javascript)?
Those sites could be exceptions, not the rule; if so, they should not dictate the default setting for just reading articles. Javascript off. If we leave Javascript enabled all the time then we never learn how many articles we can just read without it.
What's more, IME sites using "blank pages" are not usually sites that serve much interesting reading material. They fall outside the category of sites where the user just wants to read an article without distraction.
I went through the examples one by one to see if I could find any articles for reading at these sites, or whether they were purely visual sites. Keeping in mind the orginal discussion is about just reading articles where no automatic video playing is necessary (and presumably no graphics either). I am not going through these to be argumentative. We are on the same side of the issue. I simply want to see what sites are leading users to believe they must keep Javascript enabled at all times (even when they would prefer to turn it off sometimes). The only way to do that is to look at actual examples.
If anyone reading has examples, please share.
1.
All of the content of isfiberreadyyet.com is on Github. It is a website for users of React, one of the frameworks that is used to make these "blank page" websites.
There are no articles to read. In any case, if a user just wants to read the raw data, with no visualisation, she can get it from Github.
2.
The site zencastr.com is a commercial site for a web app/service. The web app/service requires Javascript to run and of course the site requires Javascript to process a purchase. There are some articles to read on their blog, linked to from the main page. Reading these at blog.zencastr.com however requires no Javascript.
3.
The third site, belowthesurface.amsterdam is a heavily visual site presenting a catalog of images. There are some pages of text and some raw data in CSV. The specific page cited is a page of images. We can access the pages of text directly as json from the CDN, without Javascript. We only need to know the access token, url format and slug names. The access token, url format and slug names are not listed in the main page source but in a .js file sourced from the main page, one click away if you are using a mouse. At this time, that file is https://belowthesurface.amsterdam/static/js/main.5e68828b.js
For example, https://belowthesurface.amsterdam/en/pagina/de-opgravingen-0 could be accessed without Javascript as such: https://cdn.contentful.com/spaces/1g4p9jizfk7g/entries?acces... Accessing the CSV data file requires no Javascript.
4.
The blog at blog.stgolabs.net is a blogger site. As with the amsterdam archaeology site, we need only view the page source to get all the text on the site. If the user clicks on the link about 10 lines down from the top - https://blog.stgolabs.net/feeds/posts/default/ - she will be redirected to the full content of the blog on the feedburner site, no Javascript required. If the user wants an xml feed of the entire blog without using feedburner, she can use the BlogID number also found in the page source. The url format is https://www.blogger.com/feeds/$BlogID/posts/default
5.
The site pricehipster.com appears to be a commercial site aimed at searching for products to buy online. There is an emphasis on images and visual representation of price history. This is not a site where the user "just wants to read an article" without being bothered by an autoplay video. In any case, Javascript is apparently not required to retrieve the price data and image urls. For example, https://pricehipster.com/api/search/products/search?name=&st...
>I went through the examples one by one to see if I could find any articles for reading at these sites, or whether they were purely visual sites. Keeping in mind the orginal discussion is about just reading articles where no automatic video playing is necessary (and presumably no graphics either).
A user has no reference point to whether a site is going to be a visual-based site or a reading-based site if a blank page is served to them. On HN, I get a brief description of the site through a title and a link to the site. Here's my first opinion of each of these sites with the HN information I have to go off of (note: I often browse using /newest , so I'll ignore user comments for the most part as I'd likely try visiting the site before there are even comments on the HN post).
isfiberreadyyet.com was posted with no description and was merely a link in response to an HN post. It could have been an entire essay about whether or not fiber is ready or even a simple Yes/No page like iscaliforniaonfire.com or isitchristmas.com which is what I was expecting to see when I clicked it.
zencastr.com mentions recording so I assumed it would use the Web Audio API. I'm not given any further explanation of what the site does when I visit the web page. I'm only told to enable Javascript because I need to (and not why I need to), which isn't going to convince me to enable Javascript.
belowthesurface.amsterdam was posted on HN with the title "Below the Surface – Finds from an archaeological project in the River Amstel". That sounds like it's going to be a lot of pictures with explanations of their history from an archaeological project in the River Amstel.
>We can access the pages of text directly as json from the CDN
The epitome of user friendliness for sure. All you need to do is know that you're looking for a "cdn" link in the Javascript file you access by opening up developer tools. Even my grandmother could figure that one out!
blog.stgolabs.net was posted with the title "Linux v4.15: Performance Goodies". This sounds like it's going to be a blog about the Linux 4.15 update, specifically about performance improvements made. Again, the user friendly method of reading this information is to poke around in the source code and already have half an idea of what you should be looking for (in this case, the "meta - alternative" link). The point of working without Javascript is to be user friendly without Javascript. One way of doing that is to serve the user content, even with Javascript disabled.
In the thread pricehipster.com was posted in, jazoom at least mentions that they have been using React/Vue so I can expect the site to be broken with JS disabled. My brief description is that people quickly glance at prices (taken from: https://news.ycombinator.com/item?id=17467842 ) -- it's the worst example on the list because it's the only one that isn't misleading and is expected to be a blank page before I even click on it.
- http://isfiberreadyyet.com/ - From: https://news.ycombinator.com/item?id=14145881
- https://zencastr.com/ - From: https://news.ycombinator.com/item?id=12065622
- https://belowthesurface.amsterdam/en/vondsten - From: https://news.ycombinator.com/item?id=17439832
- https://blog.stgolabs.net/2018/03/linux-v415-performance-goo... - From: https://news.ycombinator.com/item?id=16659360
- https://pricehipster.com/ - From: https://news.ycombinator.com/item?id=17467204
You also can't sign into a Google account anymore [0]. Though to be fair if you're someone browsing with Javascript disabled you're probably not using Google and don't have a Google account to sign into.
I frequently browse only four websites. Three if you don't want to count my own. It's the sites I discover/find from these three websites where I encounter issues. HN is a frequent source of "this site has no content when JS disabled" and it's becoming increasingly more common since 2012-2013. Given how few people browse with Javascript disabled, many of these sites (rightfully IMO, even if annoyingly) file it into the "such a small amount of users it doesn't matter" cabinet.
[0] https://security.googleblog.com/2018/10/announcing-some-secu...