3 ms·
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 ge
by sirwhinesalot 3y ago
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.
- joshstrange 3y agoFair, 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.
- sirwhinesalot 3y agoI 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.
- superkuh 3y ago>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.