In particular, David Mark makes some interesting points about the utility and elegance of framework code. I will not directly address these, but I hope I can explain a little about the value that I, personally, take from using Javascript frameworks instead of hand-rolled code.
Armin's first example is a little outdated. In jQuery 1.3, you can get rid of the
for loop in your first example by using jQuery's :header selector:$(function() {
$(':header[@id]').each(function() {
$('\u00B6')
.attr('href', '#' + this.id)
.attr('title', 'Permalink to this headline')
.appendTo(this);
});
});Also note that you don't need to use
document.ready; the $ function is overloaded (insofar as that is a meaningful statement in JavaScript), and adds an onready event when passed a function as the only argument.Personally, jQuery is my favourite library when taking into account such factors as authoring speed, concision, readability and utility. That said, Prototype will always have a place in my heart for its idiomatic yet practical approach to extending the core DOM repertoire.
Concerning the question of the initial code "hit" while 50K+ of minified framework code is downloaded and executed: we are fortunate that jQuery is now hosted on Google Code, which means there is a very decent probability that the library is already cached, and that if it is not, it is compressed with gzip to about 15K and downloaded via Google's own CDN.
However, Javascript frameworks are not really written with the aim of reducing overall download sizes. Rather, they are designed to rationalise development:
Speed
The most obvious benefit of using frameworks is that they dramatically reduce the amount of time spent writing or locating common "utility" functions—any old-school scripter worth her salt will no doubt have enough of these to rival jQuery! Having the functions already there is a very significant boon when it comes to churning out fast code
Good frameworks extend the assumed basic capabilities of Javascript in ways that are both natural and extremely useful. I consder the
each method (implemented by most of the better-known frameworks) to be a perfect example of this.Style
Most frameworks emphasise a distinctive approach to coding which is considered desirable, or at least useful in a particular context. For example, jQuery's function chaining is particularly idiosyncratic and powerful, as well as its predilection for smart method "overloading" and its approach to extensibility. YUI, on the other hand, is easily recognisable by its extensive namespacing; this distinguishes it from Prototype, which extends native browser objects (explicitly and implicitly) to add and appropriately compartmentalise functionality.
Consistency
Frameworks neatly abstract away many browser bugs and inconsistencies (need I mention event handling?) without beleaguering programmers further. Such quirks and oddities were significant factors in the low opinion that many programmers have towards Javascript in general, and their elimination over time (and through effort) has gone a good way to repairing that reputation.
Projects big and small benefit from the power and consistency that frameworks introduce. What is more, as well as speeding up experienced scripters, frameworks enable new programmers to start writing decent, useful code far sooner than they otherwise might. The last three responses to Armin all emphasise the need for best practises and technical mastery, and rightly so; however, many developers do not have the time (or patience, or even raw capability) to do so to the extent that their projects would otherwise require, and for these people, Javascript frameworks are a godsend. I include myself in this group: while I have written many interesting and reusable scripts for various common tasks such as animation, validation, drag-and-drop and event handling, I cannot consider myself to be a Javascript guru, and am indebted to jQuery (and, of course, the jQuery developers themselves) for enabling me to achieve goals which would otherwise take me five times longer without its help.
That, in a nutshell, is why I agree with Armin, albeit on a broader point: Javascript frameworks are the answer, and will only become more relevant as our expectations and requirements expand.
