Tuesday, November 4th, 2008

Weed Out Obtrusive JavaScript

Category: JavaScript, Testing, Unobtrusive JS

By now, most developers have (or should have) come to realize how important it is to build unobtrusive JavaScript code. Apart from ensuring a better user experience, today’s tools and libraries make it extremely easier to embrace this practice.

Continuing down the path of providing developers good tools, Robert Nyman of DOMAssistant fame has updated his Obtrusive JavaScript Checker. The tool comes in a couple of different forms including a GreaseMonkey script, a Firefox add-on and newly included, a command for use with Mozilla’s Ubiquity Firefox add-on.

One common and tedious task when improving code is to find inline events in the HTML code, and make sure they are implemented in an unobtrusive fashion instead (more about unobtrusive JavaScript). The web is riddled with inline events, and I strive to make it a better place. :-)

The Obtrusive JavaScript Checker tool traverses through all elements in a web page, and when it finds a HTML element with inline events, it highlights it with a red border. The newest release now offers support for “javascript:” links as well as much greater detail about the element when you hover over it. In addition, a new report summarizes the number of javascript: links and inline events in the current web page as well as the number of occurrences of each type of inline event.

Link to Robert’s updated Firefox add-on: https://addons.mozilla.org/en-US/firefox/addon/9505

Posted by Rey Bango at 11:52 am

3.1 rating from 16 votes


Comments feed TrackBack URI

How does unobtrusive javascript ensure “a better user experience”?

The end user sees no difference between obtrusive and unobtrusive Javascript. The positive difference is for the developer.

Comment by xutopia — November 4, 2008

I believe “unobtrusive” simply means that, when Javascript is disabled, the site still works, as Javascript is not a requirement.

Comment by Liquidrums — November 4, 2008

Is it really true that most developers realise the importance of unobtrusive javascript coding? Why should a 2008 web application try to serve people that do not use javascript?

It is not that easy to produce a web application that works user friendly without javascript. I think it is not worth the effort for this very small percentage of people that have javascript disabled.

Comment by daanlib — November 4, 2008

I don’t know about everyone else (@daanlib, @xutopia) – but I don’t generally browse sites with javascript enabled on my Blackberry….I greatly appreciate sites that still work when javascript is disabled.

I would argue that 2008 web applications, even more so that 2000-2003 web applications, MUST be unobtrusive (ie work without javascript enabled) – as there are many many more user agents out there browsing which may or may not have a javascript engine that works, is scalable, or reliable.

Comment by toonetown — November 4, 2008

Dreamweaver CS4 has a build in function that externalizes javascript. (adds id’s to the elements, and than assigns the listeners)

Great stuff

Comment by V1 — November 4, 2008


I’m Robert, the developer of Obtrusive JavaScript Checker.
First, let me tell you that the Firefox add-on is a bit crude at the moment. In the future, I hope to make it better with some options.

Currently, I’d recommend the Greasemonkey script, which offers enabling/disabling of the functionality with a single click, and also the option to customize for which domains it should be run.

Also, the Ubiquity command works well, since it doesn’t run until it’s actually summoned.

Second, in regards to what unobtrusive JavaScript really is. To me, naturally it’s about making web sites work initially work without JavaScript, and then progressively enhance it with JavaScript – this is both for accessibility as well as SEO purposes.

And besides from being better for the developer and being accessible, it’s also about offering a better user experience through for the end user. When you have no inline JavaScript events, the HTML code will be much smaller, i.e. load faster. With all JavaScript code in external JavaScript files, they will load just once, and then be cached in the end user’s web browser cache, leading to excessively faster page loading when someone navigates around your site.

Comment by robnyman — November 4, 2008

About unobtrusive javascript: It’s a simple matter of weighing the cost in time & money versus the added benefit for the small percentage that has javascript disabled.
Usually, web applications don’t fare well in this regard. They’re not called web applications for nothing; you can hardly write an application without javascript.
For relatively simple websites, the coin usually flips the other way; it shouldn’t be too hard to let the functionality (not the user experience) degrade somewhat gracefully.

Comment by DiSiLLUSiON — November 4, 2008

@daanlib It’s a rather ignorant and unprofessional view to simply ignore users without JavaScript. Firstly, in many cases it can be illegal as quite a few Assisstive Technologies (screen readers, etc) have very poor, if any, JavaScript support. And users of ATs rarely upgrade as the software is usually very expensive. Aside from the legalities of accessibility issues, ignoring non-JS users is ignoring a vast majority of handheld users (which should be a priority target for any useful mobile app). You would also be ignoring entire companies whose security restrictions rely on disabling JS and using browser plugins such as NoScript. Additionally, ignore non-JS and you’ve just shut off nearly every single search engine spider and data indexer in use today!

Anyone who simply says those users can be ignored because it’s ‘too hard’ is clearly not a web professional. Web Amateur is a more apt title.

Comment by posaune — November 4, 2008

(@posaune) I think there is a difference between web applications and ‘simple’ websites. As said above bij DiDiLLUSiOn, web applications are almost impossible to write without any javascript. For simple websites it is not to hard to make them meaningfull and functional by gracefull degradation. I also think ‘simple’ websites are the ones visited by users of ATs.
Web applications on the other hand often rely on drag&drop windows etc. I do not think the fact that it is hard should be an excuse for excluding people from your application. However, my time and money are limited, so if I have to choose between creating a great user experience for the vast majority of the users or creating a crippled, but functional ‘gracefully degraded’ user experience for a small percentage of the users, I personally would rather exclude those users.
Nevertheless I think that the application should be meaningful (not functional) without javascript available, so people know the reason for the app not working and for SEO purposes.
Last, I would like to comment to your ‘Web Amateur’ statement: I am not a professional (although I have made some proffesional websites and applications, I am a student in an non IT subject), but weren’t you all amateurs once? I think it is not necessary to call me ‘ignorant and unprofessional’.
Greets daanlib (please excuse me for my english, I’m not a native speaker)

Comment by daanlib — November 4, 2008

I have a web application which is a real application. It’s processor intensive. In my case, I pretty much have to serve up a seperate page if the user can’t use the application.
How should I determine if a cell phone or some other device has a lame JavaScript implementation?

Comment by Nosredna — November 4, 2008

I agree it’s not necessary to call daanlib name like that. Daanlib does have a valid point, and both you and toonetown offers valid counter-points, except toonetown didn’t call name like you did. I turned off JavaScript, visited some of the sites listed in your portfolio, and they don’t work and don’t degrade gracefully. Ajaxian registration also does not work with JavaScript turned off.

Comment by khnle — November 4, 2008

@Liquidrums – some developers do not have a choice and need to develop for all parties under 508 compliance. Your site maybe only be developed for a very targeted market, but doesn’t mean all others are. Think of government sites and the like.

Comment by geeves — November 4, 2008

sorry, that should have been @daanlib. I’ll never get used to usernames showing up after the comment.

Comment by geeves — November 4, 2008

If it’s a website, it should and can work without javascripting.
If it’s a webapp, it’s a bit like building a car for those who hasn’t any petrol.

Comment by Mikael Bergkvist — November 5, 2008

The practice I use in building web apps is the same that google uses for gmail:
– The primary web interface uses javascript and advanced browser features obtrusively and extensively.
– There are secondary interfaces targetted at non-javascript and mobile users.
The advantage of this model is that you don’t have to handicap either of the interfaces to accomodate the other one. My mobile interface’s gui is completely separate from the normal interface, so it has a completely different application organization and page structure.

Comment by Joeri — November 5, 2008

yeah, that’s the only stance that makes any sense at all to me. They can either run the full deal or they can’t. It seems obvious.

Comment by Nosredna — November 5, 2008

Leave a comment

You must be logged in to post a comment.