Hacker News Reader

Comment by gargravarr | Hacker News Reader

The biggest takeaway is that HTML was originally designed to degrade gracefully. If your browser didn't support the intended graphical layout, it would still be able to extract the hierarchy and display a usable web page, even if you were using pure text (e.g. lynx). This kept the web accessible no matter what you were using.

These days, none of that occurs. Just try switching off Javascript (I use NoScript heavily to avoid invasive ad trackers). 75% of web pages don't load at all. Others completely mangle their layouts into an unnavigable mess. Only a very small subset of pages are readable. And these are just landing pages - pages that should welcome one and all to the site. Most of the time, unless I'm looking for something specific on the site, if it loads a blank or mangled page, I just move on. If everything's a dynamically-arranged <div>, the browser has no hope of making sense of it.

You can lead a horse to water, sure...

View on HN

> The biggest takeaway is that HTML was originally designed to degrade gracefully. ... These days, none of that occurs.

This can be directly attributed to the fact that the purpose of the average webpage is no longer to convey information, but to display ads.

I frequently see people say that if a site doesn't allow people with an ad blocker to read their content, they immediately bounce off the site, and that site loses a visitor. What I don't think people get is that this is what those sites want.

They don't care about pageviews or impressions. They care about ad views. Someone with an ad blocker uses their bandwidth, but doesn't increase revenue.

To an extent, the more important conveying information is, the more likely the page is to gracefully degrade. Of course, even that is mitigated by the fact that most people throwing up a web page are either hosted by a commercial platform (Medium, et al), or at the very least using a popular framework that is designed with commercial usage in mind.

I hate to say it because I’m one of those people who bounce at a “turn off your ad blocker” notice but you’re absolutely right, and I had never considered before the fact that they don’t care that they’re losing my page view. They just want that ad impression. What a sad state we’re in right now.

I hadn't considered this angle, but it does make a lot of sense. If a bouncer wasn't going to give a site ad revenue, the site doesn't want that bouncer in the first place.

This is a horrible state to be in. I mean, I get that advertising is the only way to make regular money on the web, but dear god, we are in a sad situation where people who don't want to be blasted with advertising aren't made welcome.

I don’t think the ad part is the biggest influencer in the lack of ability for a website to degrade into a less styled form. I think the bigger factor is that people are also designing applications that run in the browser, and those make less sense to let degrade since they rely on a rich UI with lots of styling and behavior.

Web pages should be designed to load without js.

Or rather anyone starting a new project should think long and hard "is this a page or is this an app?". Too many web pages think of themselves as apps without any real reason to do so.

Developers used to building apps find it much more efficient to build that way and, to an extent, it is. I've had developers straight up refuse to build "legacy" pages, and I understand their reasoning. Sometimes that is the reason, when another is not apparent.

Web pages that don't show anything without JS are broken. Ones that show only a message about enabling JS are worse. It seems JS;DR was already a thing long before I felt the need for it yesterday, when I simply missed that article about synths at ableton.com because it was broken. https://indieweb.org/js;dr

One of those linked articles hit HN 5 years ago and almost nobody cared. I use NoScript since 2005, and I'm watching more and more things break, and it's "unpleasant"

https://news.ycombinator.com/item?id=9247871

What about web applications? I am the office champion of accessible web, but recently we made a web based game, in canvas. Without js, there's no game engine, so we had a noscript tag.

That synths article uses built in JavaScript synths (using audio apis). I agree the text should display without JavaScript but the purpose of the article (get hands on with synths) is eliminated without JS.

Basically, the web not only is a document delivery place, it's also the new Newgrounds. None of those games would work if you disabled flash, why should web applications (beyond ones that are simple documents) work without JavaScript?

> but the purpose of the article (get hands on with synths) is eliminated without JS.

If there is nothing to read, there is no way to know there is any app, let alone decide that I want it to run.

> why should web applications (beyond ones that are simple documents) work without JavaScript?

I imagine that the other kind of web app does everything with POST and forms and such like it's 2003, and I can understand that you'd prefer not to. I'm not saying they should or that they must all do without JS. I'm saying that if the article was a document that (also) documented the proper use of the web app within it then I would have liked to have been free to read it first. NoScript blocks <embed>ded things all the time and I temporarily allow them all the time. That workflow would have worked here, but if (as you seem to suggest is reasonable) the entire article was blocked because its app would be useless, then my strategy wasn't even considered, and someone is doing it wrong.

However, if a goal was to teach everyone to just run anything and everything and stop caring about privacy and security because it's a PITA, then someone is doing it right. I sure miss the good old days of Weekly_Report.doc.exe

If you like synths on the web, check this out.

https://learningsynths.ableton.com/

Cheers, but that is the exact article we're discussing lol

> > Web pages that don't show anything without JS are broken.

> What about web applications?

I would say is depends upon the application.

A data entry and simple reporting service? That should definitely be accessible and can easily be made to work without JS. Though some scripting might be acceptable: modern screen readers will cope and holding back for people with ancient screen readers is no different to holding back because some people still use IE or Android 4.4 (though do some research/testing to see what they actually w{ill|on't} commonly cope with).

If it is an interactive game or similar then you are not going to replace that practically with form submissions and no JS, so by all means don't bother caring that it doesn't work without JS. Though do make sure you include a <noscript> tag if otherwise nothing useful would display, just so users know what is going on and there isn't a fault at their end or a fault in your app that they should report.

Anything between is a grey area: you'll have to use your best judgement of your actual and potential target audiences. Though again, make sure something useful displays for everyone even if that is just a polite "sorry, we can't get this working for you" message.

This. People have forgotten why the World Wide Web was needed to begin with, and nowadays think of it merely as an integrated delivery/communication platform.

If it wasn't intended to be a communication platform, then what was it intended to be?

Web pages should be designed to be standards-compliant. While you are free to turn JS off (and that's part of what makes the web great), you shouldn't be surprised if things break. Your browser is no longer standards-compliant.

Browsers are not required to support JavaScript; in fact, HTML has a specific tag to support this case.

Yes, but the standard recommends against actually using it.

>The noscript element is a blunt instrument. Sometimes, scripts might be enabled, but for some reason the page's script might fail. For this reason, it's generally better to avoid using noscript, and to instead design the script to change the page from being a scriptless page to a scripted page on the fly, as in the next example

https://html.spec.whatwg.org/multipage/scripting.html#the-no...

I think it's important to note that a "scriptless page" does not literally mean "give me a blank white page unless I turn on JavaScript".

What do you mean when you say "should"? In an ideal world? Maybe. As it stands though, there is basically zero incentive to do so and quite a few incentives not to. Analytics, ads, referral networks etc. All of these require JS (at least the most popular solutions of the day) and if non of this works, what exactly is the reason to show you the page?

> What do you mean when you say "should"?

Probably "according to the original designers' intent," see this comment below you: https://news.ycombinator.com/item?id=20284550

You could turn it around to say that screen readers should support javascript. Some already do. They can execute the scripts and _then_ read the resulting DOM tree.

I feel like I'm going to be in a huge minority here but I am one of those developers that builds websites that won't load without js. Hear me out though.

I primarily work with ecom, and we build highly dynamic sites in an increasingly rapid arms race for engaging design.

Before vue I worked with jQuery like everyone else, controlling the dom manually to react to changes in application state. Those were dark days.

Now I can manage the cart state and increasingly everything else over apis and have the application display all these updates in real time, along with all the whizz bang the design team decides is flavour of the week. All in not much more time than jQuery and basic layouts previously took.

So, sorry if my site doesn't load without JS, but it's not about the ads. The web isn't just document display anymore, everything is an app.

Also before someone mentions it, I am using SSR where possible so at least something displays, it doesn't make one of these websites function well without js though.

I am not protesting the idea that a site should work without JS - quite the opposite, I accept that active content and user interaction requires JS (as much as I loathe the language).

What I am protesting, however, is that graceful degredation doesn't happen. The entire site either breaks or blocks you from viewing static content unless you enable JS. Why am I prevented from viewing a product's information page before I decide whether or not I want to add it to the cart? Why does a news article render as 3 columns of disjointed text that are unreadable until they're assembled? Why don't images load at all unless I permit a CDN to shove a load of JS into my browser for fancy slideshows, zooming, whatever, rather than just placing a small static image there so I can decide if I want to zoom into the dynamic larger image?

The worst ones are those that pop up a banner or overlay that darkens the page with the loaded article until I enable JS. Like, you have literally proved your page works without JS. There is literally no reason for me to enable it, except for you to load several different analytics modules that chew up my CPU and siphon as much identifiable data as they can get their hands on.

The dynamic dom frameworks (and webpacks) have a tendency to encourage moving everything into javascript. Generally this means that enabling gradual degredation requires building most things twice, once in static form and again for when vue et al have been loaded. Separating the two takes significant time and effort, which also introduces extra surface area for bugs and odd interactions. It is expensive to build this way, and there are other things worth prioritising.

Ultimately all website are optimised for their target audience, if 30% of our users used IE6 then we would (sadly) target that. If users value ease of use on a baseline browser then that is prioritised, and if static information and nojs turned out to be what most users valued highly then we would do that too.

You would think that SSR could take care of the problem and not require one to build twice. Most of these frameworks are very opinionated, if they cared about doing the right thing I don't think it would be hard to extend their opinions to make it so that content is tagged in ways that allow the framework to automatically generate the multiple views needed for graceful degradation.

> an increasingly rapid arms race for engaging design

For us, the arms race is that other one about getting code to execute on people's machines, including the virtual ones, versus preventing that. The mere existence of good code that is worth running makes it a hard problem. More of that just makes it more pressing even if not actually harder.

> Ultimately all website are optimised for their target audience

Ultimately all audiences are being optimized for the ideal website which shares its ideal viewing conditions with websites that are being used against the users (i.e. code runs even though we don't know or explicitly trust the authors or their employers or really anyone around it).

This. on the side,

> banner or overlay that darkens the page

Sometimes with ABP or UBO you can right-click and blow out that <div> which their JS would have cheerfully made invisible. Also, sometimes FF's "reader view" blanks everything but the meat of the article even if the article was hidden. (you probably know that-- for future reference and any passers-by, until the world breaks it all again. vive la révolution)

I'm savvy enough with the dev tools and CSS to set `style="visibility: hidden"` on most overlays, but yeah, I can imagine that trick isn't going to work forever either.

> So, sorry if my site doesn't load without JS, but it's not about the ads. The web isn't just document display anymore, everything is an app.

Hands down, this was the comment I was looking for to agree with.

There is a big difference between 100% JavaScript everywhere and having Vue component to manage cart state though.

A large majority of whizz bang the design team decides, can be done just with HTML 5 and CSS 3.

Where it can be done with H5 and CSS3 we use those things, we don't invite complexity for the sake of it, but it's really very easy to run into the limitations of CSS3 when doing something even slightly unusual.

Vue replaces the dom of wherever the app is, so the choice is between having everything within a single app div or having a ton of apps talking to each other. Given that the ton of apps solution still breaks fairly essential functionality (for online shopping) and requires a fair amount more structure it's a bit hard to see the benefits.

This graceful degradation doesn’t make sense in the application world. I know that’s not what the web was initially designed for, but this is what the web has evolved into. It’s now an application platform just as much as a document platform.

Reply on news.ycombinator.com