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.

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

Posted on January 29, 2007 in Accessibility, JavaScript

Comments

  1. 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. 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?

    Servus.

  3. 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.

    Unfortunately, at least in my case, it seems to be more like “when uneducated clients and clueless supervisors enter the room…”

    How do you convince somebody that something is or is not a good idea when other sites that use “best” practices seem to be doing perfectly fine.

    Maybe I’m working for the wrong company, but more often than not a “best” practice is simply what the competitors are doing and what is immediately visible when viewing the page in out-of-the-box IE6.

  4. I feel like maybe this article is titled to get added ‘shock traffic.’ Your ideas are (as always) right on, but it seems like you spend a lot of time explaining how you really aren’t against libraries and how people shouldn’t flame you, and I think a lot of that is because of the title that you chose.

    Perhaps something less flashy like “Using JavaScript Libraries Responsibly” might work better; you could focus on how to avoid the pitfalls that many library users end up in, rather than defending yourself against potential flames. If you’re writing the article to clear up your position on libraries, starting out with a negative title is asking for arguments.

    Title aside, your thoughts are appreciated and I agree with you.

  5. Scott has a point. However, the title will get this article some well deserved attention. Hopefully the attention won’t be coming from people just reading the first paragraph before they go nuts with what sets things ablaze. ;)

  6. Roger you’re right, I keep meaning to grab one of these libraries, give it some of the unobtrusive treatment (or progressive enhancement if you prefer) then release it back to the community, someone needs to.

    That won’t help with the lack of learning but I think that really won’t change in the near future there are too many “do X without knowing any HTML or [insert code name here]” products to stop that but at least the code would be better

  7. January 29, 2007 by Roger Johansson (Author comment)

    Scott: You do have a point about the title. I’ve changed it several times, and ended up with this. That is not why I keep mentioning that I am not against libraries though - it is because my experience is that I have to be very, very clear or people will misinterpret me, sometimes intentionally.

  8. 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?

    Servus.

    Maybe stick to the German, Stanislav :)

  9. January 29, 2007 by State of the art

    The problem is that the browser is becoming more interactive with every month that goes by. Check out news.google.com, its page source code, and notice the embedded javascript in there! Now ask yourself if you would write javascript like that! Now ask yourself how come Google is crazy in writing it like that! Lastly, Google has millions of users, and the javascript Google puts out needs to work for everybody, in as many browsers as possible.

    Yahoo seems to be using a lot of javascript tricks where in the past you would find only HTML. And Yahoo has millions of users as well.

    And above all, Google and Yahoo means lots of applications that need to share common code! So they both have their javascript libraries.

    That is, the time of amateur javascript programming is about to end. Now OOP/libraries will become more and more mainstream in javascript.

  10. January 29, 2007 by Isofarro

    “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.”

    How so? Looking at the code “examples” shows a lack of understanding of JavaScript. Just how many times do you want to be doing a wrapper around an id string until you do it once and store the reference?

    Also, the code there offers no clue as to how accessibility is meant to be handled. The code snippet shows a mere onclick event - what, is that the only event it can register, or can it do mouseover?

    Where are the code examples? Where’s the demonstration that they can be used and still be accessible? Sorry, an API list of methods is not a replacement for working examples.

    The lack of documentation and examples is insulting. Also, your handwaving about insisting on JavaScript being accessible is the root of your problem. You can say it as often as you like, but without concrete examples, its just verbal masturbation and pixie dust - hardly the useful information web developers need to develop accessible websites. But then, that no longer surprises me.

  11. Who should we trust? I had a conversation with a client today were we spoke about flash/javascript and what happens if you don’t have it turned on. Later on we checked gucci.com (which is made by the guys behind the popular js lib script.aculo.us) and it was not a nice visit with javascript turned off.

  12. January 29, 2007 by Daniel

    I do agree wholeheartedly with your statements and opinions Roger.

    I would like to point out that the mootools framework allows for accessible, cross-browser support most of the time (educating yourself on the library limitations is the developers job). But what I really like about mootools is the ability to download only the necessary components for the functionality (aka bling) you desire. Including the multiple options for compressing the JavaScript even further.

    It’s a step in the right direction.

  13. January 29, 2007 by Thijs

    I agree on Daniel and Mootools. I’m implementing mootools in a webshop, my job is to keep the shop up an functioning with javascript turned off and add some visial stuff.

    Nice example: Hyves.nl(no spam just example), a dutch online social network with a few million members. The site loads an incredible total of 250kb on javascript files and is not accessible with js turned off. So yes some people won’t be able to see/use the site. Point is; who of the clients will care because there are so many visitors that proof it does work for the majority.

    And that is where we should somehow try to change that way of thinking.

  14. I agree with all of you, but we should consider one, very important thing. Frameworks and IDE are becoming very popular nowadays. It is much easier and faster to create things using them. Thanks to that we have Content Management Systems and so on.. What I think is in a few years there will be two groups of software developers: -> software engineers -> implementation specialists. First group will be responsible for creating ACCESSIBLE frameworks and the second group will implement all solutions in a proper way. So we should do our best to take care about accessibility and standards of frameworks and libraries, however we should not say NO. It’s an evolution..

  15. I don’t mind requiring JavaScript for a site to work more fully, but there should be at least some functionality without JavaScript. The gucci.com not only will not work at all without JavaScript, the first page is blank without it, even though a view page source reveals data. Then if you turn on JavaScript it resizes your browser which is a strict no-no for me.

    Roger,

    How do you define a library? I have a series of functions that I use on almost every project. DOMContentLoaded, trim, addClass, removeClass, hasClass, getElementsByClassName… I include these in a util.js file.

    Is this a library?

  16. Isofarro,

    Frankly, I’m not too keen about comments by people who seem to make it a rule to write slightly disrespectful and provoking comments… Anyway, I will still show you the respect of briefly answering your questions/statements.

    Just how many times do you want to be doing a wrapper around an id string until you do it once and store the reference?

    Not sure why you wouldn’t store the reference. The examples simply shows how to create the reference, not how you will use it for the rest of the day.

    The code snippet shows a mere onclick event - what, is that the only event it can register, or can it do mouseover?

    Maybe, just maybe, it’s obvious to people that it supports all the events offered by web browsers…

    The lack of documentation and examples is insulting.

    I’m sorry if you feel that way. Besides the fact that you and I don’t use/value the term “insulting” the same way, I’m pretty convinced that the documentation will be sufficient for people using it. When it comes to examples, I can agree that they’re sparse, although it really isn’t rocket science.

    But this library isn’t for beginners; just like Roger, I think that you should have a good knowledge of JavaScript and accessing the DOM before starting to use libraries. And if you have, I’m sure you will understand how DOMAss works and how it will help you.

  17. January 30, 2007 by Carlton

    I think it definitely pays to learn Javascript before using one of the libraries and understanding how the DOM works is essential too. I found that the use of a library increased my productivity quite a bit as I didn’t have to worry about browser inconsistencies but I am now well aware that they exist. I’m against using these libraries for the effects and animations but they (well I suppose I only use Yahoo’s YUI library) are excellent in coping with browser inconsistencies, these inconsistencies being the bane of my life!

  18. wow, thx for that posting, I think that your approach and your concerns about using frameworks should make every javascript developer think before doing ;)

  19. If you’re not against javascript libraries, surely a more successful approach would be to encourage responsible application through examples of unobtrusive and accessible enhancement, rather than preach total abstinence until a thorough understanding of the base language is acquired?

    Isn’t that what you’ve been doing at 456 for the last few years with regard to accessible and semantic HTML?

  20. January 30, 2007 by Renato Targa

    I’m not an early adopter and I’m always a bit skeptical when the latest “cool thing” emerge. But I saw a real benefit when I introduced a javascript library in my team workflow a couple of months ago.

    Fortunately we have two developer teams that work with web applications: a group of server-side programmers (they stay away from javascript) and a bunch of guys who primarily work on client-side development and are very well versed in web standards, accessibility, javascript and DOM.

    And, of course, we do have a QA department who helps us to test when the javascript is not available.

    Unfortunately, at least in my case, it seems to be more like “when uneducated clients and clueless supervisors enter the room…”

    This is what I like to joke: sometimes, we create BCD (Board Centered Design) instead of UCD applications. Which is not always a bad thing: if your company have great leaders, sometimes they can foresee amazing things your users can’t.

  21. You have hit the nail on the head. I see many websites with several different JS libraries attached (bloated), all so they can get a blind down effect or a yellow fade effect - and that’s it. Wouldn’t it be much simpler to create a smaller library to fit your needs?

    I guess this is what bothers me with many different frameworks. They are nice, but they try and do everything for everyone (I have run into the same thing with PHP frameworks). Not that it’s bad, but I prefer to learn the languages and build according to my needs, not throw a bunch of frameworks together and see what comes out.

    It is important to know the language and know why you are doing what you are doing. This will help you when you want to extend something, or when you need to troubleshoot something.

    Ultimately, it will help you to see that you don’t always need the 50k+ library to achieve your tasks. I like to keep things simple, and this has nothing to do with the frameworks being bad - as you said - it is simply in the implementation by people who don’t know what they are doing (they just want the ‘wow’ effect).

    I see many similarities to the DHTML times as well, and the poor examples coat the web for the new Javascript libraries just like they did with DHTML. No matter what - people will copy/paste and try and get it to work exactly, even if you tell them it isn’t production ready.

    This is a topic I could discuss for a long time…so I will leave it at that - excellent post Roger.

  22. January 30, 2007 by Isofarro

    Robert Nyman: “Maybe, just maybe, it’s obvious to people that it supports all the events offered by web browsers…”

    So, in terms of web accessibility, it does nothing more and nothing less than all the other JavaScript libraries out there.

    Again, Roger Johannson’s biggest objection isn’t met:

    “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.”

    Your library still meets none of these requirements (perhaps there’s important information that’s not being presented?), and its also unclear why Roger Johansson feels either your library meets them or justifies sweeping them under a carpet.

    Why is this blog entry reading less and less like a web accessibility aware piece, and more and more like a sales pitch/shill?

  23. Roger’s argument points directly to a business opportunity: a Javascript library that features compliant, progressive, well-written code.

  24. Andrew W wrote:

    Roger’s argument points directly to a business opportunity: a Javascript library that features compliant, progressive, well-written code.

    It has already been done: jQuery

    Granted, with any library, just as with plain JavaScript, the individual “scripter” has the freedom to use it in heinous ways for which it wasn’t intended. But as far as libraries making it dead easy to write unobtrusive, accessible code goes, jQuery is it.

  25. January 30, 2007 by Roger Johansson (Author comment)

    Tanny:

    How do you define a library?

    Not sure, to be honest. A collection of functions that exist in the same file? A collection of functions that depend on each other? A set of functions that use a special syntax? Maybe somebody else knows of a definition.

    Steve:

    If you’re not against javascript libraries, surely a more successful approach would be to encourage responsible application through examples of unobtrusive and accessible enhancement, rather than preach total abstinence until a thorough understanding of the base language is acquired?

    Yes, you are correct. I picked a bad title for this post.

    Isofarro:

    So, in terms of web accessibility, it does nothing more and nothing less than all the other JavaScript libraries out there.

    The way I see it, using JavaScript in an accessible way is the responsibility of the developer. The responsibility of library developers is to avoid creating inaccessible and obtrusive demos. But no, Robert’s library doesn’t provide anything accessibility specific and is no more or less accessible than any other library, and I don’t see anyone here claiming the opposite.

  26. Every time some sort of barrier-to-entry is lowered, the horde rushes in, eager to play with their new toy, until an esteemed voice warns them that they don’t fully appreciate the correlated risks. Proceed with caution!

    Of course, you’re completely correct, Roger, and I agree with nearly everything you said above. But there are developers who care about accessibility and developers who do not. JavaScript libraries won’t magically turn the former into the latter.

    I also understand what you’re saying about “badly-written” demos, but it’s much easier to illustrate exactly what your library does when you do the sort of things that makes actual scripters cringe: using inline event attributes in your HTML, neglecting to provide a fallback, etc. I don’t know which side I’m on here, but I’m not sure if it’s worth it to change three lines from an HTML file into thirteen lines spanning multiple files just so you can accommodate the cargo-cultists. Good coders know the demos are just shorthand; bad coders aren’t going to have their habits changed by a demo anyway.

  27. Isofarro,

    I don’t see me, nor Roger in his post, selling my library as more or less accessible than any other library. It is unobtrusive, and then accessibility comes down to implementation.

    If you read the post more closely, the context it is mentioned in is regarding file size and complexity, not accessibility. From what I can see, the post isn’t solely about JavaScript libraries and their respective accessibility, it’s about other things as well, such as who uses libraries, different shortcomings of them and so on.

    So, please, read more carefully before jumping the gun.

  28. January 30, 2007 by icaaq

    I’m with Karl, I’ve been looking at JQuery for a while now and it’s just what i need for the times when i use JavaScript. But of course I only use it to enhance the experience on a web page!

    Cheers.

  29. In a tutorial I wrote for jQuery, for an expandable menu, without JavaScript enabled it would simply display the menu fully expanded. Furthermore, you can control the menu using the keyboard (namely using TAB and ENTER).

    JQuery makes it harder to do the wrong thing than it is to do the right.

  30. I can’t agree with this article. A developer/designer who does practice progressive enhancement can still use a JS library to write human-readable, efficient, reliable script that enhances the web app/site.

    Why learn JS in and out, when I can use a framework that builds on my existing knowledge of DOM, CSS selectors, and XSL?

    I personally use jQuery because it’s lightweight, powerful, efficient, documented, and has a huge community support, etc.

    Drupal, which is usually my CMS of choice and what I start most site/apps with is now integrated with jQuery. Both projects are perfect examples of Open Source done right.

  31. Hearing all this talk about JavaScript being unsure and possibly unreliable – “You cannot rely on JavaScript being available. Period.” reminds me of conversations about using CSS to format text and position page elements. Back then the reasoning was that browsers did not support CSS equally and that using CSS would not be consistent or reliable enough to be taken seriously… Obviously, that has changed! JavaScript and AJAX will no doubt force the same type of evolution. JavaScript now, like CSS then, has been around for quite a while, just now, with AJAX it’s been pushed to the front burner. Right now, you should proceed with caution, but you should proceed. To demand that JavaScript/AJAX and Framework libraries be accessible and universally supported before you consider using them is counter productive. Face it, for the average, small to mid size web site, web standards and accessibility take a back seat to fast turn around, client budget, and client needs. If a client needs an image gallery, has a small budget, and doesn’t exist in an industry that requires accessibility, then the Adobe Spry Image Gallery is a good option! Later, when the technology evolves and browsers have better support, then update the client’s site. By then it will probably need it anyway. Sometimes you have to choose quick-to-market and serving the immediate needs of the client and the majority of users over idealism. Academic discussions about the “absolute correct” way to do things seldom pay the bills, unless you get paid to write articles rather than develop sites for real–world clients.

  32. Lawrence Cramer:

    Back then the reasoning was that browsers did not support CSS equally and that using CSS would not be consistent or reliable enough to be taken seriously… Obviously, that has changed!

    Your comparison of Javascript to CSS is apt, so I encourage you to also compare the attitude of the standards-based community in regards to CSS based layout.

    In particular, it is now understood that a well-designed site that relies heavily on CSS for its presentation, will still be usable with CSS unavailable.

    Which is to say, we implement CSS with the (cautious) expectation that it will be rendered properly by modern browsers, but we also construct our documents with semantic markup and appropriate source order, just in case.

    The same principle has to be applied to Javascript, which is why Roger is such a strong advocate of progressive enhancement. When he says “you cannot rely on Javascript being available,” the key word is rely. You can reasonably expect that it will be there in most instances, but if your code completely fails when JS isn’t there, you’re unnecessarily leaving out a certain bloc of users.

  33. February 1, 2007 by Roger Johansson (Author comment)

    Thanks Cris, I couldn’t have said it better myself.

  34. I think you make a good point Roger… before using any language library one should spend some time getting a handle on the underlying language. One issue is we all want to call ourselves programmers without taking the time to study the underlying principles involved. So right out of the box I think you’re entirely right on that score.

    How could anyone say you shouldn’t spend time learning JavaScript if you’re going to use it in development? Now that would be both unreasonable and lazy.

    I see a lot of side issues here but really the basic premise is sound. Learn HTML before playing with WYSIWYG, learn JavaScript before playing with JS Libraries - sames the same.

    OK maybe its fine to experiment with libraries but when it comes to serious development then I can’t see how anyone could defend the view you don’t need to learn how the technology works. Don’t listen to the detractors. The right tool for the right job used correctly…

  35. February 5, 2007 by albannach

    Thijs, when you say ‘Point is; who of the clients will care because there are so many visitors that proof it does work for the majority.’

    are you missing the whole point about Accessibility. If some people cannot access the site, it is not accessible, especialy if some have disabilities.

    Do you know how many people were put off by the javascript? Was if another few million, a mere few hundred thousand or a piffling few tens of thousands?

  36. I think you should rename this article “learn good javascript practices before tasting the library kool-aid”.

    the main reason for using javascript libraries is cross-browser compatibilty so you don’t have to pull your hair out wondering if the stuff you cobbled together works on more than one browser, the library creators do that.

    but good code and standards practices are good code and standards practices. your site should work without javascript and you should make sure your library uses good code pratices and does its best to a) not use proprietary elements and features of browsers and b) strives to be as compliant with the appropriate standards as they can make it

    thats just common sense.

  37. I couldn’t agree more. Too many people depend on libraries that leave bloated code that they have no clue how to debug or extend. DOM scripting isn’t that difficult - there’s really no excuse.

Comments are disabled for this post (read why), but if you have spotted an error or have additional info that you think should be in this post, feel free to contact me.