Friday, October 13th, 2006

Caring about quality in our JavaScript libraries

Category: Editorial

What do we seem to care about in JavaScript libraries that come out?

Anecdotally it seems that the top items are:

  • Nice API: We want a nice simple well thoughtout API.
  • File size: If it is under 3KB it must be good :)
  • Documentation: Please!
  • Components / plugins that can do a lot of stuff for us out of the box

But, what about quality? How many of us profile the libraries?

We got an email yesterday from someone (will rename nameless unless they want to step up in comments) that asked:

I have seen two posts on mootools from you guys today and I’m just a
little frustrated by the hype that it gets even though (in my opinion)
it’s broken. The Smooth Slideshow 2.0 is a perfect example. On page
reload that thing leaks about 6MB. How is that acceptable by any
means?

Do you profile library code? Do you profile your own code? We can’t just blame the frameworks after all. It is very easy to leak memory ourselves.

Posted by Dion Almaer at 9:03 am
26 Comments

+++--
3.7 rating from 40 votes

26 Comments »

Comments feed TrackBack URI

I ran into a problem with prototype.js last week that would not have happened if those guys were not using coding shortcuts (ie: using line breaks instead of explicit {bracketing} for code blocks}

I’m not sure if it was ClearCase or Eclipse that caused the library to be built with extra line-breaks (the resulting file was double-spaced), but it would not have been an issue if the shortcuts had been avoided to begin with.

Comment by Marty — October 13, 2006

We’ve started using mootools for our framework at CNET.com and I must admit I’m impressed by it. Prototype, our previous choice, is awesome and mootools takes a lot of inspiration from it. But while Prototype delivers to you a tremendous amount of technology in a 50K package, it doesn’t really do anything; it just let’s you write javascript more elegantly.

Mootools, on the other hand, is perfect for people who aren’t building a clientside application but instead just want to make an html experience more engaging. You can choose the components you want when you download it, allowing you to get only the functionality you need. What’s more, it’s functional from the get go. It’s written to let you manipulate the DOM quickly and elegantly. It’s highly extendable. It has functionality in it that you’d need Scriptaculous or some other library in addition to Prototype to pull off otherwise.

So far, I’ve yet to find any memory leaks in mootools itself, though any javascript that you write that connects to the DOM a lot has the potential to leak. Writing good code with a framework like Prototype or Mootools or jQuery is always a must, and any of these frameworks – even plain javascript – will leak if you aren’t careful.

Comment by Aaron — October 13, 2006

There is a reason these libraries are open-source, free, and not yet completed.

Why not submit these bugs to the team that works on it, maybe they can improve upon these problems.

Comment by Kristofer Baxter — October 13, 2006

Also, I have nothing but praise as well for mootools.

I’ve used it on quite a few projects (which are in proofing still) and found it to be extremely easy to use and powerful.

An example of a recent usage: A site which previously used 300k of JS to simply place ads on the page and use tooltips now only uses 20k to do the same thing with zero memory leak problems.

Comment by Kristofer Baxter — October 13, 2006

I sent the email. This is why I’m frustrated with moo.fx: Link to the comment on the moo.fx bug report forum.

They know there is a problem but they are going to ignore it until IE7. So why can’t we blame the framework? They are producing something that most of the people believe to be a solid foundation to build on but it’s not.

Comment by James Starmer — October 13, 2006

I think it is a bit harsh to blame mootools because the slideshow demo leaks memory. It is always possible to write leaky code no matter what library you are using. It sounds like this complaint comes from one of the old skool procedural scripters who just do not like libraries.

Comment by Dean Edwards — October 13, 2006

The unfortunate thing is that most memory leaks in JS apps are due to the IE DOM reference counting based memory leak. In general it takes some work to actually create memory leaks in pure JS, as GC languages help out so much with that. What is unfortunate is that IE memory leaks are caused by what is actually better coding style. Setting element event handlers with closures rather than inline, and storing references to elements instead of ids is actually much better code style. In my opinion the IE memory leak bug is one of the most tragic bugs in browser history because it has caused to developers to either write ugly code or introduce memory leaks. Fortuneately IE 7 has fixed this bug, hopefully IE 7 will be adopted quickly (by thosing using IE currently).

Comment by Kris Zyp — October 13, 2006

Aaron:

I too use Prototype on a daily basis and while I must admit that I absolutely love it and depend on it when coding, I too am frustrated (or at least baffled) by their lack of conditional bracketing. It just doesn’t make sense. For a library that so effectively extends core Javascript functionality, using such poor coding style reminiscent of 1999 style Javascripting boggles my mind.

I’m just waiting for them to stop putting semi-colons after statements. After all, Javascript treats newlines as statement enders. Heh.

If you figure out why they do it, let me know, OK?

-E

Comment by Eric Ryan Harrison — October 13, 2006

Eric, I think you’re meaning to reply to Marty, not me, as I didn’t make that comment about Prototype and it’s bracketing. I don’t disagree, and I don’t know why they write it that way.

I’ve been using Dean Edward’s javascript compressor (Hi Dean, I see your comment up there) – which mootools also uses – and it requires you to be syntactically perfect. Consequently, all my code has recently gotten squeakly clean…

Comment by Aaron N. — October 13, 2006

I have been working on a new product for my FuseBuilder line as well, which is 80% javascript and Ajax with 20% backend (for setters/getters to make browser-side changes persistant). I had started this using Moo.js and the other Moo libraries built on top of it, but decided to switch to Mootools.js because of the integration and the fingerprint. It has worked fairly well, but it was not painless by any stretch, even though I was going from an earlier version of the developer’s own library. The documentation is incredibly sparse, especially for outlining what developers need to change if they’re coming from Moo.js etc.
And then, just to make sure I was sufficiently frustrated, I switched from the public download to the latest in the SVN. Now I don’t dare download the new SVNs as they are completed, even though there are bug fixes, because I’m sure to have to rewrite all my code each time.

Comment by Mike Ritchie — October 13, 2006

Dean,
You are right, “It is always possible to write leaky code no matter what library you are using”. But if the library itself has leaks then I’d say that it’s impossible not to write leaky code. I’d also say that it makes it much easier to write a bit of code that amplifies a leak in the library.

I’m not one of those “old skool procedural scripters who just do not like libraries”. I love libraries and the code reuse that they provide especially when coupled with OO javascript practices. But being that I’m not a new skewl OO javascript guru like you, I have enough trouble figuring out my own memory leaks let alone the leaks in libraries.

I didn’t mean for this to be an attack on mootools. I think they have a very slick framework going and they are obviously working really hard.

Comment by James Starmer — October 13, 2006

@James – You make a good point when you talk about a library that “makes it much easier to write a bit of code that amplifies a leak in the library”. It should be the point of libraries to shield us from these horrors as much as possible.

Comment by Dean Edwards — October 13, 2006

I’ll add one: tests!
It’s bad enough that most JS libraries are poorly documented, but most have little or no automated testing. One notable exception is Mochikit, which is one reason we (my company) prefers it.

Comment by Benji York — October 13, 2006

i believe that jQuery also have some form of testing on it as well, and the documentation is very very good.

Comment by Matt Oakes — October 13, 2006

Excellent article. I hope all of the javascript library developers are listening.

Sometimes it feels like libraries(in any language) can become victims of their own success. It’s easy to get caught up in bug fixing / feature additions and lose focus of the quality of code being produced as a possible reason for all of the bugs..

Loyalty to one js library can only go so far. For some of us quality of code is the only loyalty that exists. If you have the power to fix it in the library you currently use then great, but if not – there are plenty of libraries out there that do care about the same things.

Comment by Jesse Kuhnert — October 13, 2006

To answer the questions posed by this article, in relation to jQuery:

Nice API: jQuery’s API is very thorough and well thought out. It covers everything from DOM manipulation and events to animations and AJAX.

File size: jQuery currently stands at about 16kb – roughly the same as MooTools.

Documentation: jQuery is completely documented, with tons of tutorials and an avid community (I find it odd that you didn’t ask about that aspect here?).

Plugins: At last count, jQuery has over 80 plugins, and an excellent plugin architecture for adding more.

Comment by John Resig — October 13, 2006

@Benji: Matt was correct, jQuery does have a full, automated, test suite. All the tests are extracted automatically from the source code of jQuery, itself. Additionally, jQuery has a full build system, so that you can type ‘make test’ or ‘ant test’ on the command-line and build your own version of the test suite (or documentation, or jQuery itself). Everything about the jQuery build and test process is very streamlined – and we take great pride in that.

Comment by John Resig — October 13, 2006

Jquery do have tons of marketing/sales boys.
well done for that.
Mootool is just better (full stop).

I do like the completeness as a project (Jquery). but when we talk about quality of the library itself. Jquery have some fundamental problems.

Althoug it is fairly well structured and small but too much hacky looking code + lack of clean OO inheritence.

By list will look like this.
Jquery -> best supported
Prototype -> best feature rich library
Mootools -> simplely best designed !

Comment by someone — October 14, 2006

I’ve been using Dean Edward’s javascript compressor … which mootools also uses
ehr … MooTools uses my PHP JavaScriptCompressor to create runtime differents packages and its last version doesn’t requires perfect code (semi colons) as Dean’s packer function … and I remember I’ve compressed prototype too (but I don’t remember wich version) witout problems :)

However, if this is not OT, bytefx hasn’t memory leak problems and is optimized for Dean’s packer as MemTronic compressor … but it probably hasn’t a good documentation (maybe just the complete API isn’t enought).

Comment by Andrea Giammarchi — October 14, 2006

Bytefx doesn’t even work in safari

Comment by bartb — October 14, 2006

To be used, I would hope that a library is useful :) I used to believe in bandwidth, but no longer. At this point, all I really care about is legibility, performance, and safety: can I quickly write a fast site and know it works?

These frameworks and libraries are from people who need them, mostly addressing the first two points, but the third is an ever sticky issue. Browsers are still too broken to make this a priority until there is a real need (eg, userbase or commercial deployment), giving a chicken and the egg problem with the only way out being experimentation by developers in their own projects or better ways to do automatic browser testing. Either contribute, submit a bug report, or build your own system :)

Comment by Leo — October 14, 2006

Bytefx doesn’t even work in safari
uhm … maybe MemTronic version doesn’t work, Dean’s packer version works on Safari too :)

P.S. my friend tells me that bytefx works on Sarai 2 too :?

Comment by Andrea Giammarchi — October 14, 2006

There are many problems about quality in current frameworks. Many don’t work in Opera 8.5 and 9 (a part of scriptaculous doesn’t work in opera). I use prototype 1.5, it’s nearly perfect, but:

– Element.getDimensions is not compatible with many browsers and return the real but not the style dimensions of an element. you have to consider padding, border etc and the differences of the box model ie/ff.

– Older browsers don’t support dom event listener, so you should write your own workaround.

I use some self developed prototype extensions to make my own ideas and frameworks work and to guarantee browser compatability: http://aka-fotos.de/g/js/prototype_extended.js

Greetz

Andi

Comment by Andreas — October 15, 2006

I think that far too many developers neglect to do any profiling of their js code, for one thing, it’s not that obvious how to do it. I for one and guilty, and I’d like to hear about how people do profile their AJAX apps.

Comment by optimus paul — October 17, 2006

Andreas: Why are you (and a large portion of the web developing world) concerned about Opera? Having worked on frameworks for a while now, I can testify that is a pain in the butt to support Opera. How many people do you know that use Opera that aren’t also developers of some kind? Probably not many. Will somebody please explain why they feel we need to worry about Opera at all?

Comment by Michael Jackson — December 24, 2006

I can’t believe you said that.

I thought that, with Firefox getting more popular, every decent developer out there would realise the importance of cross-browser by now.

How many people (non-developers) did you know who used firefox, or (even firebird, the old name) 5 years ago? Huh? When everyone was using IE, and firefox/firebird only had a very limited userbase, pretty much developers-only.
Wasn’t it worth the effort?

The same thing applies to Opera, Firefox, Safari, IE, every browser out there. Browser compatibility is a ‘must’ for me.
Allright fine, I’m guilty too, i’ve written scripts that weren’t compatible with Opera too. But those were small things I only used at one site.

When writing an actual framework, that you’re gonna reuse (or others will use), things like browser compatibility, web standards, xhtml strict should be well, standard.

Comment by psyki — May 23, 2007

Leave a comment

You must be logged in to post a comment.