6 ms·
These people march into every JavaScript discussion, carrying the same cross on their back since the first day Netscape supported AJAX. They lament what a trave
by throwaway284534 5y ago
These people march into every JavaScript discussion, carrying the same cross on their back since the first day Netscape supported AJAX. They lament what a travesty the internet has become thanks to this mongrel language which broke the purity of HTML.
What really gets me is this kind of Good Samaritan plea to developers to just “do the right thing” as if every line of JavaScript was paid in orphan tears and puppy blood.
It’s 2021 and at this point it really feels like they’re begging the question: “Sites that require JavaScript are not as good as sites that don’t because they can’t operate without JavaScript.” We already know that. It’s well understood what makes a site feel slow. Progressive enhancement is an ideal situation — it’s just not something that every organization prioritizes. And for some web apps, server side rendering adds significant overhead to problems like caching, authentication, and multi platform compatibility.
If you’re honestly invested in progressive enhancement, contribute to open source tools that make it easier to ship.
- simonw 5y agoThe author of this piece has been working to help people implement progressive enhancement for nearly two decades now.
- throwaway284534 5y agoI think we can agree that the author is genuinely interested in the problem. Personally, it’s exhausting to hear what I believe are the same people ask web developers to build with competing constraints at the same time. A good website must be… - Renderable to both modern and older browsers - Designed for mobile and desktop screens - Accessible to those with disabilities - Supporting some level of offline web app use, ideally avoiding a platform specific App Store There’s all of that and more, but it’s not is impossible. In fact, requirements like accessibility are often mandated by law. But if I was building a new product, I’d honestly prefer a smaller set of JS friendly customers that I can serve a great experience to, and go from there. Progressive enhancement usually runs opposite to this issue. It’s very time consuming and adds an additional platform complexity to your existing technical product problems.
- throw0101a 5y ago> Renderable to both modern and older browsers If I disable JS and/or cookies, I should be able to read the content the web page. Just send over the HTML and CSS and let the web browser do its thing. If I get a blank page when either/both are disabled, but I do a 'view source' and get pages and pages of stuff, IMHO you're doing something wrong. It doesn't have to have all the functionality, just please have some text be thrown onto my screen.
- SquareWheel 5y agoWhat's funny to me is how many people forget that JavaScript is a web standard. By all means disable JS - it's great that the web offers this level of control. But if something goes wrong, just remember it's the client breaking the standard, not the website. Direct your blame appropriately.
- lifthrasiir 5y agoThe WHATWG HTML standard explicitly allows for disabling scripting [1]. You are not directing your blame appropriately. [1] https://html.spec.whatwg.org/multipage/webappapis.html#enabling-and-disabling-scripting https://html.spec.whatwg.org/multipage/webappapis.html#enabl...
- SquareWheel 5y agoThat does add some murkiness, but I don't take the existence of a switch to mean that websites need to accommodate both types of users. It's a technical requirement for features like <noscript> to work, so it needs to be defined in the actual standard.
- jameshart 5y agoRight - the standard provides tools you can use as a site to discover that scripting is unavailable and gracefully degrade - if you so choose. It also provides marquee and blink elements but you’re not obliged to use them.
- grayhatter 5y agoSorry, we only support users who download and autostart our spyware, I mean user experience enhancement plugin. I's not required to create a site at all, but agreed options are good. And "Because I could" is a perfectly fine reason. But the argument is "should" I require JS not "could" I.
- account42 5y agoEncrypted Media Extensions is also a web standard, yet I won't let that stop me from discouraging its use. Flash used to be a de-facto web standard. Yet sites building their navigation entirely in flash were just as shit as sites requiring JS to display some text and images.
- tofukid 5y agoI think what people lament is not JavaScript, so much as using JavaScript unnecessarily. Recreating (and usually breaking) navigation history, recreating hyperlinks, losing scroll position by interfering with it or with infinite lists, recreating forms, etc. JavaScript is overused and often at the expense of usability.
- dvfjsdhgfv 5y agoThis. There are so many pages that could display perfectly without JS, but they don't because someone messed it up. Think about it: the very existence of the Reader Mode in popular browsers shows that users no longer can read information on web pages comfortably in the browser and need another specialized layer to remove all the cruft.
- welder 5y agoThese people comment only reading the title. They lament their off-topic comment because they never actually read the article.
- dvfjsdhgfv 5y agoI'm not sure the OP can appreciate your comment though.
- jameshart 5y agoYes, absolutely. This isn’t news to businesses that have built websites that rely on JavaScript. They know not everyone has JavaScript. When movies started coming out on Blu-ray and not VHS, you could put a graphic like this out to rebut the assumption ‘everyone has Blu-ray’ - and the studios would nod and agree and say ‘yes. We know. We want everyone to buy Blu-ray players and we don’t care about serving people who only have VHS machines’ Websites know some people don’t have JS. And they want those people to use browsers with full JS support, and if they choose not to, who cares? I mean, there’s a whole stack of people who were excluded before this JavaScript flowchart even got started: do they have a computing device? Is it connected to the internet? Is it charged or plugged in to power? Have they heard of your site? Do they speak a language your site is offered in?
- 52-6F-62 5y agoI think it depends on the end service. For instance, some critical services would do best to be available without those technical constraints. So for a chat system for video games? Who cares. For my online banking when they no longer staff tellers? It should probably be more of a consideration, or at least offer a parallel, stripped-down portal. Not everyone who needs to access that kind of service has the means for a fast enough computer to run some of the websites out there.
- jameshart 5y agoBut all services can choose what they want to support. If I want to play Call of Duty I need to put the disc in an X-Box, not a DVD player. If I want to use google maps, I need to load it in a browser with JS support, not an e-reader.
- 52-6F-62 5y agoFunny enough, I think you're saying the same thing I am but looking at it from a different angle. I'm not saying JS-forward web apps shouldn't exist. I'm saying that some services should not only offer JS-forward web apps if their obligatory clientele ranges across the entire spectrum in terms of financial or technological resources and physical ability. Screen readers do not fare well on poorly structured and JS-forward web sites, for example—but the blind still need to access their online banking when their local bank branch removed their tellers and replaced them with a terminal that accesses the web portal alone...
- grayhatter 5y agoSince when is writing JavaScript easier than HTML? what amount of extra complexity and special tooling is required to make it easier to "ship" HTML? I by no means am I ann all JavaScript is bad zealot, but I do browse with it disabled by default so I don't have to trust that every single third-party developer is good enough to prevent some malicious douche nozzle from injecting some rogue script that either turns my web browser into a botnet, starts mining crypto for somebody, or exploits the newest silicone defect and is now uploading my in-memory keys to some cloud provider. and while I would agree it's unreasonable to expect complete functionality from your site with the scripting disabled, I don't think it's unreasonable to expect your page to at least partially load. I get it JavaScript developers for the most part don't give a shit about security* but some of us do and it would be nice if it wasn't a constant battle between the two of us. *to you the random JavaScript developer who actually does care you notice I didn't say all but you have to admit your colleagues are often guilty.
- Wowfunhappy 5y agoPure HTML+CSS websites are, of course, way easier to code than ones with heavy Javascript (Assuming we're talking about hand-coded websites, and absent other factors like the developer's personal familiarity.) But there's also things you can't do without Javascript. For example, if you want a fade-in animation to play when the user scrolls to a certain spot on the page, you'll probably want to calculate the user's scroll position with Javascript. If you don't address the no-JS case specifically, the element will never fade-in for users without Javascript!
- grayhatter 5y ago> had-us-in-the-first-half.gif lol, you got me in the first half there; I was already mentally constructing my reply before I eventually got the sarcasm :D Well played!
- deleted 5y ago[deleted]
- 411111111111111 5y ago
- myWindoonn 5y agoAs somebody who browses with JS disabled by default: Would you let me give you a 2KiB executable of native code? Probably not. What makes you so much more confident that if I give you 2KiB of JS, that it's not going to exploit you? We are far past the "do the right thing" plea. At this point, many major sites are simply not on my browsing menu, and I write tools to extract any data that I care about. It is now a systemic issue: How much do you trust random publishers to not attempt to compromise your Web browser?
- quickthrower2 5y agoNo. I didn’t take this site as a religious anti-Turing-tarpit sermon. Rather it is saying that not every load of your page will run the JS. 99% might but 1% won’t to make up some stats. So you need to decide how your app behaves when there is no JS. I work for a very rich desktop experience web app company where there is nothing you can do! Best things is have a nicely styled “sorry” message as a default. If you are operating a mail client, maybe you can have a seperate low fi mode. Or choose a tech that allows server side rendering, which is running that JS on the server and then losing up that page. There are trades offs for every site. From no-JS-in-the-first-place static marketing sites to web app versions of native apps with all the whistles. It comes back to technical and architectural and UX design. The post here is a reminder. Some of your client loads won’t have JS running, of that you can be sure.