Friday, November 9th, 2007

How well do you know Prototype?

Category: Prototype

With all of the news about Prototype this week, it’s time to do a quick check to see if you, the Prototype developer, actually know your stuff.

Juiry Zaytsev takes us through a comparison of the right & wrong ways of doing certain tasks in Prototype:

I’ve been developing with prototype for almost a year now and have been spending a lot of time on the IRC channel. It’s hard to explain what kind of nonsense people are asking sometimes. It seems to me that most of the time prototype is used at 15%, not more. I’m not surprised anymore to see Ajax.Request used with document.getElementById on one line

Juriy created two posts that offer insight into how to properly right Prototype code to handle various scenarios. For example:

The wrong way:

$(‘footer’).style.height = ‘100px’;
$(‘footer’).style.background = ‘#ffc’;

The right way:

height: ‘100px’,
background: ‘#ffc’

The two posts can be found below:

How well do you know prototype Part 1
How well do you know prototype Part 2

Posted by Rey Bango at 9:41 am

3.5 rating from 36 votes


Comments feed TrackBack URI

It overrides/extends internal Javascript objects, that’s about all I need to know.

Comment by Mark — November 9, 2007

damn, I was expecting a quiz :(

Comment by Viktor Kojouharov — November 9, 2007

@Mark : If you’re speaking about that stuff, extending the hashmaps, it’s no longer the case. Otherwise, I can’t see what is wrong with extending prototypes, beside the fact that some of methods implemented sucks, like Array.getFirst();

Comment by Samori Gorse — November 9, 2007

The problem is that there is no ‘unified’ documentation AFAIK. When using Prototype (or any other JS library) this will more or less deprecate parts of the regular API. But no one will tell you which parts should not be used anymore. So how could be developer possibly now that document.getElementById should not be used anymore, but Math is still ok? Especially if one only adds Prototype for a particular reason (like a nice API for XmlHttpRequest).

Comment by Tim — November 9, 2007

extending base objects bad, because we used prototype some time ago, and now it’s really hard to get rid of it because those .bind() and few array and string extensions are used sometimes across the code.

Comment by Anonymous — November 9, 2007

I would love to see a similar wrong way/right way list for dojo (0.9/1.0). If anyone knows of something like that be sure to share, but I’m sure chances are slim.

Comment by mhusson — November 9, 2007

@Mark, Tim: Just to clarify, Prototype doesn’t override native properties, it extends them. There’s nothing wrong with using document.getElementById, for example, it’s just not using the full power of Prototype, that’s all.

Comment by Tobie Langel — November 9, 2007

Nice post, I found a couple idioms I need to start using. …(@Mark ..Prototype (the JS library) hasn’t extended the Object.prototype since version 1.4, many moons ago. )

Comment by Mark Holton — November 9, 2007

This actually goes the same as jQuery except jQuery’s selector doesn’t really return a raw DOM object.

I’ve seen ppl doing this

$("#some_node").css("background", "red");
$("#some_node").css("color", "#FFFFFF");

Which the actual better and more efficient way is

$("#some_node").css({background: "red", color, "#FFFFFF"});

Comment by Simon Jia — November 9, 2007

Oh, and one more thing to mention, if you need to set “background-color”, the syntax should be “backgroundColor”.
Pretty sure most of u guys know this already.

Comment by Simon Jia — November 9, 2007

Nice checklist and some interesting stuff on the blog as well.

@Simon: Why are you posting that jQuery code here? Want some Mootools and YUI code too? Maybe it’s a good idea if you made your own checklist?

Comment by Trulli — November 9, 2007

extending base objects bad, because we used prototype some time ago, and now it’s really hard to get rid of it because those .bind() and few array and string extensions are used sometimes across the code.

I can understand (in some cases) wanting your code to be portable, but given the different philosophies of the various popular JS libraries, you’d have the same problem with any one of them. I fail to see how this is prototype’s fault any more than any other library. I mean, if you’re advocating against using a library at all, that’s fine too, but I can’t really imagine a good argument for that.

Come on. Until you’re ready to rewrite an application, it’s okay to use a single library’s API as part of your application. And you can always use a different library on a different application. You wouldn’t expect changing your house’s foundation to be a quick and easy task, not especially if you’re moving your house to a different locale with different geological demands. Why would you expect that of the foundation of your UI logic?

Comment by Trevor — November 10, 2007

How well you know prototype also has to be tempered with how well you now your browser. Case in point, I had a long list of checkboxes in a tree that had to be set and cleared depending on what the user selected. I had used the “prototype way” of doing things which worked fine in Firefox (it finished in just under 1 second), but when tested in IE, the function ran over 6 seconds long. Only by taking out some of the prototype syntax sugar, was I able to get the times below 1 second on IE.

Comment by Marlon — November 10, 2007

prototype is tha shit. there is a better lib

Comment by jsJihad — November 11, 2007

@Marlon: there was a bug somewhere between versions of prototype that made various selectors (like getElementsByClassName, which is now deprecated) to be very slow in IE. However, this was fixed a long time ago. Though it might not be as fast as firefox (IE doesn’t support xforms), it’s not ‘6 seconds’ slow either.

Comment by Viktor Kojouharov — November 12, 2007

I couldn’t post a comment on Part I. But the author might want to note that $F doesn’t work for radio buttons. As a newbie, that tripped me up.

It would be nice if that gets fixed.

Comment by Sam — November 14, 2007

People should really read the docs!

Those things are there!

Comment by Web Design NY — November 17, 2007

Leave a comment

You must be logged in to post a comment.