Everyone Has JavaScript, Right?
kryogenix.org
kryogenix.org
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.
- 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.
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.
[1] https://html.spec.whatwg.org/multipage/webappapis.html#enabl...
It also provides marquee and blink elements but you’re not obliged to use them.
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.
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.
JavaScript is overused and often at the expense of usability.
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.
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?
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.
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...
Remember that what blind users use to interact with plain web navigation is called 'assistive technology' - it adds more interaction options onto plain web pages. You couldn't build such a thing with just HTML.
In general, JavaScript offers the opportunity for web-delivered experiences to be improved - for all their users.
Browsing with Javascript disabled means you are not going to get to enjoy those benefits. And I don't think that businesses should all feel obliged to try to provide a completely equal experience for someone who chooses to browse with such a restriction.
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.
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!
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!
Yeah, I'm aware of these cases. I'm not demanding your web3.0 real time interactive multiplayer pokemon clone work without JS. But it would be nice if the text and images on your root index page would load without JS, so that I could decide if I want to run your arbitrary code on my computer without feeling like I'm rolling the dice.
> Because a non JavaScript version of lots of applications means a dynamic server generating HTML.
You haven't heard of page pre-generation have you? You could use JS to generate all the basic html you need, save that, and serve it somewhere from some basic HTTP server. Then the site would still do something without JS.
> I would argue that building secure, user oriented data-backed applications out of JS clients with backend microservices in the JAMStack style is actually easier than doing it in classic serverside scripting LAMP stack or Ruby on Rails style.
I would argue the exact opposite, but this absolutely comes down to familiarity. I've written more python and html than I have JS. But what's easier still is writing a basic blog with the exclusive intent to deliver information, rather than increase growth, retention, conversion, or whatever metrics sales/growth is asking for today.
You’re right that SSR/pregeneration approaches are a reasonable modern approach to building a simple blog, but still comments are an annoying obstacle to a simple pregenerated page model.
And I’ve got to say: it for sure gets a lot more complex when what you’re building isn’t a blog but a blogging platform.
I’m absolutely not arguing that such a system shouldn’t serve up relatively simple prerendered HTML for article pages by the way - I mean, basic SEO kind of pushes you to do that - but that the rest of the stuff on that blog - the tag clouds and the comments and so on - are actually easier to add through clientside JavaScript integration of simple backend services, than through adding complexity to your serverside HTML generation model.
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?
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.
https://technology.blog.gov.uk/2016/09/19/why-we-use-progres...
And the original research is available at
https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missi...
I've also used the Raspberry Pi as a computer in the past and used Dillo (or similar browser) as it was lightweight.
We fixed the problem by switching to HTTPS.
Worrying about somebody using „Chrome data saver mode“ before your startup gets 100k hits per month means to me that your focus is completely off.
Instead, perhaps improve your core product and talk to actual users today?
See where the problem is?
No, I don't. In part because I don't tick boxes, I just (try to) build good shit. Also because I don't expect every UX "best practice" from [random internet authority] from a site with JS disabled. I just expect the text on the site to render somewhere readable.
Usually, the argument from the "js is bad" crowd, isn't that the site should be as functional with JS disabled... only... that the basic content... should still render...
If my current frontend framework of choice happens to not render any HTML without JS, I am sorry, my site will be inaccessible to you.
Because that frontend framework allows me to iterate much faster and improve my product for the vast majority of users.
It’s never been worth worrying about non JavaScript clients (except search engines)
That's probably the difference in experience then. I've been a software engineer for almost as long, but I'd never consider describing my work as just "web tech", and the engineers are all willing to make a reasonable minimum effort to at least render "something" without JS. The difference is probably between web developers, and software engineers generally.
My javascript user metric collecting service says all my users have JS...
Imagine that :P
> any rational business will refuse to invest resources to serve your unique needs.
I'm not convinced that's rational, but all the same. Any rational engineer would rather do the job correctly, rather than what's easy. Which is what the argument comes down to. One the minimum always works, the other way is easier (for you).
> If my current frontend framework of choice happens to not render any HTML without JS, I am sorry, my site will be inaccessible to you.
Don't be sorry in this case, if this is the tradeoff you've decided to make. That's totally fine. It's your project, and your code. You absolutely should make the decisions you think are best. I'm just some random idiot on the internet who thinks your decisions are bad, and your framework is a dumpster fire waiting to implode. I like to write code that works, and I think code that works in every case is objectively better than code that works in most cases, and is easier to write. But I suspect the code we write and projects we care about are very different.
The difference seems to be that I care more about the code than I do about the cash. You frame all decisions from the context of a business trying to make money. You're right when you say:
> Because that frontend framework allows me to iterate much faster and improve my product for the vast majority of users.
That is probably the best way to make the most money with the smallest expense. But I have a different set of standards for the work I do. And just to be clear, please note I didn't say my standards for my work are better than yours, only that they're different.
But your code does not work in every case:
Image a user that would like to access your website using an even older setup than simply no JS, let's say he's using lynx on a 50 by 20 character ssh session on an old Android phone with a broken keyboard.
Your website will look like shit, it will be absolutely unusable and the user will have a mental breakdown.
If you counter that your website is only one line of text that says "Hello world!", and that would work on my imaginary lynx setup, let me counter as well:
I am now a user that has no computer at all. I would like to access your content by calling. Where is the phone number I can call to talk to a human in my language, at 03:30am in the morning?
Remember, not everyone is using the latest technology! A company should be accessible even if the user doesn't have WASM/React/JS/CSS/HTML/HTTP/TCP/a computer/a Chomsky universal-grammar based spoken language/...
I think we all have edge cases we simply cannot serve. I agree that there might be different thresholds, though. :-)
I had enabled 'Do Not Track' in the browser, which broke the widget.
I'm sure the 3rd party provider regrets listening to the privacy nerd who insisted on supporting this header.
"Everyone has JavaScript, right?"
After reading the page...
...basically, yeah.
It's browser plugins right now -- the main snoopers.
Until you’re in 6-digit MRR territory, this shouldn’t even cross your mind when building a Web app. There are way more important things you should be doing to your product/business.
Does anyone know what that means for e.g. flaky mobile browsers?
EDIT: Actually the data saver thing is called "noscript" so you'd hope it'd activate the tags. Network failures though will trigger onerror and leave the rest up to you
Currently, I'm checking out Cloudflare Workers.
They're compatible with service workers, so they might be a viable fallback solution for people without JS.
Web scraping may not be your value proposition (or you may not think it is), but it could very well be your users'.
And yes, I'm that small but vocal minority that makes use of console browsers, wget and curl, and heavily disables JS in my graphical browsers for numerous reasons. Gratuitous breakage is utterly unnecessary, and that's the point. Not that you cannot use JS, but that functionality which is independent of JS should be supported, when JS is disabled.
Everything else misses the damned point.
> Meeting our many users’ needs is number one on our list of design principles.
What?
Interactive applications came way before the Web and JavaScript.
Interactive applications currently exist outside of the Web and these same applications may not have been built using JavaScript.
- May still want to see the noninteractive element of that application. We call those "documents".
- May selectively choose to enable JS in specific cases where utility outweighs other factors. But JS dependence impedes on that case.
Their strength is in selective and goal-oriented blocking, in a way that doesn't break nearly every website by default.
For example, cnn.com shows no content with javascript disabled. By itself html is perfectly capable of displaying text and graphics, that's what it is designed for. Taking a quick look it appears that about half of the scripts loaded on their front page are for ad-tracking. A gizmodo page I'm looking at now wants to load 37 scripts for some reason. ublock is showing me 14 ad-tracking items.
I'd rather avoid such sites. So I go somewhere else if they don't work with javascript disabled. I can make per-site exceptions, but I'd rather not.
(In the above examples, I use lite.cnn.com to consume news articles news MUCH more quickly, and gizmodo with javascript disabled still showed me the text of the article I was interested in, so I'm happy.)
Yes I'm that much of an asshole.
Does your site mostly work without JS untill I want to do/use 'other thing'? Then I'll normally just white list the whole site because I know that you've at least considered what needs to be and what doesn't need to be included.
but more often than not I have to scroll past more than a few untrustworthy data mining domains just to find the CDN that's distributing your magic JavaScript. Those are the ones that piss me off.
- drag drop reorder and move?
- accessibility?
- draw on top of webpage?
- popup menus?
- show/hide sidebar?
Any links for examples?
Accessibility is possible with standard semantic HTML and aria tags (again to a certain extent)
D&D is probably not workable though
2. Use ARIA
3. Use position: absolute?
4. Create it with position: absolute/relative and use CSS :hover selector to show it (or see #5 for explicit open/close)
5. Use <details> or a checkbox along with the appropriate CSS
HTML is pretty accessible by itself, simply follow the standard and WAI-ARIA.
>popup menus?
https://www.w3schools.com/howto/howto_css_dropdown.asp
>show/hide sidebar?
You can use the checkbox way to handle that: https://codepen.io/Sfate/pen/nLBGr
The rest isn't really possible without JS as far as I know.
[1] please note the content on the page is outdated, this is just a prototype -- the drop-down below "PayPal": https://sdproto.gitlab.io/donate/
(Although, you could argue the end-result for users who need accessibility features is the same, regardless of who is at fault.)
Then the JavaScript that loads can hide that area and cause it to display in place when the show link is clicked.
Or... these days you can get a lot done with the HTML summary/details elements - including implementing popup menus.
I don't work on any web pages that are particularly fancy or sophisticated. The main page I work on is the ordering page I maintain (but did not write) for a small company. Their product is pretty simple--a subscription service with some downloadable software to use the service. The ordering page has a section where you can select your subscription length (monthly, quarterly, yearly) with some radio buttons and a checkbox for buying a copy of the software on CD-ROM, a section for entering your email address and billing address, a section for entering your credit card information, and a button to submit your order.
They really want to keep this as one page.
Originally I'm pretty sure they had no JavaScript on the page. That was back when we didn't have to collect sales tax except to customers in our own state, and before the state's tax laws made online sales based on buyer location rather than seller location. The checkout page simply showed your total without tax, and had a note that said if you were in our state we would add tax of X% where X was the sales tax at our office.
Later, when the state switched to buyer based taxing, I believe JavaScript was added. That message about taxes started off just saying tax would be added to in-state orders without stating the rate. When you filled in the zip code, the JavaScript would see if it was an in-state zip code and update that to mention the rate for that zip (which it got from a static table in the JS). It might have even been fancy enough to also show you the total.
But if you did not have JavaScript it still all worked.
Somewhere in there the JavaScript started doing checks for things like missing form entries and blocking submission until the user fixed them. Still worked without JavaScript.
When we started selling in Europe and the UK and had to collect VAT, the JavaScript got a little fancier. Now it knew the VAT rates by country so it could show the VAT before you ordered.
The PHP script that served the page would decide what currency you probably used based on your IP. I modified that to include a dynamically generated JavaScript table on the page that had the prices of all the products on the page in USD, EUR, and GPB, added a currency select dropdown on the page, and added JavaScript to switch all the prices and totals on the page if the user changed the currency.
But it still worked fine without JavaScript. You might see the prices listed in EUR say, and switch the dropdown to GPB, and your order would then be done in GBP using the GBP pricing. You just wouldn't see the actual GBP amounts until you got the receipt page.
What finally stopped it working without JavaScript was a change Visa and MasterCard (and I think some others) made to what merchants have to do when accepting credit card and when storing cards for recurring or on-file billing [1].
You must show the total that will be charged and get approval from the user before submitting the card. You must tell them how often they will be re-billed and for how much. You must tell them what card will be billed (and re-billed). You must get positive confirmation that they have seen this information.
For that, we added a section at the bottom of the page that spells all that out, and has a checkbox they have to check to confirm they saw it. The ordering button does not work until that checkbox is checked.
As the user changes what products are selected, JavaScript is updating the total in the order summary, and updating that disclosure section at the bottom of the page. Same as they change currency. If they changed address, the JavaScript calls a tax API on the server to find the tax, and updates the page. Same if they change the credit card information. The JavaScript unchecks the acknowledgement checkbox if they make any of these kinds of changes after they acknowledged before.
Making that work without JavaScript would, I think, require going to a multi-page order flow which management really does not want to do. I've done some measurements, and everyone who has tried to order over the last two years (both real and bots up to who knows what) have had JavaScript enabled so it is pretty hard to argue that adding a separate milti-page order flow to handle non-JS people is worth the development time.
And so now we've got a page that requires JavaScript. No one set out to require JavaScript, but here we are.
[1] Well...they said they were making this change. They originally announced it, then when it was close to going into effect many payment processors said they weren't ready and Visa pushed it back a year. The payment processor we use got it supported by that second deadline, and we got our site and backend changed, but others were still not ready and Visa delayed it again. I'm not actually sure if it ever went into effect or is still being pushed back.
> You need to enable JavaScript to run this app.
I know I have no interest in your project as you have no interest in communicating with me, only funnelling me into your recently launched startup.