Jun 1, 2009

Learn JavaScript before tasting the library kool-aid

Learn JavaScript before tasting the library kool-aid

When I mentioned “Overuse of JavaScript frameworks/libraries” as one of the Six things that suck about the Web in 2006, I quickly learned that some people don’t quite agree. That’s fine, everybody has the right to their opinion. But I want to explain my thoughts and feelings about JavaScript libraries a bit more. If JavaScript libraries are religion to you, please read this article in full before you bring out your flamethrower.

These days, just about every blog or forum related to Web design or development contains a lot of talk about JavaScript libraries (frameworks, toolkits, whatever). No surprise there, considering how popular they are. However, some of those blog posts and discussions are making me a bit concerned. Not about JavaScript libraries being popular–they do have their place and can be used well–but about how they are being marketed and the way many designers and developers tend to use them.

Unfortunately, some JavaScript libraries seem created specifically to appeal to people who are easily dazzled by animations and other visual bling-bling, or people who want to “get the job done” without actually knowing how to get the job done. This can much too easily lead to bloated, inaccessible, and obtrusive scripting that is dependent on several different libraries and their add-ons, and makes teamwork more difficult and complex than it needs to be.

The JavaScript library hype is making me feel uneasy because I was there in the late 1990’s/early 2000’s when DHTML was a huge buzzword. DHTML libraries made it too easy to create annoying animations, inaccessible dropdown menus, unusable scrollbars, and other pointless and obtrusive novelties. And it looks like we are heading that way again.

Check out the demos that accompany some of the popular libraries. Do they work in all modern browsers? Are they accessible? Are they created with progressive enhancement in mind? Do they provide a reasonable alternative when JavaScript is off? The answer is no in too many cases for me to believe that library developers in general care about accessibility and progressive enhancement. Of course there are exceptions, but a lot of demos and tutorials are really not doing what they should to set good examples. To see what I mean, all you need to do is take a look at the obtrusive and inaccessible JavaScript Adobe Spry promotes.

Unfortunately it seems that when libraries or frameworks enter the room, best practices regarding usability, accessibility, and unobtrusive scripting are very easily thrown out of the window. In most cases this is not the fault of the libraries themselves, but of badly written demos (which will be copied and used as-is, no matter what you say), lack of documentation, and developers who use the libraries and their accompanying demos recklessly, without considering the consequences.

Before giving in to the JavaScript library hype, please invest some of your precious time in learning JavaScript. I really think you will feel better about yourself if you can say “I know how to program with JavaScript and can make an informed choice about which library, if any, to use” instead of just “I know enough JavaScript to use Library X to create cool animations”.

Just to be perfectly clear: I am not against JavaScript libraries. They can relieve you of repetitive programming tasks and help you with browser inconsistencies, letting you spend your time on better things. What I am against is using libraries the wrong way, like for adding gratuitous visual effects and making GUIs inaccessible, confusing, and difficult to use.

I personally don’t quite see the need to use third party JavaScript libraries, at least not any of the big ones I have taken a look at. They are too complex and do too many things for my taste. What I would prefer to use is a really minimal library that contains the essential helper functions that you need for almost every website project. Nothing more, nothing less. If it’s easily extensible, great. But it needs to be small. I don’t want to make my clients’ visitors download a 50 KB library if I’m only using 5 KB of it. Robert Nyman’s recently released DOMAss - The DOM assistant seems to fit that description. It’s only been available for a few days, so I haven’t had the time to actually use it yet, but it does look very promising.

You may disagree with some or all of what I’m saying here, or agree but feel that the benefits you get from using an oversized library make up for the disadvantages. In the end, it’s obviously your decision.

But please, whether you swear by libraries or not, make sure that all your JavaScript is accessible and unobtrusive, and remember that You cannot rely on JavaScript being available. Period.
Related reading

JavaScript libraries and their use have been discussed a lot by others, and here are a few noteworthy articles on the subject:

* Christian Heilmann: The Importance of Maintainable JavaScript
* Christian Heilmann: Dear JavaScript Library Developers…
* James Bennet: Django and AJAX
* Jeremy Keith: Learning JavaScript
* Jeremy Keith: Your own personal library
* Justin Palmer: Ajax: Killing Usability One Request at a Time
* Peter-Paul Koch: Again JavaScript libraries
* Stuart Langridge: The fog of libraries

Possibly related posts

* base2.DOM is my kind of JavaScript library
* Adobe Spry and obtrusive, inaccessible JavaScript
* DOM Assistant 2.0 released
* DOMAssistant 2.6 released

Posted on January 29, 2007 in Accessibility, JavaScript

* Previous post: Interviewed for lab:kloud9
* Next post: Designing with Web Standards, 2nd Edition (Book review)

Comments

1.
January 29, 2007 by Daniel Gr

2006 was basically 1 step forward and 2 steps back for accessibility. Because, while semantic HTML grew, poor and intrusive Javascript virtually exploded.

I hope we can take a step forward this year only and we’ll be back at 2005 levels, at least, but I doubt the web will ever be as usable as when we only had HTML 3.2, sorrily.
2.
January 29, 2007 by Stanislav Müller

What happens if somethink doesn’t work as good as you expected?
»Did you take another JS Framework?«

No

You are trying to understand what happens and why it happens isn’t so?