Via Geoffery Moller, I came across this article on Matt Snider’s blog. I’m surprised that no one noticed what (to me) was the most relevant difference in the libraries that he evaluated.
The “YUI method of class creation” is not distinctively YUI—it’s just what Javascript gives you for free. You can use the “Module Pattern” alone on a page with no library at all! You can call it Crockford’s Module Pattern, but it seems to me that he discovered or popularized it more than “invented” it.
This, to me, highlights the biggest difference in approach between YUI and every other library: YUI doesn’t attempt to re-write the language, but rather to show off what the language can do and how those features can be effectively put to use. My experience with Prototype and Dojo and Mochikit all made me feel a bit like the author must not have liked Javascript very much. (Dojo actually goes a bit further—it rewrites HTML as well!) It seems like the other libraries say, “This Javascript language is too hard and confusing. Let’s make it into something else.” YUI says, “This language is beautiful and powerful, but it would be handy if we had some conventions and a common approach to these rough edges. Let’s build those common pieces.” It’s the difference between teaching someone to fish and giving them a fish, except instead of giving him a fish, you pass the fish through a slow and complex machine that spits out Java code.
Of course, I’m a bit biased. I imprinted upon YUI at a fairly early stage in my Javascript development. I work here, so I get to request features directly through our internal bugzilla instead of pleading in the public arenas. But the approach is one that I’ve always favored. If you feel the need to rewrite the language, then just go use another language. Javascript is the common tongue of the internet, and will remain so for the indefinite future. Don’t fight it. (Hat-tip to Jeff Atwood.)
Crockford’s “Module Pattern” is a great way to create a singleton that has some private methods. In fact, in my opinion, it’s the best and only way that this task should be done. (There are others, but they tend to be more obtuse, IMO.) But that’s not the only task of an object-oriented development. Sometimes, you need to have a bunch of objects, and if they have shared functionality, then that should be handled with a class of sorts. In Javascript, that means that they’re stamped from the same Constructor and Prototype. The Module Pattern does not address this in a very clear way, but it does highlight the principle of data-hiding through a closure that is the key to OOP in Javascript.
To create a class, I usually do something like this, which takes the essence of the Module Pattern and uses it to create a reusable class.
(function () {
// these are properly private static, not just private
// but with scope correction, that’s good enough for functions.
// private function, called with privateFunction.call(this, a, b, c);
var privateFunction = function (a, b) {
this.a = a;
this.b = b;
};
// private static data. Shared between all instances!
var privateStaticData = “I’m private and static. All instances share me.”;
YAHOO.myProject.myClass = function (a, b, id) {
// a and b are public, since they’re set on this.
this.a = a;
this.b = b;
YAHOO.myProject.myClass.instances[id] = this;
};
YAHOO.myProject.myClass.instances = {};
YAHOO.myProject.myClass.prototype = {
myPublicProperty : “I’m accessible as
(When in doubt, wrap it in a closure. Global variables are evil.)
I’d rather work with someone who is a bit green with Javascript but can learn, rather than someone who is an expert with Prototype or Dojo. The more time someone spends building applications with a library like Prototype, the further they get from Javascript, and the more dependent they become on the library. By contrast, time spent using YUI tends to breed developers who are experts in Javascript, and that skill is far more useful than being an expert in a particular library.
17 Comments
Great post Isaac. I could not agree more ^_^
Well said - I’ll be pointing people to this post for sure.
Thanks,
Nate
Thanks for the props, guys.
@Nate I think I just figured out a promotion technique for Foohack: write about YUI every other post, and let you promote it for me.
Take a look at jGrouse Loader http://jgrouse.com/#jgrouselib/jgloader.html - it is the logical extension and implementation for the concept of JavaScript module. Normally you would expect that modules would track dependencies on each other and have a predictable initialization order - jGrouse Loader provides that functionality. And you can use it with any other library that you’re currently using.
Foo Hack » Blueprint CSS Framework vs YUI Grids
[...] did recently compare YUI with a competitor, and I don’t want this to turn into a “YUI vs. X” blog. It’s a very limited [...]
I don’t see the point of creating the constructor in the anonymous function. If the public instance methods (in the prototype) need to use private (inaccessible to others) variables, just have the *prototype* returned from an anonymous function:
MyClass= function(a, b, id) {};
MyClass.prototype = (function() {
var privateData = “foo”;
function privateMethod() {
};
return {
publicMethod: function() {}
};
})();
@Animal
That works just as well, I suppose, except that the private methods can’t be accessed from within the constructor itself. On the other hand, the benefit is that, for those familiar with the javascript module pattern, it uses the module pattern to create the prototype.
Of course, they’re so cheap that when in doubt, I just create a closure to hide code within it. They you can afford to be a bit “sloppy” (creating vars willy-nilly) without fear of polluting the global space.
To properly compare frameworks and libraries one must become very proficient in each library. That means write several applications in each. Or, more fairly, write the same application in each. Perhaps the old Pet Store.
By the time you’re done the libraries will have evolved and the critics will say you’re using out-of-date software. Then, of course, you will have used up far more time than you have available, and a major purpose for using the library was saving time in the first place!
Rational comparison is irrationally expensive.
Fred
That’s a very good point.
In all fairness to Prototype, I haven’t used it nearly as extensively as I have YUI, and it does provide some very nifty syntactic sugar. What’s worse, I personally know a lot of the people involved with YUI, and I’m sure that my high opinion of them as people colors my feelings about their work, even if I try my best to be unbiased.
However, I *can* say that I’ve interviewed and known with many Javascript developers who have worked with Prototype and Dojo. Take away their $, and most of them are useless. We internalize the paradigms we surround ourselves with. By comparison, I’ve also seen complete javascript novices (including a few non-yahoos) start using YUI, and by adopting the paradigms in the library, become much better javascripters.
The fundamental reason for this is obvious: YUI was created with the intent of extending the paradigms within the javascript language. Most other libraries were created with the intent of changing the paradigms of the language. You can’t learn russian by speaking french.
There comes a time in a project, hopefully as soon as possible, when you pick a framework and run with it. That decision is never fully informed, because that would make it pointless. The quality of the community and the documentation is key. In my opinion, YUI is a better library largely because it fosters a community that tends to be more knowledgeable about javascript in general, and because code that uses YUI will tend to be more understandable by anyone who knows Javascript.
Dojo’s chaining syntax is pretty and clever, but if you aren’t familiar with Dojo, it can be rather confusing. On the other hand, YUI’s structures, and the code that implements them, while a bit more wordy than Dojo, are also very clear, easy to optimize, and easy for any javascripter to understand, even if they’re not already familiar with YUI.
Most people seem to forget that the original motivations of libraries like Prototype, Mootools or Dojo was not “reinventing javascript” but rather address the extreme differences between each browser’s implementation of the language.
YUI does offer some utility methods, but you are always “exposed” to these browser incompatibilities. Prototype has changed the way to write javascript, but hasn’t changed the language. It’s just that by using their perspective on javascript coding, you can be pretty sure your code will run on all the browsers supported.
My (long) experience with javascript has not been the language itself, but the major deficiencies in browser implementations (IE, *sigh*). As a developer, I like to be productive, and my choice of library will be mostly based on the time I save “working around” those browser deficiencies.
How are you exposed to browser incompatibilities with YUI? The utils provide a replacement layer that replaces the DOM, Event, and XHR interfaces in a way that is both sane and cross-browser compliant. Additionally, it does so with as little effect as possible on any other code in the page (by minimizing the number of globals, for example.)
If you’re very familiar with the “standard” (that is, w3c-style) way of doing things, I’d recommend checking out Dean Edwards’ base2 library. Personally, I think the specified DOM API is crazy and ridiculous, as you could expect from any design-by-committee product, and that YUI’s interfaces are much more sensible. YMMV.
I’m with you on the libraries. In fact, I think the overuse of libraries has made almost all of us lazy programmers! Our quickly accessible knowledge is slipping away, making us weaker.
Lots can be said for the time saved not rewriting the wheel (or, cough, figuring out the various browser nuances) over and over again. Either way, I think YUI is terrific and I feel better for using it after your point about it producing better JavaScript coders.
Maybe. On the other hand, you keep on that line of logic, and you start to sound like the assembly programmers who claimed that C was going to make everyone forget how computers work. But you don’t use assembly do you? (Hell, I don’t even use C; all my server-side work is done in PHP. Usually, I’m programming in Javascript, which is about as far from the processor as you can get.)
There’s nothing wrong with using a library, even one like jQuery that may as well be a different language than “regular” javascript. I like jQuery a lot, actually. If you forget javascript, oh well; I’m sure a lot of C programmers forgot assembly. But, for now at least, you can get more jobs and more employees if you are using Javascript, and it’s a pretty powerful language in its own right. So why not use a library that accents it rather than replacing it?
We also prefer the Module Pattern vs. other alternatives…
http://blog.trendics.com/development/advantages-of-using-the-module-pattern-javascript-classes/
“I’d rather work with someone who is a bit green with Javascript but can learn, rather than someone who is an expert with Prototype or Dojo. The more time someone spends building applications with a library like Prototype, the further they get from Javascript, and the more dependent they become on the library. By contrast, time spent using YUI tends to breed developers who are experts in Javascript, and that skill is far more useful than being an expert in a particular library.”
Truthfully, I started with YUI and later switched to Prototype.js. I just love the brevity and flexibility that comes from Prototype. With prototype I can code in a similar fashion as in standard OOPs. Basically my thoughts and style are the same while I’m coding JavaScript or in C#, Prototype makes programming JavaScript … standard again while remains very JavaScript. I value consistency and easy to follow so that a year later I can still pick up my old code and understand it. With tricks like module pattern, do you think somebody who are new or even got some experiences to JavaScript can just look at the code and know what’s going on?
I wrote the the editor of TubeCaption.com with 100% prototypeJs (http://tubecaption.com/captions/demo). I did not even have to worry about differences between browsers. The first time I ran my code, it worked across all the browsers: FireFox, Safari, and Internet Explorer. I was really surprised too. Some thousand lines of codes later, Prototype is still saving me hours and hours of coding and frustration.
I don’t think I am getting away from JavaScript by using Prototype at all. In fact, I’m learning from the framework and JavaScript in general quite a bit while peeking through the code. PrototypeJS is a work of art with lots of craftsmanship in the code. I can’t praise it high-enough. The 1% percent that I need something else, I can fairly comfortably modify or tweak Prototype and Scriptaculous to suite my needs.
Of course I still look into YUI for inspiration and for the controls suite that YUI offers. Still, Prototype is my Swiss knife for web development.
Alex
I personally like what prototype-kin is doing with javascript. I find coding raw javascript boring. You’ve said that if I don’t like javascript I should chose another language to program. But the problem is, I don’t have a lot of choices. As you’ve mentioned, it’s the language of the net, you can’t change it, not easily.
I think using a library like prototype is the quickest/most reasonable solution for me.
Firat.
Great article! Great Point!
JavaScript Module Pattern at relaxdiego.com (beta!)
[...] Article from Foohack [...]
Very good article. Excellent points. Im a frontend developer not a Hardcore backend guy. I prefer Prototype because of short learning curve and compact code. YUI documentation was a bit too overwhelming for me.