I was thinking that if all the users of a website are required to have JavaScript enabled, Is it ok to use obtrusive JavaScript?

I'm all for progressive enhancement, but what's the point when an advanced web application bounces users at the door if they have an old browser or JavaScript disabled?

We have a very slim target audience, and we can tell our target audience what browser and plugins/functionality they are required to have. So my question is, is mixing JS and HTML alright in that case? Like using onclick attributes.

  • 1
    "If all the users of a website are required to have JavaScript enabled...if they have...JavaScript disabled?" <-- This is a contradiction, and I'm not sure how to give a useful answer with it unresolved.
    – HedgeMage
    Commented Jan 29, 2011 at 12:57
  • 3
    Note that depending on your target audience and market, there may be accessibility laws that require your websites to be accessible to all users, including disabled people. What that means in practice for JS I don't know. AFAIK (IINAL) where I am we have such laws but there have not yet been test cases to work out the details.
    – James
    Commented Jan 31, 2011 at 9:45
  • 16
    What do you mean by "obtrusive" javascript? I'm not familiar with the term.
    – Macke
    Commented Feb 6, 2011 at 22:23
  • 2
    So your question basically is: Is writing crappy code ever ok? Yes it is, for prototypes and projects that sufficiently small and require no maintenance/upgrades once finished. Otherwise you'll just facepalm yourself half a year later, because it takes you an hour to figure out what could have been plausible if you had invested a few seconds more when you put it in place.
    – back2dos
    Commented Feb 8, 2011 at 10:20
  • 3
    I thought this question was going to ask wether it was over ok to resize someones browser window or have tons of popups. Commented Feb 9, 2011 at 22:54

15 Answers 15


This is a business decision rather than a design decision.

There is a cost to providing a version of the website that works without JavaScript (or Flash, or Silverlight). The business has to decide whether the loss in revenue/visitors is worth it or not.

So if it costs $10,000 to do write this version (the number might be on the large side, but it's there for this example only) then will the business recoup that outlay over the lifetime of the site? If not, then don't provide that version.

However, if it only costs $100 to write this version then it would make sense to provide the graceful degradation.

Having taken the business decision to only target JavaScript enabled browsers and expect that your users will have JavaScript enabled then it makes perfect sense to make your application take advantage of those features you now have available. The only thing you will need to do is (like Stack Overflow itself does) is put up a warning that the site won't function correctly if the user hasn't got it enabled.

  • 2
    I think you a misunderstanding me.
    – Petah
    Commented Jan 31, 2011 at 23:54
  • 5
    You should kindly tell us WTF "obtrusive JS" means to avoid the misunderstanding. You've been already asked to do it (upvoted 7 times)!
    – maaartinus
    Commented Feb 9, 2011 at 22:12
  • 1
    I've built some gracefully degrading pages in the past and found the html and javascript to be a lot less transparent, if you still want to offer the JS enabled visitors the best user experience. The pages were A LOT harder to build and I believe the guy maintaining the page will have quite some difficulties following your code. So there is certainly a long term maintainability cost to keep in mind when estimating the cost for making your site gracefully degrading. I found it to be very tempting to compromise on the JS enabled UX.. Commented Feb 10, 2011 at 7:40
  • 1
    @maaartinus, obtrusive javascript is the opposite of unobtrusive javascript en.wikipedia.org/wiki/Unobtrusive_JavaScript
    – Petah
    Commented Feb 11, 2011 at 4:37
  • 1
    OK, so I can only say... html+js is a plague (broken implementations ignoring strange standards) and I'd minimize the effort just as Thomas Stock wrote. Try to make it work perfect in the chosen browser (and don't choose IE6 :D) a and to be bearable in others. Instead of working around all problems spend your time on functionality.
    – maaartinus
    Commented Feb 11, 2011 at 5:33

Something no one else has brought up as yet…

99% of Web sites welcome a particular visitor, one with little to no JavaScript. That visitor has a name: Googlebot.

A big reason everyone should care about blind visitors, as well…

If you're one of the very few who doesn't care at all about search engine traffic, well, that's your prerogative—but it certainly doesn't make for a general rule.

  • 4
    Indeed. We improved one of our sites to make it more accessible to the blind and as an (unintended) consequence the traffic we got from Google multiplied by nearly a factor of 10 in one year.
    – Kris
    Commented Feb 8, 2011 at 12:26
  • 1
    Yea, but the website is not for the public. So search rankings do not apply.
    – Petah
    Commented Feb 9, 2011 at 9:36
  • 3
    @Petah: Have you considered stating clearly and succinctly what your precise requirements, situations and restrictions are in the question rather than peppering little snippets of information here and there in comments? Commented Feb 12, 2011 at 5:45
  • 1
    You're no more right. Since quite some time, Googlebot runs javascript well (no surprise, given that Google works both on the V8 engine and angularjs).
    – maaartinus
    Commented Dec 16, 2016 at 0:16

People writing things for specific internal environments are a big reason why IE6 is still around.

Think about it


If you're doing a JS only site (perhaps 'application' in this case is a better word) the so called 'unobtrusiveness' of JS does not matter all that much as in the case, when you need to degrade gracefully to non-JS version.

However: JavaScript written in an unobtrusive way is in general easier to write (and least I find it this way) and maintain. It's easier to introduce changes to HTML layout that do not break JS, and changes onto JS without worrying about breaking HTML.


If you are building a web site I would keep JavaScript unobtrusive. However, if you are building some form of an application (like Google Docs) then JavaScript will be quite obtrusive.

JavaScript and HTML5 is great for building applications if that is your need, but it really is a business choice.

  • Yes it is more like Google docs than a website. And we use HTML5 heavily.
    – Petah
    Commented Feb 9, 2011 at 9:39
  • Correct me if I'm wrong, but I think you can still utilize most of the concepts in Unobtrusive JavaScript without necessarily creating a mess in the code? That is the concept that stands out and makes the most noise for me. Perhaps you're referring to some other aspects of Unobtrusive JavaScript that you would need to avoid by using HTML5, such as backwards compatibility with non-JavaScript users? You do have to pick and choose what's best for you & the project, as long as you can intelligently justify reasons and analyze risk, then I think it's all good :) +1
    – jmort253
    Commented Feb 13, 2011 at 0:16
  • What I am talking about is how will the site function if Javascript is turned off. There are some times where it will be fully functional (if maybe not as nice) and others where it will fail completely. I am not worried about old browsers that do not support JavaScript (Netscape 1). Of course in any case there is no reason to write BAD javascript
    – Zachary K
    Commented Apr 29, 2013 at 6:45

The majority of users (my users, I don't know about your users) have JavaScript available and enabled. Let's give those users a great user experience. However, you still need to provide a version of your site that works without Javascript. I know it's a hassle to build 2 versions, but that is the way it goes in web development. (In reality you may have to build multiple versions, a third might be a mobile version of your site).

What you don't want to do is design for the least common denominator: "Well, there are some users who have Javascript disabled so we are going to design our site to work well for them -- no Javascript, hit the server for everything." This just penalizes the majority of your users who do have Javascript.

  • What I'm saying is none of users have JavaScript disabled. If they do, they cant access the site.
    – Petah
    Commented Jan 29, 2011 at 12:39
  • @Petah, well, that's not great either. You don't want to bounce users without Javascript. So is what you're asking then, since I am kicking out the users without Javascript, is can I put the JS in the same file with my HTML?
    – Marcie
    Commented Jan 29, 2011 at 12:44
  • We have a very slim target audience, and we can tell our target audience what browser and plugins/functionality they are required to have. So you my question is, is mixing JS and HTML alright in that case. Like using onclick attributes.
    – Petah
    Commented Jan 29, 2011 at 12:49
  • 4
    @Petah, there are other reasons to avoid mixing JS and HTML. It's the same reasons we avoid mixing styles and HTML -- separation of concerns. If your style is mixed with your structure, which is mixed with your behavior, you have something very difficult to maintain. After doing it the "unobtrusive" way for a while, you'll see how elegant your files are, and how much easier it is to make changes.
    – Marcie
    Commented Jan 29, 2011 at 14:21
  • 2
    @Petah, do you have one enormous JS file for your whole site, and everything goes in there? I have roughly one JS file per page, and that works well for me. Truly "common" stuff is all that goes in the shared JS file.
    – Marcie
    Commented Jan 31, 2011 at 13:00

You mentioned using onlick attributes. Are you planning on using a JavaScript event handler for page navigation?

I would recommend against this for a single reason: it breaks middle clicking.

For regular link clicking, assuming JavaScript is enabled, these will be functionally equivalent:

<a href="#" onclick="window.location = 'myPage.htm';">Click here</a>
<a href="myPage.htm">Click here</a>

If you try to middle click the first example, you'll get a blank page rather than myPage.htm.

Apart from this example, I think it's ok to use obtrusive JavaScript if it makes business sense for you. It takes less time to write (but not necessarily maintain) inline JavaScript, and the loss of progressive enhancement might not be important in your situation.

  • In this case its not for navigation, it for buttons like 'Refresh', 'Delete', 'Create', etc
    – Petah
    Commented Feb 7, 2011 at 4:08
  • In that case, I'd suggest it's personal style. I find the obtrusive method quicker/easier to get started, but the 'correct' way to be cleaner and easier to maintain. There's definitely a fuzzy-feel-good factor in doing the right way.
    – GavinH
    Commented Feb 7, 2011 at 4:20
  • +1 - It's easier to keep the code clean from the start if it's unobtrusive. I find that if I get too messy in the beginning, it can be too tough to try to fix the problems later. I get overwhelmed. I prefer to do as good of a job as I can so that when I go back, it's not so bad to refactor.
    – jmort253
    Commented Feb 13, 2011 at 7:31

Obtrusive JavaScript was okay 10 years ago. It's also okay if you're an amateur, or if you're building a throw-away prototype, or if there is some circumstance that necessitates it, such as dependency on legacy code or data-driven code and it would just plain cost way too much to fix al

If you're building something from the ground up, follow the standards, write good, clean, maintainable code. Write something that you'll be proud of and that won't make you sick a year from now when some poor schmuck asks you for help because they don't understand a hackjob you did. Write something that ensures that your web designers can easily swap out CSS without having to dig their way through messy HTML and JavaScript.

Build the application so that it has room to grow, so that any developer can come in and maintain it. The time invested now will save time in the future, if not your time, someone else's.

Make sure that the JavaScript can be reused in another context. Make sure that a complete website redesign can be just that, a redesign, and not a complete rebuilding of something that already exists but just wasn't built tough.

Imagine how embarassing it would be to have to spend the same amount of time on a redesign as it did to build it originally.

Trust me from experience, Unobtrusive JavaScript will prevent you from making some costly mistakes.


Alright, just call me the crypt keeper on all the necro I do but I have never felt the true value of this has been properly understood. Historically, it has been asserted that "unobtrusive JavaScript" or, keeping your JS out of the HTML via inline HTML event handler attributes and script tags that didn't link to a file as much as possible is a huge key element of:

  • Accessibility concerns
  • SEO
  • And progressive enhancement

LIES! (well, now they would be)

The truth of the matter is, you could do technically obtrusive JavaScript and still pull the above three items off. Unless you were building HTML content dynamically which was a big SEO no-no in the day.

But Stop and Think... About YOU!

Really, the big benefit, the major and most undersold win of maintaining separation has always been the direct benefit the developer gets out of it. You can have as many event handlers as you want on the same html element for the same event as is convenient. That means if a tag with class="some_class" always gets a certain behavior but also gets some bonus behavior when it's inside an id="bonus_behavior" div, we don't have to start messing with logic inside our one-allowed event handler to branch for that. We can just add or not add handlers depending on context.

Easy to Read Too

Another benefit is legibility. This was a more critical concern when browser tools consisted of IE's exclusive error message telling you that there was something wrong with [object] but IMO, it's still a big deal. CSS here, JS there and HTML is the place where both they and the server meet. With all of those things coming together in one place it makes sense to rely on the hooks (the IDs, classes, and hierarchy) to create a layer of abstraction that everything uses to connect to the HTML.

IMO, the more you CAN keep your HTML, CSS, and JS separated the easier it is to not just read but also to modify and understand what's going on. I see an empty div with "dynamic_combo_box" as a class and I have a good idea something is doing a fancy select that loads data in dynamically. I have a lead on how to find that in the JS and the CSS and if I run into the class in those concerns, I'll have a good idea what it's about and how to find it in the HTML.

Too Easy to Make Even Sloppier

And of course legibility tends to go hand in hand with maintainability. When you just do things directly by dumping it all in script tags where the relevant HTML happens to be, as often as not, it becomes easier for people to just cut and paste that script in the HTML of another page they're working on when they want similar functionality which means you now have one thing that will most likely eventually become two annoyingly similar but not 100% alike things whose behavior may become problematic over time by defying expectations and require the addition of more pointless branching to handle exceptions one needs that another didn't.

So rigging behavior to those HTML hooks encourages code re-use in a smart way. If you need to branch behavior for an alternate implementation, you just go to the same function and handle it there with HTML hierarchy or maybe a data-att triggering some alt-behavior. It's one stop-shopping for anybody wanting to understand how UI elements of a certain type work and those despicably lazy-in-a-bad-way cut & paste types will do the right/more-maintainable thing just because it's the easiest thing to do now and that's the best way to make maintainability happen. Make it the easiest "duh" thing to do even for somebody who couldn't care less whether due to panic or apathy.

But What About 2014?

It may be a legit point that in modern single-page applications, some of these stickler things maybe shouldn't be stuckled to as dogmatically as they have been but believe me when I say I don't think I'm the only one who was sold on it because it ultimately makes the work easier. I'm lazy in a (I hope) mostly-good-way. I like it when I only have to change things in one place to get changes all over an app, when I only have to look in one place to figure out what the bug is, and when I have an easy time understanding what the heck is going on and how to best re-use that code to do something very similar.

It's good like splitting out a DB or data-layer is good. It's ultimately a why-didn't-I-just-do-that time-saver like taking all of five minutes to do the laundry the night before rather than spending 10 minutes on febreezing your boxers and conducting paranoid smell checks the next morning.

For me, it is those selfish motivations that have always been the main point of why I hold on to not just unobtrusive JS but the separation of style/behavior/content concerns as much as possible even as WHAT-freaking-WG does their damnedest to muddle those concerns in understandably awesome and cool/handy ways.

Now that everybody's doing SPAs and it's almost silly trying to convince business that we should care about people who run without JS (accessibility can now be, supposedly, handled with JS-generated content), it seems like the next generation of JS devs care less about this but IMO, there is still a win there and it's mostly for you, the developer writing and maintaining this stuff. And really, that win should have always been the most underscored point but never has been for some reason because it ultimately benefits you and also the product by happy accident through virtue of being easier tweak/modify/debug.

Is it Ever Okay?

Well yeah, I guess. In a disposable throw-away app for a contest or something maybe. But I would still do it just because I'm in the habit of it and it's not actually harder to do.


If you know your target operating environment Javascript and frameworks like jQuery can be a real godsend. For instance in an Enterprise environment where the SOE has Javascript and IE8 than its more than safe to write intensive client side browser applications.


Making graceful degradation easier is only one of the many factors which make unobtrusive JavaScript an attractive choice, and in my opinion, it is not the most important one.

From personal experience, I would say that if you are talking about a bigger project, one that will likely evolve a lot over time, then using unobtrusive style will make the application a LOT easier to maintain, debug and refactor. This is the biggest reason why we always use unobtrusive style, even on sites that demand JavaScript to be enabled for all visitors.

  • +1 to Shang for this gem "Making graceful degradation easier is only one of the many factors which make unobtrusive JavaScript an attractive choice, and in my opinion, it is not the most important one." Implementation of Javascript can be a double edged sword at times, I have found personally
    – MattyD
    Commented Feb 8, 2011 at 9:06

In general, if you are developing a traditional "web site" that is anonymously available, indexed by search engines, and where revenue is generated by ads, then you should provide graceful degradation. The idea being that this sort of site lives and dies by accessibility so limiting accessibility means losing a ton of page views and thus ad revenue.

A restricted access, generally non-indexable and non-ad-revenue-based "site" (web application) can be a lot more flexible. It comes down to a decision between breadth of support, depth of features, and development cost. Think of it like developing a traditional application: what platform do you support and what are the minimum specifications? If you target just one platform and limited specifications you can concentrate on providing a superior product with less development and support costs, at the cost of lost potential market share.

Example: Google Search is a web site. Google Docs is a web application. Google Search is no frills and can function identically without JavaScript, CSS, and/or images, etc... - it works in text mode browsers just as well as it does in the latest GUI browsers. Google Docs simply doesn't work with JavaScript disabled and it doesn't even degrade gracefully - not even a warning to enable JavaScript.


I prefer to have most layout and navigation handled in CSS. Yes, Lynx might not support it, but all full featured browsers that I am aware of can't turn it off. Then JavaScript can be used for more flashy but not required things. I also like Ruby on Rails for this purpose. It can do a lot of what JavaScript would be required to do server side as long as you don't need dynamic page updates.

More targeted to the answer of the question: I don't LIKE required JavaScript, but there is a business case where it is required as ChrisF noted.


Javascript is the defecto standard when it comes to any sort of dynamic content delivered client side, if they don't have JS then they probably won't have silverlight.

Then you have to think about your market/audience are you programmers.stackexchcange or bbc.co.uk/news ? very different audiences.


Since you can look around the web and see "obtrusive javascript" on many sites, your basic question is answered, yes, it is ok, and many popular sites do it, even Google.

More important however, is graceful degradation of functionality, even though you insist that your users should have Javascript enabled, you must provide a decent level of experience for non-js users, or they will never willingly return.

  • They will never even be allowed past the first page in the first place.
    – Petah
    Commented Feb 9, 2011 at 9:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.