Progressive Enhancement and what that means for JavaScript

Taking a neutral look at whether or not a Progressively Enhanced approach to JavaScript makes sense for all Websites?

By Luke Whitehouse on



Should we provide our user's with an experience when they do not have JavaScript enabled? At face value a relatively simple question, yet one that fuels debates across the entire Web Industry.

With the subject matter creating such a strong division between the sides of for and against, all discussions ultimately degrade into chaos and becomes a game of who can shout the loudest.

Recently, Josh Korr published an opinionated blog post on the reasons against progressive enhancement, especially surrounding JavaScript's place in the workflow.

On the back of a twitter thread sparking outcry from the Industry, I noticed a conversation between Rach Smith and Sara Soueidan reacting to Josh's blog post.

After reading through their thread and a reactionary blog post from Aaron Gustafson, I completely understand where Rach is coming from, many people still don't fully understand the arguments for and against Progressive Enhancement and instead of reasonably looking at each side's views we become pubescent teens unable to have a thoughtful discussion on the matter.

With that said, for the rest of this blog post I'm going to play devil's advocate, a neutral party looking to provide insight into the points that many make for and against a non-JavaScript experience or just Progressive Enhancement in general.

Let's begin.

"Websites should be accessible to all users"

Accessibility will always be a hot topic, and the Web Industry is no exception. When we think of Web Accessibility though, what are we actually referring to? Well, if we're taking the classic definition of accessibility then the W3C's Web Accessibility Initiative describes Web Accessibility as...

Web accessibility means that people with disabilities can use the Web. More specifically, Web accessibility means that people with disabilities can perceive, understand, navigate, and interact with the Web, and that they can contribute to the Web. Web accessibility also benefits others, including older people with changing abilities due to aging.

Web Accessibility Initiative, 2005

Someone unfamiliar with the concept of Web Accessibility may then believe the book stops there, to provide an accessible website for people with Physical or Mental disabilities. If thats you then I'd like to reference a WebAIM survey from 2012 that disproves the idea that JavaScript is inaccessible for people with disabilities by showing that 98.6% of screen reader users have JavaScript enabled, with the numbers being even higher for people with low visionary impairments.

However, I, like many others describe Web Accessibility as a much broader subject and being the inclusion of all users, no matter their:

  • Physical or Mental capabilities;
  • Device and browser used;
  • Connection speed or quality;
  • and any other unknown factors about them.

Based on this definition, you can start to understand why people are so protective over the subject, is it not our duty to cater for as many people as possible?

Telling someone they cannot use your website because they don't have JavaScript enabled could be likened to telling someone in a wheelchair they cannot access their bank because there are too many stairs. Just as we might complain at said bank for not including a ramp, they may feel the same way about a website not providing an experience outside of JavaScript. Granted that experience may not be identical, but 'something' is always better than 'nothing'.

Moral obligation is a great motivator, however, who draws the line? Perhaps the Government? Are we legally obligated to provide an experience for users without JavaScript? Whilst I'm no expert in UK law, after a little research into the UK Equality Act 2010, it only mentions the more traditional approach to accessibility by stating that...

A person (a “service-provider”) concerned with the provision of a service to the public or a section of the public (for payment or not) must not discriminate against a person requiring the service by not providing the person with the service.

Section 29: UK Equality Act 2010

With there being seemly no legal obligation to cater for user's without JavaScript (in the UK at least), the book then ends with the project team. Do they want to support an experience outside of JavaScript? If so are we now talking about a battle between Moral Obligation vs Financial costs? For the Moral Obligation, allow me to provide a counter argument.

"Our application requires JavaScript"

Whilst most website's will force themselves into using JavaScript as a preference, there are some website's that simply don't have a choice, which is where things get tricky. When a product requires JavaScript as its primary language for functionality, how do we then provide an experience for user's without? Google maps is a prime example of this.

Google Maps does not provide support for user's without JavaScript

Fig 1: Google Maps does not provide support for user's without JavaScript

As seen in the image above, Google Maps does not support an experience without JavaScript being enabled. Many interactive website's out there require JavaScript to run, as there is not an alternative experience that can be presented with just HTML and CSS. In this case, should the developers be held responsible for not providing an experience to those user's without JavaScript? Of course not, there is no possible experience they can give other than "This website only runs with JavaScript enabled".

That being said, a lot of people misconstrue this notion to justify their development stack.

"Our Framework doesn't work without JavaScript"

With the rise of frameworks such as React and Angular in the past few years, many believe that JavaScript can no longer be purely an enhancement to the initial HTML & CSS layers and has grown into being the website itself. In their eyes, without JavaScript you don't have a website, just like we might say the same about HTML.

Personally, I believe this to be a fallacy and an inherent flaw with the current JavaScript frameworks we have to hand. No matter the language, frameworks never are nor will they ever be a requirement for a project. A framework by definition is a structured approach to development in a particular language and fundamentally uses the same code as any vanilla counterpart. True, a framework may provide you with some development benefits such as scalability and maintainability of a project but they are by no means a requirement.

Therefore, by using a framework which pigeon-holes you into this mentality, you're putting the ease-of-use for you as a developer over the needs of your potential user's who cannot use JavaScript (for whatever reason). Whether that's right or wrong is for you as a team to decide, but don't use the excuse that your preferred development stack does not support an experience outside of JavaScript as a justification.

On the flip side, what are the benefits of Progressively enhancing a website with JavaScript? Let's start with the obvious financial benefits first.

"You'll reach more users with Progressive Enhancement"

The more users that you allow to access your website, then the more business you will create as a result. We all know this by now, the primary goal of any website is to have as many people viewing it as possible, so to enable people without JavaScript to experience your website is always going to be a financial gain, right? I thought so too, but looking at the data may prove the opposite.

How many people use your website without JavaScript enabled? Unfortunately, just looking into your Google Analytics isn't a reliable solution, as the UK's Government Digital Service (GDS) found in 2013 when they discovered that only 0.2% of people had JavaScript disabled in their browser or don't support it. However, upon further investigation they also uncovered that a further 0.9% of people didn't receive JavaScript even though they had it enabled on their browser, possibly due to one of the following reasons:

  • corporate or local blocking or stripping of JavaScript elements
  • existing JavaScript errors in the browser (ie from browser add-ons, toolbars etc)
  • page being left between requesting the base image and the script/noscript image
  • browsers that pre-load pages they incorrectly predict you will visit
  • network errors, especially on mobile devices

Number of users without JavaScript

Fig 2: Number of users without JavaScript.

That's 1.1% of the entire user base for the website, which caters for user's of varying backgrounds and origins, handling typically around 10k users every 5 minutes. Whilst every website will have different levels of traffic, I'd go out on a limb to say has one of the highest requirements for Accessibility in the web and provides a solid baseline for us to work from.

Now, if we're focusing at purely the financial concerns, one could argue whether 1.1% of traffic is actually worth supporting.

Side stepping a little into Browser Compatibility, we might take a browser only being used by 1.1% of traffic as unworthy of the development work needed to cater for this browser, yet we're supposed to do the exact opposite for user's without JavaScript? Why?

In an ideal world with unlimited budgets I'd definitely invest the time to optimise a website for all users, however, we don't live in an ideal world. For businesses with tight budgets, I can definitely see why they would say no. Quite honestly, the time would be better spent in other areas of the business, depending on what the ramifications are for Progressively enhancing the user's experience when we know they have JavaScript capabilities.

It all depends on the costs

If you're telling me its going to take a few hours to create support then I'm sure there wouldn't be a problem, however, if we're taking a couple of weeks then that might be a different story. Assuming your hourly rate is £50 per hour and you work 8 hours a day, 5 days a week then £150 is far different to £4000.

The main thing to remember here is the decision should be on a case by case basis, rather than a blanket yes or no. The next time you come onto a project, ask yourself:

  • What is the budget for this project?
  • What are the time scales we're working towards?
  • Can I actually provide an experience outside of JavaScript?
  • What are the costs to do so?

Concluding thoughts

Hopefully by reading this post you've realising that creating a website which provides an experience without JavaScript and the topic of Progressive Enhancement in general is not as black and white as one may think. There are arguments for and against so each project needs to take these points into consideration before coming to a conclusion.

In addition, I'd like to think the next time we see opinionated posts such as Josh's, we approach them with less pitch forks and instead try to weigh up both sides of the coin to come to mutual agreements. Let's work together, we're better than this.

Further reading

Until next time 👏

Follow us on Twitter, Facebook or Github.
© Copyright 2019 Assortment.
Created and maintained by Luke Whitehouse.