Comment by joshstrange | Hacker News Reader

Comment by joshstrange | Hacker News Reader

> If the user’s browser fails to download, parse, and run any JavaScript, nothing will display on screen.

> So before any JavaScript has been downloaded, parsed, and run, a desktop browser could display something like

If? Before? I’m sorry but that’s just not based in reality at all.

These examples are so hopelessly contrived. Their fallbacks are rough and often ugly, require a ton more testing and development, and are not what users want. If your JS is slow to load or often fails loading then that’s what you should focus on. Not some half-working BS.

Web _apps_ require JS. Pure and simple. Pretending that it’s worth the time to implement a fraction of your web app’s functionality for the case where JS doesn’t load is ludicrous. “Oh look you can use a title instead of a tooltip”, cool, now make some actually complicated work.

If I had unlimited budget and unlimited QA time I still would think this was a stupid idea. Dealing with all these “graceful” (press X to doubt) fallbacks means double the QA time: once to test the happy path that users demand and once to test the absurd path that <1% of your uses will see or want. Anti-JS/noscript people don’t make any sense to me. Might as well reject CSS or h1 tags while you are arbitrarily drawing the line somewhere.

Yes I know HN has a higher proportion of these people than the internet at large but it’s simply not worth the extra effort and testing. It’s like installing peddles in a car in case the engine goes out.

I still regularly see spinning dots of death or broken pseudo-progress-bars on top of pages that are little more than blogs and could very well be statically generated.

Don't get me started on broken browser history, even youtube fails at that.

Web _apps_ require JS, no doubt about it, the problem is that every website these days thinks it's a web app.

Fair, and in other comments on this subject I’ve complained that we don’t have good “language” for discussing things like blogs vs marketing sites vs JS-heavy sites vs actual web apps. More often than not people are taking past each other in the pro/anti-JS context with each person thinking of a different example.

I completely agree that your blog probably doesn’t need to require JS and might even be worth some of these fallbacks if you do want to enhance it but a blog is tiny testing space compared to any “web app”. Also even if your user-facing aspect of the blog can handle noscript your backend admin/editor is going to require JS in most cases.

Yes, yes, static site generators are great but let’s not kid ourselves and pretend they are suitable for most people. Hell, I used SSG for years before deciding I just wanted a web admin UI to edit/write in for my blog. And you can even pair the two together (JS-based admin that generates static frontend files for readers).

Bottom line if any part of your website/app requires JS then it’s a waste of time to try implement fallbacks. At a previous company I dealt with this, the core of our business was a website that needed JS to function but I had one dev who constantly wanted to have fallbacks on our less JS-heavy pages. A user using noscript would not be able to do the most important things since there was literally no conceivable way to have a noscript fallback (show me the fallback for drawing polygons on a map without JS, I’ll eat my hat). Being able to create calendar items in our system might be possible without JS (with a terrible UX) but good luck with the UI to assign people to the calendar entry. It just wasn’t worth the effort and QA time to support both.

I agree with you, JS is a part of the web and disabling it entirely is silly. My issue is solely with the modern approach of making the web nothing but JS. I blame the W3C in part for moving in that direction (and, in turn, google, for pushing it in the first place).

I've been on poor internet connections where being able to get half broken HTML with barely any CSS loaded was a godsend. Progressive enhancement was a good idea. Nowadays if some little bit of JS doesn't load right the whole website goes down. That's a shame.

>Bottom line if any part of your website/app requires JS then it’s a waste of time to try implement fallbacks. At a previous company I dealt with this, the core of our business

It certainly is a waste of time for incorporated legal persons who pay human persons to implement things to generate profit. But for human persons making websites for other human people just because they want to it isn't.

> and are not what users want

Ohoho.

I, as a user, want to see the content. The amount of times when the content is not available because for whatever reason JS/CDN/whatever didn't work is uncountable.

Hell, sometimes I get a blank page for the login page, which could be replaced with a three lines of HTLM form, but now it requires a ten web requests, wait for them to load and only then it renders something.

It's even more amusing if you look at Network tab of Devel Tools.

> but it’s simply not worth the extra effort and testing

Maybe you shouldn't made a simple page require tons of JS and CSS to show the content in the first place?

Maybe not everything should be a web _app_?

And this gets back to point I’ve made here and elsewhere about talking past each other. Not everything has to be a web app but some things do and those things need (require) JS, end of story. Yes a blog frontend doesn’t need JS but we are talking about different things here I think.

the problem is that react is being used outside of SPAs, for any sort of interactivity, because it is easy to hire for at this point and because there are a lot of existing components to choose from. so yeah, progressive enhancement doesn't work if the actual component is state-heavy, or the entire site is state-heavy. When React came out, its tutorial was very centered around being embeddable on existing web pages, and it was framed as more of a "jQuery replacement". IIRC the term SPA didn't even exist yet. The other commenter already pointed out what the end result is.

if you don't do it for accessibility, do it for SEO. yeah a lot of commenters here already pointed out that SSR is a thing now, but the concerns you had still apply then. There's two paths to test now, one with JS and one without. This kind of always was the case though.

Reply on news.ycombinator.com