Again JavaScript libraries

In the last days of last year, while I was enjoying a holiday from obtrusive RSS feeds, the JavaScript library discussion seems to have heated up once more. Here's an overview of recent thinking about JavaScript libraries. The remainder of this entry is going to concentrate on the Stuart's and Chris's articles, in that order.

Stuart Langridge: The fog of libraries

It was Stuart's piece, especially, that caused me to write this entry, partly because Stuart has changed his opinion somewhat, and partly because his entry has the best overview of the entire issue.

This is an excellent summary of my position, which is shared at least by Jeremy and, until recently, by Stuart himself; and probably by many more JavaScripters around the world. Stuart, however, calls for a re-evaluation:

I feel kind of torn. A moderate dose of elitism can be a good thing, so I don't worry about the fact that dissing JavaScript libraries may come across as elitist. In addition, I still strongly believe in knowing what you do: if you have no idea how JavaScript works, you shouldn't write JavaScript, with or without a library.

On the other hand, Stuart's theory makes excellent sense. Most JavaScript is written by nine-to-fivers who just want to get their job done. If these web developers use libraries, they help themselves, while at the same time the average JavaScript code quality on the Web goes up a bit. Their library-induced code will probably be better than the code they would produce when left to their own devices.

All this is true—in theory. Nonetheless, nine-to-fivers haven't entered the library picture yet. In order to understand why we have to turn to Chris Heilmann's article.

Chris Heilmann: Dear JavaScript Library Developers...

In his article, Chris pinpointed some problems that are shared by many (most?) current libraries. He hits various nails on their respective heads when he says that the lack of offline documentation, and unobtrusive examples, as well as problems such as excessive use of the style property or inconsistent terminology ("action" instead of "event"), holds back the adoption of libraries.

For the purpose of this article his second point is the most important one, because it contradicts Stuart's theory:

About six months ago I made a half-hearted attempt to study a few libraries, but the lack of simple examples stopped me pretty quickly. Sure, I can study the library code itself or the API documentation, but they don't give me a quick rundown on the library's strengths and weaknesses (to be fair, neither the actual code nor the API documentation is meant to do that).

True, the jQuery homepage contains a few simple examples, but they're meant to show the library's style of code, not to gently introduce newbies to the power of jQuery.

When none of the library sites offered me quick rundowns ("here's how you create an animation"), I stopped studying them, and I wouldn't be surprised if others (such as Stuart's nine-to-fivers) do the same.

Combining Stuart's theory and Chris's facts

So we have a problem here. Stuart's theory, though attractive, becomes less convincing when we take the lack of simple examples into account. If JavaScript is not your main strength, using a library to do the dirty work for you makes sense. However, if you can't figure out how the library works, either, you're back to square one. Right now it doesn't seem that Stuart's nine-to-fivers will actually benefit from libraries, unless they're pretty decent scripters to begin with, which makes their using a library less necessary (hence less likely).

In conclusion, it seems that libraries don't yet reach the audience that would benefit most from them. Then who uses libraries right now? What do the nine-to-fivers use right now? If not libraries, we can safely continue to discourage everybody but experts from using them—can't we?

Stuart's answer is that expert JavaScripters should stop repudiating libraries and start documenting them, as well as pointing out flaws in them and making them better in general. Again, fine in theory, but it presupposes a lavish amount of time to spend on something I still (quite frankly) don't want to spend too much time on.

Count me out—for the moment. I agree with Stuart's basic analysis, but I'm going to concentrate on documenting more fundamental matters such as DOM compatibility so that the library writers won't have to do it themselves.

Comments

1 Posted by Dean Edwards on 11 January 2007 | Permalink

You already answered your own question really. You are helping to improve the quality of libraries by maintaining an important resource like QuirksMode. You don't have to write documentation or test plans just carry on laying out tables of browser quirks for library authors to study.

We all help in our own way.

2 Posted by Jonathan Snook on 11 January 2007 | Permalink

I'd say they're both right. Sure the lack of documentation prevents nine-to-fivers (9-5s) from understanding the libraries at a deeper level but by the same token, the functionality that these libraries offer and have documented, solve the majority of problems 9-5s would run into. What it more likely means is that these people are under-utilizing the libraries because they aren't able to understand them without more detailed documentation. This is certainly wasteful, hence the reason people love their jQuery or Mootools.

3 Posted by Michael Schuerig on 11 January 2007 | Permalink

Common libraries provide a common language at a higher level than bare-bones JavaScript.

Yes, you are able to write custom code on any new project, but it'll probably be more voluminous than if you had used appropriate libraries. This can be a major maintenance concern. Even more so when the maintainer is another developer who may well know a common library used for the site/app, but has to go into every painstaking detail to understand your custom code.

4 Posted by Dmitry Baranovskiy on 12 January 2007 | Permalink

I am abolutely agree with you on this topic. So many disadvantages:
1. User should load full library for effect, which could be done in 5 lines of code
2. If something goes wrong — it could be whatever: your code or library code
3. Libraries remove the reason to learn JavaScript deeper. As a result even more crappy scripts on the web — this time on libraries
4. It is really hard to create something really good with unversal tool. I could bet that standalone script could be optimized much better then library based one.
So, libraries are doing their job, but at the end noone wins.

5 Posted by Stuart Langridge on 12 January 2007 | Permalink

I agree entirely that simple examples for my 9-to-5ers don't exist. I don't really think (honestly) that those of us who know what we're doing should immediately drop everything and start writing documentation for libraries (although it'd be cool if some did). However, I do think that we should stop telling people to not use them. Say "I *personally* don't like libraries because I want to exercise complete control over the code I write", rather than "libraries are bad unless you completely understand JavaScript, and then you don't need them". The former leaves the door open for people who want to get work done without a deep understanding. It does, however, put a heavier burden on library *authors* to do all they can to encourage users to use the library for progressive enhancement purposes, not for JS-only effects. I can imagine a library refusing to attach an onclick handler to an A element if that A element has a href of "#" or "javascript:*", for example. We need to start talking about this sort of thing, but we can't if half the influential top end of the DOM scripting community is condemning all library users as "not clever enough to use JavaScript".

6 Posted by Clive Murray on 12 January 2007 | Permalink

Speaking as a professional HTML/JS developer for one of the London media agencies, I am grateful for libraries. I'm far from your, Chris's or Stuart's level of expertise but I'm also far from being a nine-to-fiver knowlessman, having been writing JS for 8 years or so.

While I can write neat pure JS by hand to accomplish what I want - and 8 times out of 10 without it works first time - it is sometimes just easier to plug a library in and let that worry about the syntax and the browser differences. I'm a big fan of JQuery, having delved into the big 4 or 5 after seeing yourself, Chris and Simon et al at @media 2006. I was extremely impressed at what it provided for me, i.e. a shorthand way of achieving my goals and knowing that I won't have to hunt through reams of code to find the single erroneous quotemark or missing semicolon that's preventing the whole thing from running in IE6 or Safari or whatever.

That said, I agree wholly with the idea that "if you don't know how JS works, don't write JS, library or not."

Great article, Peter-Paul.
--c.

7 Posted by Clive Murray on 12 January 2007 | Permalink

Apologies, I meant to say "after seeing yourself, _Stuart_ and Simon et al at @media 2006". I happened to be glancing at Chris's name at the time, though. :-)

--c.

8 Posted by Colin Lear on 12 January 2007 | Permalink

I find that using libraries cuts both ways. Most libraries are wasteful overkill. However they help me by providing plumbing that I would or should create anyway.

Before using jQuery or Prototype, it had occurred to me to write my own generic, reusable library, but it never eventuated.

I certainly never would have created a library that enabled JS as powerful, concise or expressive as that enabled by either jQuery or Prototype. I've never been that ambitious, or crazy.

Whether I roll my own library or use someone elses, I'll likely be using a JS library for the forseeable future.

but yeah +1 for complaints about documentation.

9 Posted by Phil Wills on 12 January 2007 | Permalink

I've used Yahoo UI, along with Prototype a fair bit on an internally facing tool and found whilst it's far from perfect and the documentation isn't stellar, it allowed my colleages and I to get the interface the customer wanted built quicker than we would have managed if we'd written everything from scratch. It doesn't stop some of my colleagues with less js experience doing things I'd turn my nose up at, but just having a reasonable encapsulation of cross-browser event registering for instance has some value.

10 Posted by Sean Ransom on 12 January 2007 | Permalink

Libraries are important. In any language really. How useful would c++ be without STL? Most c++ folks could write the string library themselves but why should they have to? The idea that developers will not use a library because they can write it themselves is off the mark. Code reuse IMHO is the sign of a great developer. The ones that feel the need to reinvent the wheel everytime are the ones I do not want to hire at my company. Libraries provide easy means of code reuse. Save your time for the actual problem you are trying to solve, use libraries to take care of the mundane stuff.

As a newish javascript developer but long time compiled and scripting language user I find the availability of libraries a welcome addition to javascript. I feel libraries need to be further adopted and developed. The anti-library arguments seem more elitist and arrogant and do anything but hold back the community and new adopters.

In all honesty javascript is the most painful language I have developed in. The DOM compatibility issues should be encapsulated not in a website (still glad you are doing this) but in an actual library.

Languages should strive to be portable , jscript is far from it.

-sean

11 Posted by Joost Diepenmaat on 12 January 2007 | Permalink

Using a library has little to do with how well you know a language. In fact, a big part of learning most languages is learning which libraries you can use to accomplish tasks - for example Java/J2EE with it's enourmous library, perl with CPAN, etc.

In my experience with "server-side" languages, experienced programmers make more use of libraries than relative newbies. This is partly because of a kind of "getting the job done, quickly" mentality, but also because they realize that most problems are more complex than they appear.

In javascript this is especially true - it's just plain hard and often boring to write efficient portable scripts to do anything interesting. If you have reusable code to take away some of the work, then that's all good.

In my not so humble opinion people who argue against libraries in general are immature script kiddies who should learn a bit of I.T. history. Reusable libraries are the reason we're not still stuck in the early 80's.

That said, there are certainly cases where using libraries is overkill, and there are also definitely javascript libraries that are badly thought out or documented, so criticism on specific issues is still good. Just don't throw away the baby with the bathwater.

12 Posted by Peter on 12 January 2007 | Permalink

Personally I find it difficult to stomach any library if I don't understand it thoroughly, because when things break you have to fix.

When I started learning Javascript about a year ago I was interested in libraries like prototype and moofx because everybody was raving about them. The idea that I could get cool effects now! rather than wait is quite seductive. But my experience was more fustrating than anything else, because the documentation was scant, too techie, or I just didn't understand it. Just made me more determined to learn javascript from the ground up rather than try shortcuts.

13 Posted by Matt Snider on 13 January 2007 | Permalink

I've been using libraries for a while now. At first i found them cumbersome, but once i familiarized myself with the most popular ones, i became attached to key features. The $ function, json parsing, rounded corners, form parsing, ajax management, preloading scripts, etc. Unfortunately, no library does a great job at everything, so over time i've extracted features from different libraries into a small, but powerful toolset.

The biggest problem is each toolkit reinvents the wheel. Mostly they do the same things. Libraries can be powerful, but need standards. Dojo and yui have great internal standards so one can use the code libraries they need. However, they don’t mix well with each other and the other toolkits don’t play nice with anyone.

Another problem is the proliferation of prototype and prototype-based toolkits. Prototype massively references itself, especially the Enumeration object, which is slow. Also, the Enumeration object attaches 15-20 functions to type array, all but forcing you to use prototype array enumeration methods.

My list of grievances goes on, however, the most important step to the toolkit wars/revolution is standards. It is a project I’m looking forward to working on once I get some free time.

14 Posted by Tino Zijdel on 14 January 2007 | Permalink

Libraries are abstractions, and abstractions always leak on a certain level; be it on a performance level (overly use of $() for instance), be it on a functional level (where the abstraction actually doesn't quite let you do what you want to do), be it on a fundamental level where the abstraction actually doesn't cope with a specific situation and fails miserably.

A browser environment isn't a homogeneous environment and libraries have to deal with a lot of different javascript implementation issues. Some do that quite well but some others are quite poor at that, and none are perfect. Fact is that no matter how well documented the library is, documentation will mostly be oriented around functionality and features but not around it's shortcomings.

Without any real javascript knowledge it is very hard to determine whether a specific library will fill the actual requirements for a specific project or not.

Furthermore: libraries don't teach you javascript and you shouldn't rely on a community to solve your specific problems because often their priorities won't match yours.

15 Posted by Jamie on 15 January 2007 | Permalink

As a nine-to-fiver who spends 90% of his time on server-side scripting I cannot agree more with your view that "If JavaScript is not your main strength, using a library to do the dirty work for you makes sense. However, if you can't figure out how the library works, either, you're back to square one."

I have had a look at countless libraries when I couldn't be bothered to work out why for example my simple fade-in effect didn't work in Browser X but spent so much time trying to figure out how the library worked I could have solved my browser incompatibility myself 10 time's over.

16 Posted by Matthew Pollard on 15 January 2007 | Permalink

My general feeling about JS libraries is pretty negative - this might be because there are so many posts about how bad they are but when it comes down to it depends on what you are doing.

If you are only going to use a small part of the library you still have to include the whole lot which in some case seems to be 3 files which seems overkill to me.

But if you are building a massively DHTML site which is going to have all the bells and whistles imaginable then why not.

Either way bells and whistles should not be used for the sake of it.

17 Posted by Dimitry Z on 22 January 2007 | Permalink

Most libraries I've used were overkill for the task at hand, and required 10kb+ of included code. Simple transitions would depend on heavier DOM and Array libs for one or two functions.

However, if you plan on using file-submitting AJAX forms - and don't want to mess with JS generated iframes - you may have to use some of the heavier solutions out there (YUI, Dojo).

I've found MooTools to be the best lib. It uses easy to read names (what the hell is a $() anyway) and includes some very useful classes that all HTML based sites/systems use (Cookie, Funciton, Element). With a core and lightweight solution, you can create function that take care of the high-level functionality:

eg.
function showModal ( text)
{
/* display a modal window */
}

function editInnerHTML ( elId)
{
/* edit the content of a div, p, etc. like in flickr.com */
}

jQuery, although very short-hand and briliant in many respects, feels like it belongs in inline events, rather than external .js files.

18 Posted by Chris on 26 January 2007 | Permalink

My feeling about the libraries is that of any project I might take on. If somebody has already gone through all the trouble of creating a cool effect, and making sure it will work in all the browsers, AND gives me an easy way to attach it to an element, why would I want to go through all that myself? Introducing myself to the libraries (I happen to be a mootools fan at the moment) encouraged me to dig deeper into javascripting in general and every day I am learning something new. That being said, it is imperative that one understands how the library works so when it comes time to debug, you know what you are looking at.

19 Posted by Robert on 26 January 2007 | Permalink

Libraries - in any language - provide two great benefits. First, code reuse, and second, platform abstraction. When a new browser comes out, ensuring your site plays well with it is as simple as updating the library; if the library is designed well, you won't need to touch your own code. A good open source library will have thousands of contributors finding and squashing bugs and quirks. Harnass the wisdom of crowds, and all that.

Frankly, refusing to use libraries isn't a sign of elitism, it's a sign a bad programmer. As someone mentioned before, would you sit down and rewrite the STL every time you began a project in C++? (And would you say that only programmers capable of rewriting the STL should be allowed to use C++? There goes almost everyone - what hubris!)

That being said, most JS libraries floating out there are NOT currently production-ready, I will certainly admit. Then again, most of them haven't even claimed a 1.0 release. Perhaps you should lend your expertise.