Monday, March 26th, 2007

More base2.DOM and advice for writing JavaScript libraries

Category: Articles, JavaScript, Library

<>p>Dean Edwards has followed up on his base2 library posting with another way to use base2 and rules for JavaScript Library Authors.

In “the other way” Dean shows how to use the library as library functions instead of strapping on to objects, and his library rules are:

  1. Be unobtrusive
  2. Object.prototype is verboten!
  3. Do Not Over-extend
  4. Follow Standards
  5. Or Follow The Leader (Mozilla)
  6. Be Flexible
  7. Manage Memory
  8. Eliminate Browser Sniffing
  9. Small is Better
  10. The Tenth Rule: Be Predictable
  11. Bonus Rules: Documentation. Annoying but true., The more namespacing you use, the less likely I am to remember your phone number., Remember that potentially millions of people will be executing your code.

This is good advice whether you are writing the next Dojo, or working on your own project too. Code bases get bigger, and you don’t want to clash with your own code.

Posted by Dion Almaer at 9:04 am
14 Comments

+++--
3.6 rating from 38 votes

14 Comments »

Comments feed TrackBack URI

I think it is acceptable to use Object.prototype for extending objects – the main problem is the fact that IE does not recognize everything on the page as objects. I ran into that problem, and had to make IE init everything that was on the page as an Object, something I wasn’t happy about.

Looking back on it, I don’t really think there is anything WRONG with using Object.prototype, but it would be more optimal to create a custom element class and initialize all elements on the page as that class.

The flexibility that is created when this is done is astounding and wonderful – I can use code like the following:


document.getElementById("box1").moveLeft(50);

The big advantage to the above is not that I am moving the object’s x coordinates, but that when using these functions to move the object’s x coordinate I can attach events, so that I can even move objects relative to the x coordinates. See below: (I’m making this on the fly so I might have some very big mistakes…)


var splitter = document.getElementById("splitter");
var right_panel = document.getElementById("right_panel");
right_panel.makeRelative(splitter, "right", "left");
splitter.makeDraggable();

Though the code above is hardly complete, it shows what I was trying to accomplish.

Though like I said, if I were to do it again I would use a custom element class and “add” the functions to the objects that way…

Comment by Alex — March 26, 2007

Extending Object.prototype will cause headache with loads of other scripts that use for(var i in object)….

Big big problem. You should be able to use for(var i in myObject) unlike the for(var i in myArray) which iterates over the array object instance and not just the index’s of the array stack.

Comment by wrong — March 26, 2007

It might cause a problem if you want to iterate over an object. I’ve never had to, so I didn’t see it as a problem.

But if you are talking about objects like custom objects created with {“key”: value}, then I can understand the difficulty. Thus I probably should change my code to extend only HTML elements (which is what I want to extend).

Comment by Alex — March 26, 2007

I think using Object.prototype or any other kind of prototype is good
to implement new functions to the default javascript objects.
The bad side is if you override some existing function to modify the behavior.

Comment by rodrigo — March 26, 2007

Its fine to extend other Native objects in js, BUT the native “Object object” because so much is built of it as my first post mentions.

Comment by wrong — March 26, 2007

Do not use Object.prototype. How novice-y can you get? This is like other famous ideas “Hey, lets denormalize these tables, we’ll never need to-” or, “Nah, we can put it all in memory since we don’t have to worry about-”, or “Nah, this is a one time thing, so we don’t have to do this in-”

Why introduce it as a possible major headache? Just say no.

Comment by Ivan — March 26, 2007

so as someone who *is* writing the next Dojo, I can tell you that these are rules we’ve been following for a good long time. What they don’t address, however, are situations where higher-level semantics are preferable or beneficial.

Half the value in a toolkit is that it should fill in where the standards themselves fall down, not just the implementations of those standards.

Regards

Comment by Alex Russell — March 26, 2007

@Alex – I wrote those rules for myself really. Some of them don’t necessarily apply to something the size and scope of Dojo.

Comment by Dean Edwards — March 26, 2007

Finally, thanks! From now on, thanks to Dean Edwards, I hope some individuals will start to believe me that Prototype and jQuery is evil :-)

I believe that the rules “be unobtrusive” and “be predictable” not only bans Object.prototype from modification, but it bans Array.prototype and other possible built-in prototypes too. Rule of thumb – don’t modify existing prototype, extend your own instead.

Another two rules of “unobtrusiveness” could be:
1) “keep namespace clean” – wrap your functions and objects into namespaces like yui does.
2) “don’t touch my event handlers” – if you need to attach eventhandler somewhere and you don’t want to use listener, first look if you are not overwriting another event handler.

Comment by Richard — March 27, 2007

That “Object.prototype is verboten” jazz is silly. If you write your programs correctly, they won’t break so often. As we mashup, it becomes even more irresponsible to be dependent on everyone else in the world adopting your rule because you can’t be bothered to write a for loop correctly.

It is a shame that documentation fell off the list. It should be much closer to the top.

Comment by Douglas Crockford — March 28, 2007

@Douglas – the “Object.prototype is verboten” jazz is not silly. When you are authoring a library you should try as hard as possible not to break other people’s scripts. It is not about protecting your own code, it is about protecting the user’s code from your code.

Comment by Dean Edwards — March 28, 2007

@Richard : I am fairly certain that neither prototype or jquery abuse the object.prototype. I might be wrong, but you should check your claims.

I do believe the DED|Chain library by Dustin Diaz might modify the array prototype ( he uses his “sugar arrays” snippets internally )

Comment by Abba Bryant — April 2, 2007

Thanks for the advice for writing JavaScript libraries. I have bookmarked this page for further reads.

Comment by Fifth Wheels — September 13, 2007

Over the course of the last four years I’ve had many occasions to help friends and colleagues with JavaScript. While the problems they were trying to solve ranged from validating the content entered into a form field to making an image fly across the screen, the structure used to solve the problems has remained consistent. Learning JavaScript can seem like a monumental task. Often one’s first exposure comes from examining the code grabbed from a random site on the web, or that created by tools such as Macromedia Dreamweaver.

Comment by fordavidbrawn — June 30, 2008

Leave a comment

You must be logged in to post a comment.