Is obtrusive JavaScript ever ok?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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

Think about it

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

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.

Answer 13

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.

Answer 14

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.

Answer 15

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.