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

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 10

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 11

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 12

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 13

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 14

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.