A tiny little gripe about javascript libraries
posted Feb 05, 2008

I wrote a rant about something that annoyed me greatly when working with JS libraries.

read the rant if you want. Or read below, which is the same thing, but in a nicer and hopefully clearer way.

Because about half of what I ranted about was wrong, and the other half wasn't worth getting angry about. It's just slightly annoying.

A great deal of what I do with js libraries is move page elements around, change their size, and toggle them on and off.

Every JS library has slightly different ways to do this, and these ways aren't internally consistent.

(By "internally consistent", I mean that functions which get a value should return data in the same format accepted by functions that set that same value.)

This isn't too surprising, considering that the properties in question are really css. JS libraries don't like to layer tons of abstractions on top of css, prefering to simply let the programmer get and set attributes.

But for the things I described above (element position, size, on/off), css attributes aren't the greatest. I like to store visibility as a boolean (not "none" or "block"). I like to store and manipulate position and size as integers (pixel dimensions). As great as css is for defining sizes in percentages or ems, my javascript is only concerned with their pixel size.

For a long time, I've been a big fan of the <a href="MochiKit</a>> js library, because it makes what I want easy.

I recently learned that jQuery does this too. Thanks John!

Other js libraries don't measure up as well:

Set Element Position Set Element Dimensions show/hide element
MochiKit:):):)
JQuery:):):)
YUI:):(:(
Prototype/
Scriptaculous		:(:(:)
MooTools:(:(:)

I hope those libraries improve at some point. For the time being, I'm stuck writing wrapper functions for setting element position and toggling visibility whenever I work with them :(

Comment by
posted Feb 01, 2008

I'm perfectly capable to write wrapper functions that let me do visibility toggling and positioning. But I hate, hate, hate doing it.

Do it once and put it in a file like we all do. What's your problem?

Comment by LPD
posted Feb 01, 2008

My problem is that I hate doing it.

Abstracting away small things that "we all do" is a library's main job.

I didn't hate it as much before I started using MochiKit :)

Comment by John Resig
posted Feb 01, 2008

I'm confused - in jQuery you can do: .height(400) .width(400) .css("left", 200) .css("top", 200) All using pure numbers no strings involved - isn't that what you're referring to?

Comment by LPD
posted Feb 01, 2008

Thanks John :) BTW that Pretty Date stuff is very smooth.

In jQuery, my wrapper function looks like:

function setCoords(el, c) {
  el.css.left(c[0]);
  el.css.top(c[1]);
  if (c.length < 2) return;
  setSize(el,c.slice(2));
}

function setSize(el,s) {
  el.width(s[0]);
  el.height(s[1]);

}

What I'd like (which I should have clarified in the rant) are functions that accept tuple pairs of coordinates.

Dictionary pairs also work ( {'x':0,'y':0,'w':200,'h':100} )

Basically, whatever data structure is returned by the coordinate getter functions ought to be accepted as input for the setter functions.

It may be that most folks don't share this opinion :) It appears that many are comfortable with custom wrappers around their favorite libraries' coordinate APIs.

Comment by John Resig
posted Feb 01, 2008

@LPD: I see what you're saying, so you could do this, then: Use .offset() (returns {top: 40, left: 40}) which you can feed straight into .css(), like so: .css({top: 40, left: 40}) - you can even include width and height (again, no css munging needed): .css({top: 40, left: 40, width: 200, height: 200}). It sounds like it meets your criteria fairly well.