A Note to a Web Retailer about JavaScript-or-Else Pages

I was cruising computer hardware retailers on the web today because I’ve got to make a few orders. Not so many that I need to pester the manufacturers directly, but a large order compared to what most folks buy online with a credit card. Specifically, I need to replace one motherboard and build six new computers (complete with screens, etc.). Checking through a few shops I decided to order from one of the top 3 online stores for computer gear — and was rejected by their website for even trying to browse the product listings because I don’t have JavaScript enabled by default.

This got me to thinking about how stupid that was. JavsScript isn’t necessary for any of that site’s core functionality, particularly when just browsing. I hadn’t put anything in the cart, hadn’t done anything that requires “interactivity” (a laughable concept in a website if you know anything about the history of port 80, but whatever) or anything like that — I was just checking specs and prices, which worked just fine, but every single page is set to a five-second redirect delay if and only if the customer doesn’t have JavaScript enabled.

So I wrote the webmaster a note — and moved on to make my purchase somewhere else. Here’s the note:

Your website works just fine without JavaScript enabled but after a few seconds redirects *everyone* with JS disabled to a “turn JS on or you can’t browse our site” page. There is irony here because most people who browse the web with it disabled by default are IT professionals like myself who
1- Order huge amounts of hardware online and
2- Already know that they have JS disabled and how to enable it when they want to.

So that’s the situation and my complaint. Here’s a suggestion to solve it:
Test for JS and redirect to the JS-or-Else page only when the user hits ordering or shopping cart dialogues or something else to which JS is actually central. (Almost nothing, in fact, really requires JS, its just the only way a lot of web developers know how to think at this point.)

Compromising by making your site broadly accessible and then only forcing JS when the user actually needs a client-side script to run is a much better design policy than doing what you’re doing currently — which is drive customers elsewhere when they are just beginning to browse.

Its too easy to go somewhere that doesn’t do that, and so that is what what I’m doing now after writing you this note. Consider that I’d seriously consider turning JS on if I’d gone so far as to pick out items, fill the cart up, etc. and *then* get told that I can’t process the purchase without JS turned on.

4 thoughts on “A Note to a Web Retailer about JavaScript-or-Else Pages

  1. Robots don’t really have anything to do with JavaScript. If you’re thinking that by not allowing non-JS browsers to cruise your site you are somehow protecting yourself from bots, you’ve got a lot to learn about general computing. This is just a stupid reason.

    Protip: If you don’t want some data to be seen by arbitrary entities making arbitrary requests, don’t put it on a web server.

    HTTP is a publishing protocol. That’s it.

    [I really went off about this the other day. The not-really-on-topic part of the response has been made into a new article of its own.]

    But I digress. My whole point is that robots and JS don’t have anything to do with each other. There are robots that can implement/simulate JS (its an open standard…), there are robots that take over and fly browsers directly (detect that, genius), and there are people who simply don’t like all the trash that comes along with gratuitous use of JavaScript, Flash and related stupid ideas (ActiveX, anyone?). Discerning among the three? Yeah… right. And refusing to let me browse your product inventory because I’m blind and use Lynx to surf the web or because I don’t like weird crap running inside by browser on unknown websites by default and turn of JavaScript, or really for whatever reason at all is just plain stupid if you are a web retailer in need of my money and I in need of your products. That hinders trade, but doesn’t stop robots at all.

    Wow. I really went off on this response. Anyway, “robots” is not a good reason for this. There aren’t any good reasons for this.

    Looking back at this gigantastic response, I think it should be turned into another blog post of its own instead of left as the hugest comment on the site… (o.O)

  2. How about the difficulty of keeping up with the “graceful degradation” principle? If Flash doesn’t work, then a JS or alternate media type should spin up, if that fails then an HTML forms/CSS-based page should load, etc. This is really hard to do and just forcing people to turn JS on simplifies the developer load for the web. I don’t like it, but that’s what passes for a good reason to force JS.

  3. Graceful degradation being hard is a good reason to not consider the web an application development platform in the first place. It is impossible to know what the next must-have client-side browser plugin is going to be, so it is impossible to future-proof a website that steps out of the HTML-document-only paradigm in any way.

    You mentioned Flash, for example — Flash is in its final days now, but how many websites (or really embedded widgets and things) are Flash-based? How long will those websites continue to use Flash? How long will at least one of those sites be important to at least one user that is important to the site owner? Its a two-sided question, and one that is very hard to answer. Once the span indicated by the previous questions end Flash support can be pulled from the browser and the website, but not before. But we don’t know the answer to either side of this question — which means that a prudent website owner should have produced a viable HTML-only version of his site to begin with, which is not what most people do. So as Adobe’s support for Flash fades and new iOS and Android products arrive with zero support for Flash to begin with those websites will suddenly not be reaching their targets because they don’t have an HTML fallback.

    How long is JavaScript going to be the Big Thing? Remember when Java applets were all the rage? Where is that now? There is absolutely nothing that guarantees the development world won’t either come to its senses and realize that JavaScript is a severely inconsistent and hamstrung language (or just get tired of it when something else less advanced than Algol gets industry attention) and move on to the Next Big Thing.

    HTTP/HTML is cool because it is a deliberate attempt to create a lowest-common bar for document publication over the wire. The Web sucks because it is an attempt to use the lowest common denominator present across the most common systems and turn that into a common application development platform. There is no way to fix this and demanding that site visitors turn on JavaScript this year does not do anything to prevent JavaScript from falling out of style next year, losing client-side support, changing form so radically that today’s scripts won’t work tomorrow, or any number of other random disasters. JavaScript/ECMAScript isn’t even fully implemented anywhere in the wild today, and every existing implementation is inconsistent with the standard.

    After all that I just wrote above, it is important to remember that none of the functionality provided by the site I was visiting requires JavaScript (not even a little). Listing products is actually a more complicated task when JavaScript is involved than if it were simply paged by the server’s own populated template.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.