Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
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 Jan 29 '11 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 Jan 31 '11 at 9:45
16  
What do you mean by "obtrusive" javascript? I'm not familiar with the term. –  Macke Feb 6 '11 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 Feb 8 '11 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. –  whatsisname Feb 9 '11 at 22:54
show 3 more comments

15 Answers

up vote 17 down vote accepted
+50

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.

share|improve this answer
2  
I think you a misunderstanding me. –  Petah Jan 31 '11 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 Feb 9 '11 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.. –  Thomas Stock Feb 10 '11 at 7:40
1  
@maaartinus, obtrusive javascript is the opposite of unobtrusive javascript en.wikipedia.org/wiki/Unobtrusive_JavaScript –  Petah Feb 11 '11 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 Feb 11 '11 at 5:33
show 2 more comments

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.

share|improve this answer
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 Feb 8 '11 at 12:26
1  
Yea, but the website is not for the public. So search rankings do not apply. –  Petah Feb 9 '11 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? –  JUST MY correct OPINION Feb 12 '11 at 5:45
add comment

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

Think about it

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
Yes it is more like Google docs than a website. And we use HTML5 heavily. –  Petah Feb 9 '11 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 Feb 13 '11 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 Apr 29 '13 at 6:45
add comment

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.

share|improve this answer
    
What I'm saying is none of users have JavaScript disabled. If they do, they cant access the site. –  Petah Jan 29 '11 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 Jan 29 '11 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 Jan 29 '11 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 Jan 29 '11 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 Jan 31 '11 at 13:00
show 1 more comment

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.

share|improve this answer
    
In this case its not for navigation, it for buttons like 'Refresh', 'Delete', 'Create', etc –  Petah Feb 7 '11 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 Feb 7 '11 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 Feb 13 '11 at 7:31
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
+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 Feb 8 '11 at 9:06
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
They will never even be allowed past the first page in the first place. –  Petah Feb 9 '11 at 9:37
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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