JavaScript support – the issue of how many, and how to gracefully degrade

One of the most popular debates on front end development over the last ten years has been regarding the usage of JavaScript. Many have fiercely criticised developers that didn’t take into account users browsing with JavaScript disabled.

When I built the new Jet Booking Direct, I always knew it would rely heavily on JavaScript. One of the most critical examples of this would be the updating and changing of the flight, which was done using AJAX. So how broken exactly is the website with JavaScript disabled? Let’s take a look, first the home page.

First, we’re alerted to the lack of JavaScript support. Even if a website relies heavily on JavaScript and simply cannot work without it, including a polite message such as this, may be enough to persuade the user to add your site to their exceptions list so it works. Secondly, we can see some differences in the search form. Most notable here is the lack of the passenger number spinner.

This spinner can only be coded using jQuery, and the spinner helps usability by making it very quick and easy for the user to adjust passenger numbers without having to manually type them in. However, with JS disabled, the form field still works. What it does lack is a label indicating what the field is for. The form also now lacks live validation, another feature that only JavaScript can provide. This is a good reason to make sure you also use PHP validation, which fortunately my system does.

The good news is, aside from the lack of the label for the passenger field, the form is largely the same and equally as usable. So we can easily request a flight, which takes us to the flight request page.

Most notable here is the glaring large white space where the map should be. Google Maps requires JavaScript support to work. However, one good bit of news is that we’ve still been able to obtain a guide price and a recommended aircraft type, which is the most important feature of the page. This is of course because this part of the functionality is done on the back end by PHP.

However one glaring issue is that on desktop devices the pop up form to send off the flight request is handled using JavaScript, so with it disabled, we’re unable to fill in our details to get a live quote. This is perhaps the most serious issue so far. We are also unable to edit the legs or add to our flight.

Overall, were I asked to score my pages here on how well they perform without JavaScript, I’d give the home page an 8/10 and the flight planner page a 4/10. The most serious issues are with the planner page. However, they are not issues that we can’t fix for users browsing without JavaScript.

Fixing our JavaScript issues with Modernizr

We can fix our issues primarily by using Modernizr. I won’t go over adding this to your site, there’s already plenty of tutorials online for that, Google is your friend.

What Modernizr will do is switch around a simple class to your HTML tag, depending on whether or not it detects JavaScript support. By default, you should add the class “no-js” to your HTML tag. If Modernizr is able to run, there must be JavaScript support, it therefore then removes the “no-js” tag and replaces it with “js”.

Aside from our doctype, our HTML tag is always the first on the page. This means we can target its descendants using the class “no-js” in our CSS. For example, we may find that a particular field needs to be wider when JavaScript is disabled. So we can do this:

.fieldname {
    width:220px;
}
    .no-js .fieldname {
        width:320px;
    }

The result of this code will be that on pages with JavaScript support, the field will be 220px wide. On pages without JavaScript support, the field will be an extra 100px wider. This is great because now we can specifically target non-JavaScript supporting users, and have better control over how well a page works for them. So now I’m going to try to fix some of my issues, first, the passenger field on the home page. Remember, it lost it’s spinner functionality as well as its label. We add in the extra HTML:

<label class="pax">Passenger Numbers?</label>

We want the label hidden for JavaScript users, and visible to those that have disabled it. So we can now use our no-js HTML tag class.

label.pax{
    display:none;
}
    .no-js label.pax{
        display:block;
    }

Some people would argue that this method is what is called graceful degradation. If you prefer the progressive enhancement route, we just need to switch between using the “no-js” default class, and the “js” class that Modernizr switches it with when it detects support for JavaScript.

label.pax{
    display:block;
}
    .js label.pax{
        display:none;
    }

However, bare in mind that going down this route will almost definitely lead to more bloated code, because every single bit of CSS that is used for JavaScript elements will need to be prefixed with the “js” class. That is going to be extremely tedious to work through, the reality is that in this case graceful degradation is the smarter and easier route to go down. There’s more on this courtesy of Paul Irish.

So how does it look?

I also styled the label to look similar to the others. So now we have a label, the field is again usable, which is exactly what we wanted to achieve.

I’m not going to talk through fixing every single issue, but in quick summary, I can now use some clever CSS fixes to enable the site to work much better for those browsing without JavaScript.

No-JS Support – Yes or No?

So now you know how you can fix issues regarding JavaScript support. The bigger question though is, when you weigh up the time required to do so, can you justify it? Do enough people browse without JavaScript support to warrant going through all this effort to make your site work for them? This is a difficult question to answer with certainty.

My attitude is to treat JavaScript support in a similar fashion to how I treat browser support. Below a certain threshold, I cannot justify the extra development time. For example, the New Jet Booking Direct was not coded to support any version of Internet Explorer below IE8. This is because combined usage of 6 and 7 on this particular website is below 2% and dropping rapidly (this time last year it was 5%). And because of how advanced the website was, and how much time I had to dedicate to the back end side of development, I couldn’t justify the extra time required to make it work well in these browsers.

So I would apply a similar attitude to JavaScript. Try to establish how many are browsing the particular website with it disabled, and then figure out exactly what doesn’t work with it disabled and how long it would take you to get it to work. In my case, fixing the label for the passenger field was a two minute job, so really there isn’t much of an excuse not to do it.

It is also quite likely that the number of users still browsing with JavaScript disabled is extremely low, worldwide I would estimate below 1%. Whether you decide to support them or not, really needs to be site dependant and project dependant. For bigger sites, this 1% is going to represent a much more significant number of people so it’s more important to consider them. On smaller sites with low traffic, it may just be that you cannot justify the extra time and cost.