Comments on: Caring about quality in our JavaScript libraries

By: SiteSmart

SiteSmart — Thu, 29 Nov 2007 20:55:53 +0000

Clean API and small file size are important. If code is commented well (in uncompressed version) then documentation isn't as important. Justin Are you site smart?

By: portrait artist

portrait artist — Wed, 07 Nov 2007 05:50:19 +0000

Donâ€™t despair. There are just people out there who are nothing but plain and simple fault finding critics. Just do your job well and youâ€™ll see that no one can ever steal your thunder.

By: psyki

psyki — Wed, 23 May 2007 09:46:39 +0000

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.

By: Michael Jackson

Michael Jackson — Sun, 24 Dec 2006 23:59:31 +0000

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?

By: optimus paul

optimus paul — Tue, 17 Oct 2006 19:59:24 +0000

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.

By: Andreas

Andreas — Sun, 15 Oct 2006 12:36:09 +0000

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

By: Andrea Giammarchi

Andrea Giammarchi — Sat, 14 Oct 2006 21:57:03 +0000

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 :?

By: Leo

Leo — Sat, 14 Oct 2006 18:48:37 +0000

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 :)

By: bartb

bartb — Sat, 14 Oct 2006 18:01:31 +0000

Bytefx doesn’t even work in safari

By: Andrea Giammarchi

Andrea Giammarchi — Sat, 14 Oct 2006 15:47:54 +0000

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

By: someone

someone — Sat, 14 Oct 2006 08:27:17 +0000

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 !

By: John Resig

John Resig — Fri, 13 Oct 2006 22:43:59 +0000

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

By: John Resig

John Resig — Fri, 13 Oct 2006 22:39:06 +0000

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.

By: Jesse Kuhnert

Jesse Kuhnert — Fri, 13 Oct 2006 20:11:35 +0000

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.

By: Matt Oakes

Matt Oakes — Fri, 13 Oct 2006 18:57:33 +0000

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

By: Benji York

Benji York — Fri, 13 Oct 2006 18:46:18 +0000

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.

By: Dean Edwards

Dean Edwards — Fri, 13 Oct 2006 18:21:51 +0000

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

By: James Starmer

James Starmer — Fri, 13 Oct 2006 17:53:14 +0000

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.

By: Mike Ritchie

Mike Ritchie — Fri, 13 Oct 2006 17:53:12 +0000

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.

By: Aaron N.

Aaron N. — Fri, 13 Oct 2006 17:22:35 +0000

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…