JavaScript Newbies: Beware of libraries
With the vast emergence of JavaScript libraries like Prototype and those of which extend it like Open Rico, Behavior, Scriptaculous, and even Moo.fx which was built on a light version of prototype; I feel the need to warn Web Developers that have been decoupled from the world’s most misunderstood language to backoff just for a little while. This is no way intended to veer developers away from such brilliant frameworks that can immensely aid in the development process for web applications, but the fact of the matter is: That’s what these libraries are for; Web Applications
.
Instead, I would recommend just one little piece of advice before adding 100k to your web documents.
Learn JavaScript First
Seriously. It’s for a developers own good. When Peter-Paul Koch published his feelings on addEvent() considered harmful, it was aimed at novice developers who were unaware of the logic behind how it works. The initial goal of the addEvent() function was to mimick event attachment in a cross-browser friendly manner. However it includes different browser objects which in fact do not behave the same (eg. addEventListener vs. attachEvent vs event handlers). And that’s just one function! Let’s consider a framework like Prototype…
Prototype: JavaScript rewritten
If you’ve peaked at the underlying objects of Prototype, you may have noticed its frequent use of methodizing common functionalities. What does that mean? Let’s take a look at the Element Object and just a few of its methods.
Prototype Element Object
toggle: function() {
for (var i = 0; i < arguments.length; i++) {
var element = $(arguments[i]);
Element[Element.visible(element) ? 'hide' : 'show'](element);
}
},
hide: function() {
for (var i = 0; i < arguments.length; i++) {
var element = $(arguments[i]);
element.style.display = 'none';
}
},
show: function() {
for (var i = 0; i < arguments.length; i++) {
var element = $(arguments[i]);
element.style.display = '';
}
},
remove: function(element) {
element = $(element);
element.parentNode.removeChild(element);
},I thought to myself “You gotta be kidding”! They’ve rewritten the way we think how to do such simple tasks. If I wanted to remove an element, it’s simply become this:
Example of Removing an Element
Element.remove(object)Albeit its terrible usefulness and simplicity, what’s one to do if they don’t have prototype.js sitting on their file system? I would hate for a developer not to know that all you really need to do is grab the parentNode and run removeChild() on the element…just two references to basic DOM methods.
Lesson Learned?
Read up. It will make you a better developer in the long run. Ninety percent of the time, you won’t be building web applications anyway. You’ll be building web documents where JavaScript (in practicality) should enhancement your webpages, and in contrast not be dependant upon.
November 8th, 2005 at 9:55 pm
Well, for the software engineers and visual designers who don’t want to hire a front-end developer, these libs are very useful.
What worries me is the lack of a standard, ala the Java 2 Standard Library (or whatever it’s called) from which an application can build upon. These libraries attempt such, but how can you measure the quality of ad hoc code? Maybe if the various browser developers followed and implemented the W3C properly (i’m not up-to-date on such) then maybe we’d have less problems. A good first step, but ultimately not a long-term. But I hope someone proves me wrong.
Just .02
November 9th, 2005 at 12:09 pm
The really problematic issue is not only the added 100k to the bandwidth, but the tax on a client’s memory. To take something that already exists in the DOM or other built in JS functionlity, and copy it into an object is just wasteful in memory terms. While memory management is not a prime focus to most JS developers because JS takes care of it, you’d kill yourself in a language like Java if you built things like the examples Dustin gives.
OOP is wonderful, but it must be used with care. When writing classes, think about how necessary each property and method really is within the class and remember that everytime you instaciate that class into an object, you use memory–then, second guess yourself about how necessary it really is.
November 9th, 2005 at 12:21 pm
Well, I guess if you’re writing a wild Ajax application which does not re-render the web page and just makes behind-the-scenes requests, then you will have deal with memory leaks.
I’m not sure of the behaviour, but I reckon memory is freed when requesting a new webpage that paints screen. Large-sized libraries can be cached in the client (under normal circumstances) after initial download. Yes, the request for the same JS file, returning a 304, is yet another request, but at least you’re not downloading the same 100kb lib.
The real bottleneck is bandwidth. If an infrastructure to provide bigger pipes were in place, maybe some of the websites / webapps would / could be more robust. Yes, that’s idealistic, but I reckon Google wouldn’t have it any other way =)
just more thoughts.
November 9th, 2005 at 1:12 pm
A few things just in defense of scriptaculous and prototype: they’ve gone through great lengths to prevent IE memory leaks and eventDisattachment etc as best as possible.
Other notables is that the libraries have yet to be crunched, so you might be able to get them down to roughly 75K (which is like a large image). On top of that you can send http compression (however IE will fail to cache that kind of compression).
Lastly, scriptaculous has rewritten their infrastructure so that you can choose to insert only the functionality you wish to leave out, eg: if you only wanted th effects, that library is only 30k or so.
Nevermind the matter, I still stand by folks learning the language before implement these libraries. In a way it’s like jumping straight to a WYSIWYG Editor without knowing HTML or CSS.
November 9th, 2005 at 1:59 pm
To clarify, it’s not memory leaks that I am concerned with. It’s simply the fact that instanciateing objects uses memory, just like doing anything else in programming. The more objects you instanciate, and the larger they are, the more memory you use. On top of that, it is often true that a large object is instanciated only to access one or two properties or methods.
Like I said, in JS this is less of an issue. But it’s something to think about in any OOP language.
November 9th, 2005 at 5:43 pm
Funny, I was thinking the same thing the other day when I launched the redesign: do I use a library or throw together something of my own?
I was inclined to wait and have a hard look at the libs before I do anything…
November 9th, 2005 at 6:15 pm
Mike, by all means, these are all great libs. See Steve’s Search who did some nice stuff with scriptaculous.
If you really know what you’re doing, they can be your best friend.
November 11th, 2005 at 6:40 pm
For a good look at how to rethink standard Javascript code into a nice Object-oriented flavor (using Prototype.js) see the book Ajax in Action. Darren James, one of the authors, is the architect of Rico. Darren is a fellow Yahoo! and is on the awesome Y! Mail Beta team (former oddpost).
I believe it is Chapter 10. Very concrete example.
Darren is one of the best at simple design & object-orientation. He cut his teeth on C++ and Java. And had about 15 yrs of OO experience.
November 12th, 2005 at 4:36 am
Though the point is absolutely valid, I would prefer a novice utilise a library than attempt it on their own.
The fact of the matter is, the majority of people writing websites probably don’t understand JavaScript to an adequate level to do it ‘right’. If the library author does, at least the novice will be, even if unknowingly, author something that is compatible.
Al
November 13th, 2005 at 4:10 pm
Bill,
just ordered it last week and came in yesterday. I briefly went through the introduction pages and the first chapter. This book is definitely meatier than i thought it was going to be.
December 12th, 2005 at 8:28 pm
I admit you are right ,but people are too hesitate to develope a product ,so they use something the did not understand.
I personnally like rewrite things,but I have not enough knonledge ,I will learn more form your blog and the Internet!
3x
March 3rd, 2006 at 4:57 am
It would be best to add JQuery from your list.
Comparing $() … with Prototype (w/c is a simple document.getElementById ). In JQuery, it made the paradigm easier (accessing/manipulating the element object), BUT certainly inadvisable to newbies trying to grasp the Javascript Objects and DOM.
November 6th, 2006 at 9:06 pm
[...] You’ll notice just by looking at the source JavaScript files that I’ve used scriptaculous. One of the downsides of scriptaculous is the large download required. A solution is to compress the JavaScripts, but that is outside the scope of this article. Furthermore, Dustin Diaz says to avoid JavaScript libraries, but the slider control for scriptaculous was just too tempting to resist. [...]
November 17th, 2006 at 9:34 am
While I do think that it is important that developers learn the underlying workings of javascript, I see nothing at all wrong with developers using wrappers such as prototype to not only speed up the pace of their development, but also to bridge that huge and horrible standards gap that Microsoft is constantly leaving in it browser. One of the great things about prototype is that its methods work in a crossbrowser way. They have managed to find “most” of the differences between javascript and jscript (the ms way) and they have created tight little methods that will work in both. As far as I’m concerned the scripting world has long been in need of libraries like this.