Using the Web for a Day with JavaScript Turned Off
smashingmagazine.com
smashingmagazine.com
At some point (maybe after the popularity of Google Maps?) nobody wanted progressive enhancement and it was totally cool to just ignore users who had JS turned off. It made web app development so much easier, but probably less user friendly.
It feels like JS is a hammer to fix the nail of the page reload. I always thought it was too bad that browsers choose to show the blank page instead of sending the request and just rendering the difference themselves.
FWIW there are libraries that work around this, e.g. turbolinks - which I heavily suspect Github is using, and is probably a large part of why they're able to support progressive enhancement.
I still do that on my case, a good 95% of the features I develop work without Javascript. One additional benefit is that if your JS crash for any reason, most of the things are still working.
There are so few web apps that actually need the SPA treatment. It’s a lot simpler to ignore the tool chain headaches that come from committing to the SPA when you don’t need it and gracefully degrade.
It’s so rare that I actually run into an SPA that doesn’t feel slow...I just wonder why people bother sometimes.
It's fashion over function on the business side, and CV-driven development on the frontend people's side.
Oh, there's a function to it. The 7 year tech cycle generates huge amounts of money for everybody involved. Consultants and consulting companies get a nice influx of billable hours every time the tech changes. Software companies pay to upgrade to the coolest tech because it's relatively cheap compared to the amount of money it generates. Users like it because with each tech upgrade comes an increase in convenience and graphical design. And, in some ways, having the latest version of the hot apps is another way of keeping up with the Joneses. Everybody's happy except for the power users. They tend to get left out in the cold.
- Visitors with a bandwidth so low it takes a long time for the JS to download completely (so making it work in the mean time helps a lot).
- Visitors with outdated browsers where your JS will stop on some unsupported feature you forgot to polyfill (I usually add a polyfill after when I see it but in the mean time it works), that's what I meant by "crashing", it never works 100% of the time in 100% of the cases, it depends on the browser as well.
Causes vary. Sometimes it's a resource that fails to load. Sometimes it's a race condition. Sometimes, it's just dumb coding[0]. The more JS is put on site, and the more the site depends on it, the more likely it is to happen.
--
[0] - Like one of the large food order sites in my country that won't let you submit a form if it contains a number in the comment box - the very comment box you're supposed to use to add details like floor number. The problem persisted for the last couple times I used them (in a space of several weeks), so I wonder if they even realized they have a problem and are losing business because people see the checkout form broken without explanation, and order elsewhere.
I think people expect much more interactivity now, (I think google maps was a driver and web based email as well), so it became harder to do pure back end. For example a lot of the queries I run now show a dynamically generated graph. I can do that on the back end, but much easier to use a javascript charting package. I guess I could just use javascript all the way down
This keeps coming up.
Personally I keep thinking that devs and cv-driven development might be to blame as I rarely hear any customer demand anything that demands a frontend framework for their web sites (now web apps, that's another story).
The real problem is that fashions are even possible on the web. This is what Ted Nelson calls the "triumph of typesetters over authors," and it's one of the great tragedies of the computer age. We could have had a real, global, hypertext system with working two way links and micropayments, but instead we got HTTP and HTML.
If you have other content though, it's not OK to not show anything; only the graph should be missing without javascript, the rest of the page should still render.
You can put data for the graph into a table, then use a script to render that table as a graph. If people cared enough, graph libraries could expect heir data in table format.
Saddly most graph libraries seem to love json data formats, which aren't logically table oriented... though if you used the json data and javascript to load the table and create the graph...
If the number of people who visit your site with JavaScript disabled is less than the number of people who visit using the Opera browser, does it really make sense to add [number of supported browsers] x [JS on | JS off] permutations to your testing workload? Is spending the time and resources on creating a non-JS site worth it, or would it better spent somewhere else (usability, accessibility, etc.)? Everything is a trade-off.
I personally feel the JS ship has long sailed. I'm more worried about the recent trend of sites not even working in Firefox anymore, just Chrome. That is definitely a bit sad.
It depends on what you're doing. If you're building an app (something which would make more sense as a native program anyway), then sure — use JavaScript. But if you're displaying text and images, then HTML & CSS are perfectly capable of handling that.
In general, I think that a good content-focused website will work equally well across all browsers. There's no need to force end-users to allow you to execute code on their machines in order to display paragraphs or images.
> I'm more worried about the recent trend of sites not even working in Firefox anymore, just Chrome.
And I'm worried about the long-standing trend of sites not even working in lynx, links, elinks, eww or w3m anymore, just Firefox, Chrome & IE.
If your site doesn't work for people with JS disabled, you're unlikely to see significant traffic from people with JS disabled.
It is VERY much an alpha and a lot of things aren’t working, just the bare minimum.
(followed by some horribly formatted content, at least on my phone)
Guess which product I will not be buying today?
No worries etatoby, just wanted to share an alternative.
EDIT: Thanks for your comment though, I just thought of some ways I can improve usability by using <noscript> to explain why JS is used for something.
Hmm there is a pretty big "Pricing" section in the middle of the page for me
Even a naive approach to making a javascript-rich site render with JS turned off will have profound positive impacts on usability and accessibility, so I'd say it's still worth it.
Comments like these make me wonder if any of the people saying PE is hard ever tried it at all. The whole point of progressive enhancement is that you don't create a separate non-JS website.
Example: I make a form. It works without JS, so my server has to generate the form, handle the request where the form is submitted, and generate the result HTML. If I'm practicing good separation of concerns, the work is done in a service/contained library that the webserver code calls and assembles into a page. Then I go to add a "nice" Js experience: disable the normal form submit, read the form data, send the request, parse what I need out of the HTML result ("parse" = easy cut here) and replace the portion of the DOM involved. A nice, maintainable PE site. Nothing wrong with that.
But if I have the server generate the original page only, I can have JS read the form, call the service, and update the DOM. I was able to completely skip the server composing a new page. And that's for a bone-simple form, if my site has any interaction on that form before submit, each step represents duplicated effort. Checking if a name is already used? JS to call a service and add a line. Server/service absolutely needs to check that, but if we're not worrying about PE we can completely skip worrying about a nice UI generated on the server-side (which would involve re-populating the form we got, so it's not just "same HTML + one line"). And that's still the stupid-simple stuff.
To do this I need to design the application w/o JS and then find nice ways to improve it. But my designers, my PMs, they are all thinking from a JS-first point of view, so without PE when they say "do X" I can do X. With PE when they say "do X" I need to figure out how to do Y (a flow they didn't consider at all), and make sure it can behave like X. Anywhere it's hard to do so, it's on me to fix that because neither design nor business consider PE remotely important or valuable.
PE is great, and I'd love to work on more sites that use it...but I'll confess I rarely put forth the effort myself, even when I do have the space to do so in a project. Because Progressive Enhancement IS effort (most importantly time), effort that will most likely be seen by a single digit number of users and I've got a lot of stuff I want to do and a lot I need to do. Even a free hour can improve my productivity or quality for far more users if I spend it in something other than PE.
PE has very real benefits beyond just working without JS...but even those benefits rarely outweigh the time/effort costs in an industry where there's always far more work than time.
Back in the early 2000s, this meant you had to check your site in IE. Stragglers still using Netscape could pound sand.
If you were checking user agents then chances are you were doing something stupid or lazy.
I don't know who "we" is, but what was touted and what was actually done were, then as now, two different things. The client wanted something fancy, was only willing to pay developers who would deliver, and (crucially) was running IE as their browser. As was most of the audience for the page. Stupid or lazy it may have been, it's still what web developers did to feed their families.
They haven't and now we're in this javascript SPA mess.
Intercooler.js provides a preview of what this could be like, but, of course, it's layered on top of javascript since that's the hammer we have to work with.
Probably had the word "Active" in it. Active control or something like that.
I aim to develop web UIs using (mostly) progressive enhancement. I adopted several practices and developed some libraries supporting this process. As a result:
1. When I need to create something, I know exactly which data structures to use. This is determined by what is available in modern browsers.
2. I can quickly prototype solutions using plain HTML focusing on logic rather than style.
3. Since my data is by definition contained in HTML, I can easily query it using CSS queries. This makes working with nested data a breeze.
4. I factored code I reuse into generic, self-contained behaviors. Things like "when this form is invalid, this control should be inactive". There is usually very little to none page-specific code.
5. Once a behavior is written and tested, "debugging" usually involves simply making sure the page has the right attributes. I can do this by running a CSS query in console or looking at DOM. No breakpoints, no stepping, no watches.
6. The most important part: I can add one behavior at a time and the result is something that works and makes sense.
7. A lot of UI "logic" I used to have in scripts naturally migrated to CSS.
I like this process way more than fiddling with tons of page-specific "glue" JavaScript. I especially like it when I'm in a crunch, because it pre-defines a lot of the things I would have to "design" on the fly in a traditional development workflow. Also, if I run out of time I have a working (if ugly) app. If I introduce a bug somewhere in UI or run into a compatibility issues, it usually doesn't result in the entire user workflow stopping dead.
Server side rendering with vanilaJS for the snippets that actually matter.
Sometime you have to cut corners, sure, but if you know what you are doing, the PE way is probably the easier one from the start.
It really isn't that hard to design a functional HTML site and then layer Javascript and AJAX over top of it to enhance the experience. There are very few sites that actually need to be using Frameworks like Angular and React.
Sometimes I wonder if most developers would even be able to design a functional site using only HTML. It seems like most don't know the difference between a button and an anchor.
With modern server side frameworks it's even easier to support graceful degradation or progressive enhancement as the frameworks will handle the accept header processing for you.
One might debate if a page really needs hundreds of kb of js to function, but then again, this is not much different than the classical progressive enhancement site with jquery etc. layered on and reacts server rendering can make to page easily available and working when js is disabled.
Careful planning is required of all frameworks to make a JS free version. I wouldn't say it's a feature of React or that it's free.
> One might debate if a page really needs hundreds of kb of js to function, but then again, this is not much different than the classical progressive enhancement site with jquery
JQuery was a crutch that wasn't strictly necessary and with modern browsers you can largely do without it and write pure JavaScript. Assuming you know how, which I would wager most developers don't.
With that mandate, the site (about 300 pages) ended up almost completely js-free. I think there was only one page that had js, and that was for a calculating widget.
js is great for certain things, but certainly not necessary for all the things it's used for.
Maybe throw this in the pot: There are those of us who care about such things, and honest signalling counts for something.
I remember there was a movement to be completely JS free in late 90s/early 2000s.
I feel like there was a huge uptick in developers ignoring users with JS turned off when Angular and React started becoming popular. It's interesting to note that big tech companies, who have a financial interest in pushing websites away from progressive enhancement techniques, were the ones behind the creation of those frameworks.
JS is useful for much more, e.g. collaborative editing, where the user doesn't have to wait for a server round-trip. JS is essential for a real-time multi-user interactive web.
I block all JavaScript, then re enable it when needed to fix a site.
Often I just need to enable 1st party scripts in the uBlock Origin grid to fix it.
Make sure you enable advanced mode to see the grid.
It's also interesting seeing how many tracker domains each site tries to hit, definitely changes your opinion on different sites.
Having just one is certainly less hassle, but uMatrix gives more granular control over what's allowed by the first/third party domains than uBO's advanced mode.
Much safer to disable umatrix in the normal tabs then.
There's a bit of a dance you have to get used to when things don't work, but I've got it into muscle memory now so I don't even think about it. I tend to click around in there enabling the first few obvious things for about 3 seconds, which works 95% of the time, and for the the remaining 5% the URL gets copy-pasted into Chromium.
Wait, what are all these floating obstructions? I thought I disabled all JS... hang on, you mean CSS is now full of animations and distractions too? https://addons.mozilla.org/en-US/firefox/addon/unstickall/ and https://github.com/gagarine/no-transition.
What's that? Sticky sidebar full of chum? No problem - uBlock Origin's "right click, block element" to the rescue.
The internet doesn't have to be shit any more!
Actually, when I get stuck on a different computer and I'm forced to use the same terrible internet everyone else has to use these days, I catch myself clicking around where my uMatrix icon would normally be and it takes me a few seconds of dawning horror to realise that I've totally lost control of my experience.
"No thank you, the latest celebrity diet fad isn't really my cup of tea." "What? Where is this autoplaying video hiding?? Must be under one of these neo-popup JS disasters." "No, I'm not interested in 17 ways that my imperfect sleep is going to kill me right this instant." "NO I don't want to download Bonzi Buddy."
uBlock Origin doesn't have CSS or image control per domain but it's the JS I worry about!
Decentraleyes is also worth a look if privacy concerns form a part of your aversion to the blizzard of garbage your browser spews forth at you. It contains in-browser hosted copies of all that CDN JS junk, so if you have to turn on JS for some shared copy of jQuery that Decentraleyes happens to have bundled, you don't hit the network at all.
Next, long press the reader view button in safari’s url bar, and turn it on for all sites.
Finally, since Apple doesn’t support high contrast black backgrounds in reader view, go into accessibility, turn on the three clicks to bring up accessibility shortcuts option, and add “classic invert” to it.
As a bonus for reading this far, also add “magnifier” to it, which lets you use your rear facing camera in a surprisingly good magnifying mode that should be part of the default camera app.
Every site should have a plain html option. Or create their html so that it works fine without js or cnn.
I can only applaud this effort!
I made a lite version of a job listing site I'm working on but its go live approval got lost in bureaucracy.
* gopher://jdebp.info./1/
I surf the web, as I have for many years, with NoScript turned on and as few permanent domains white-listed as I can get away with for security reasons.
I don't have any numbers to back this up, but my guess is that the population of people who use the NoScript add-on dwarfs the population of users that actually disable their javascript in their browser. I'm not sure how someone like me shows up in their numbers, but I suspect that I would be on the "blocks javascript" list and then on the "uses javascript" list if I am intrigued enough about the site to enable some of the domains it requests javascript from.
I don't know if web developers take that into account or not, but I suspect they don't because the number of domains I have to experimentally temporarily enable just to see some parts of some sites is getting even more ridiculous these days.
Maybe someone should design a new protocol that is built for interactivity from the start instead of one designed around static content with back-flips needed to make it usably interactive.
I wonder why if I can sell my lack of skill on the market... because the skilled designers/coders are programing a web that really has a tendency to be so bloated.
I browse the web with no-script (firefox extension); and many websites won't even load without scripts. I wonder why. For many many website I don't see the need to have JS around at all.
Can the lack of skills be a skill? :) hire me!
These type of articles are a shame and are only written to instigate fights among developers. The world is using JS, it's on every major app. Get over it or make something better.
It takes a few seconds to load the post titles, it'll make your computer grind to a halt if you have more than two tabs of it open, it took months to write, and it doesn't do anything you couldn't do with plain HTML and some AJAX request handlers... but Brawndo has electrolytes!
I bet it looks pretty good on his resume.
I bet it looks pretty good on his mantelpiece.
There comes a point where you have to ask yourself - does it matter that he built (what I assume is a personal) blog in framework du jour, simply he just wanted to?
Facebook has a no-js version of their website which suffices for all of my purposes.
AJAX for all form submissions
Service Worker for caching
Turbolinks[0] for page navigation
Of course it can be done, not something I'm going to worry about as a solo operating and developing multiple ventures.
Are there marketing-specific attributes of anti-JS web users?
My mobile browsing experience has been immensely better since I installed Brave and set it to block everything by default, including js.
When I'm presented with a blank page (not very often) I evaluate in a split second whether the several seconds needed to reload the site with js enabled are worth its content.
90% of the times the answer is no, so I click Back and then try the next search engine result for the same query. 10% of the time I really want to see or use that particular website, so I enable js for it on Brave's panel and wait for it to reload.
Summary: 1 additional click and 1 additional reload (to be only paid once) on websites I care about. ∞ less nuisance on everything else.
I Used the Web For A Decade With Javascript Turned Off.
I have been using the Web for over a decade via software that has no Javascript capabilities.
There is a conception one can detect in this article that there is only one "working" look for any website: the look that the designer intended.
However IME many websites "work" without ever engaging the "look" the designer intended. To discuss this, one needs to first specifically define what it means for a website to "work". I am not sure agreement can be reached on that issue.
It may be that the definition of "work" varies with each user. Different users may want different experiences. I know what I want from websites: data. I am less concerned with design. This may not be the case for another user.
The author cites Amazon as an example website.
When I am only browsing Amazon I do not use a "modern" web browser nor Javascript. Without a browser nor Javascript I can download product data in bulk, convert it to CSV and import it into kdb+ for easier searching and viewing. Without a browser nor Javascript I can download images of interesting products and embed them into a simple PDF for offline viewing, using pdflib.
When I am ready to purchase, then I might move to a "modern" browser with Javascript-enabled.
Other example websites he gives are Wordpress, Github, Instagram, Twitter and YouTube. I read the content of all these sites without ever using a "modern" browser nor Javascript. If I want to view images or video, I can download them as in the above case of Amazon. I may choose to view the data in whatever application I choose on whatever computer I choose on the local network, and the computer need not be connected to the internet.
For this user, these websites "work" just fine without Javascript. I can always use a "modern" browser with Javascript if I want to see what the designer intended. However this is rarely necessary for the experience I seek.
i always have js off by default, and turn it on momentarily when i feel it necessary. i do not feel it necessary for yelp.
Goes to show how much effect the large number of requests have.
requests blocked
on this page
168 or 96%
I think we've about reached the point of ideology on this. If you are considering arguing with the other side your probably better off arguing evolution with a creationist, or facts with the GOP.
I've never been an ideological seeker of "organic, all natural" type foods, because the criteria tend to seem arbitrary and unscientific, but I've come to see the label as useful because the other stuff is increasingly adulterated with garbage I don't want.
Such a search engine would never be widely used, because there's no widespread desire to limit search results only to sites which don't use javascript.
A more useful search engine might be one that shows whether or not a site uses javascript, and if so, which common libraries, etc. Maybe even whether or not a site will render without javascript.
In my defense though, this whole conversation feels like a time loop on HN every time it comes up. It's not hard to predict/categorize the arguments and arguers at this point, as a generalization.
You have a vocal group of progressive enhancement cargo-culters who are a decade out of time; the very real motivators for the formation of the dogma missing for years. For them, progressive enhancement is "the way it should be". Then you have a group that know the ship has sailed shouting down anyone who won't join the new world order, regardless of whether they have significant value/cost reasons. Both sides talk at each other.
On the fringes there are the hypermilers and the data analysts. There is a small contingent of the equiv to hypermilers; they know it's rather inconsequential, with no notions confusable with ideology, but it's more of a game or hobby to them. The data analysts actually talk about the numbers of people still blocking javascript and whether it's worth the effort in 2018 for the average site.
At this point it's more a social study than an insight into the cost/benefit.
> There is a danger that more and more sites will require JavaScript to render any content at all. What danger, exactly? While some sites that don't require a lot of js is nice you will soon notice that many sites you want js on. Music streaming services is one example.
I build api based sites nowdays because of mainly two reasons:
1. They feel more rapid after initial load and gives the user a better experience.
2. You can use the same api for web and mobile experiences.
I personally think that WebAssembly is the future so the web will finally just be another compilation target and I can't wait for it to be wide spread.
Hmmm, I'm not sure about that. I've only done toy projects with WebAssembly, so I could easily be missing something, but it seems to be:
1) Overkill for most websites
2) Significantly more complicated than current web development - which is saying something given the explosion in complexity of recent web development practices
Obviously #2 can be lessened as time goes on, but it's hard for me to imagine #1 ever being false. It's great for performance-sensitive applications like games, but it doesn't seem to offer much benefit for CRUD apps or static sites.
I really hope not. I don't believe we've seen the last of exploits like Spectre & Meltdown. Allowing anyone in the world to execute code on the same machine whose memory contains your bank accounts, your private memos, your passwords &c. will, I hope, come to be seen as riskier & riskier as time goes on.
I fear that in the not-too-distant future web pages will simply be blobs of WebAssembly which paint UIs within a browser, and general-purpose computers will have become TV terminals — but TV terminals which allow the modern equivalents of networks & newspapers to steal one's private information.
Some will, probably, but there's no reason all web pages will go that way. "App" type sites almost certainly, maybe streaming services, but the benefit just isn't worth the cost for most sites.
It didn't happen with Java, it didn't happen with Flash, it didn't happen with Silverlight, it didn't even happen with javascript even though it's possible to publish an entire web UI as an obfuscated "javascript blob" that writes on a canvas. It hasn't happened now that most people surf the web on walled garden Android phones, arguably the antithesis of a "general purpose computer" and closer to the "TV terminal" you described. Why is Webassembly the straw that will break the web's back?
If almost no one actually wants to build the dystopian scenario you're afraid of, and doing so would probably be impossible, why be afraid of it?