What's your favorite JavaScript framework?

[WA]

I'm starting to get into jQuery, and just wondering what some of you like and use the most. I'm talking general purpose JavaScript frameworks. Is there one that is a clear winner for you, and how so?

[shyam]

i was hooked to prototype...but having discovered jQuery's css selectors i've never looked back

[oesxyl]

I'm starting to get into jQuery, and just wondering what some of you like and use the most. I'm talking general purpose JavaScript frameworks. Is there one that is a clear winner for you, and how so?

I don't find one I like. Oat seams to be somehow my winner, :)

http://oat.openlinksw.com/

Are still many things I don't like to oat. Maybe a thread with what is good/bad to frameworks could be relevant, :)

best regards

[jkd]

I like whatever framework I develop for the website. With really intensive GUIs, I find most generic framework code to be too slow.

[WA]

I've yet to look at Prototype closely, mainly because of its relatively large size. Just wondering, compared to jQuery, how is it "better" or more robust, given it's much larger footprint?

[A1ien51]

Most people move to JQuery from prototype. I know some die hard prototype people run TO JQuery after using it.

Once you get the hang of JQuery, it is very fun to code in.

If you want some books on JQuery or Prototype, my friends have books out on them which are very good reads:

JQuery In Action (http://www.manning.com/affiliate/idevaffiliate.php?id=484_93)
Prototype and Scriptaculous in Action (http://manning.com/crane3/)

Eric

[WA]

Most people move to JQuery from prototype. I know some die hard prototype people run TO JQuery after using it.

So what's the primary lure of jQuery for these people versus Prototype?

[A1ien51]

So what's the primary lure of jQuery for these people versus Prototype?

jQuery focus is heavily on DOM manipulation and traversal. So that is the big draw for a of people that do not want prototypes "Ruby" syntax of doing things.

This example here shows you why your fingers can hurt a lot less with JQuery: http://jquery.com/blog/2006/10/18/zebra-table-showdown/

Eric

[GJay]

I'm a big fan of Prototype, it just seems to make the most sense to me. Pretty much everything I do now makes use of it's Class and inheritance system which makes code so much easier to follow for other people, and much easier to modify.

Looking at the updated bit of the zebra-tables example shows that prototype's CSS selection and manipulation is pretty much the same as jquery's.

Once you're gzipping your javascript, the filesize of the libraries becomes pretty insignificant, so whichever fits your programming style (and in a team environment makes it easy for others to pick up) should probably be more of a concern.

[richApps]

I recently discovered jQuery and I've become a big fan. It's just amazing how much you can do with very little code. The syntax is very elegant and the chaining of statements is a big time saver.

Most of my apps / pages now integrate jQuery. You can find some of these at http://richapps.googlepages.com/

-Pablo

[EricaStar]

Yahoo User Interface, gives plenty of sample code and documentation. As a beginning javascript developer that is exactly what I need. If you are experienced in programming techniquest (from other languages) and are now taking on javascript, YUI is excellent for practicing and developing your javascript skills.

[Isaak]

I chose for jQuery because the code is so compact, the community is great and the framework is just unbelievable awesome (perhaps slightly exaggerated).

[fside]

I chose for jQuery because the code is so compact

I suppose what's need is speed, not interpretation. Would it really matter with these scripts - if they able to be precompiled and run in IE, FF, Safari, etc?

[fside]

JQuery In Action (http://www.manning.com/affiliate/idevaffiliate.php?id=484_93)


Compare to Apress ebooks. They sell theirs - for $10. I'm not even sure if they check for receipts, just that you have an ISBN and a copy of the book nearby (don't quote me on that).

[Kor]

What's your favorite JavaScript framework?
None. I don't trust libraries or frameworks. I code everything by hand and using my own "subroutines" tested as crossbrowser (which I try to keep up-to-date). Thus I am able to create exactly what I need for the designed custom purpose. No more, no less. In short time. That saves my time, my money and :D my nerves.

[1andyw]

I code everything by hand and using my own "subroutines" tested as crossbrowser (which I try to keep up-to-date).

Are these available for public access?

Andy

[Kor]

Are these available for public access?

Andy
All the javascript codes are available for public access with View Source. Mine are as well, whenever you open a site with my codes. :rolleyes:

The genuine question was: "What's your favorite JavaScript framework?". I answered, frankly :none. And I said why. That is all. :)

[Skyzyx]

So that is the big draw for a of people that do not want prototypes "Ruby" syntax of doing things.

Personally, I LOVE the Ruby-like syntax. I'm not a Ruby developer, but I love how Prototype *feels* when you use it... like all is right in the world.

Lately, I've been using MooTools as it's smaller and faster than Prototype + Scriptaculous, but still maintains a very Ruby-like feel.

I don't like YUI at all because it feels very JavaScript-like, and JavaScript can tend to be pretty clunky to use. The YUI team is lead by Doug Crockford who is a JavaScript guru, but also favors "programmatic perfection" more highly than usability or how comfortable it feels to use.

[jkd]

I don't like YUI at all because it feels very JavaScript-like, and JavaScript can tend to be pretty clunky to use. The YUI team is lead by Doug Crockford who is a JavaScript guru, but also favors "programmatic perfection" more highly than usability or how comfortable it feels to use.

What do you mean by clunky? Prototype *is* JS; it just uses an idiom more commonly found in Ruby (not JS's fault that most people who write it don't have a clue about coding). JS is my favorite language precisely because I have the option of using idioms from functional languages, OOP, and plain old procedural programming, whenever one is most appropriate (I think recursion is always appropriate :)). Anyway, I am curious about this "programmatic perfection" versus usability trade-off... do you have an example?

[Skyzyx]

Okay, so "feels like JavaScript" was probably the wrong way to describe it, and by "clunky" I mean something along the lines of "inelegant".

As far as YUI and Prototype:

1) Getting a DOM element by ID (a la getElementById):
YUI: YAHOO.util.Dom.get();
Proto: $();

2) Getting a DOM element by classname:
YUI: YAHOO.util.Dom.getElementByClassName();
Proto: document.getElementByClassName() (optimized for JS 1.8)

3) Getting a DOM element by CSS selector:
YUI: YAHOO.util.Selector.query();
Proto: $$(); (optimized with XPath support)

There are far more examples of syntactic sugar that Prototype (and MooTools, and jQuery, and...) provide over YUI that I don't have the attention span to type out here.

Now yes, you can do:
var $ = YAHOO.util.Dom.get();
to shorten up the function, but this is "discouraged" because it litters the global namespace. Programmatically perfect (or at least well-intentioned)? Yes. Easy to use? Not so much.

YUI Docs: http://developer.yahoo.com/yui/docs/
Prototype Docs: http://prototypejs.org/api/

[liorean]

I always thought $ looked hideous in code anyway. Just like underlines do (a feature of Ruby that i really dislike is the use of under_lines instead of camelCase). I prefer the syntax of the 1kDHTML API (by Chris Nott), but extended with more utility functions, and put as methods on an object instead of as global functions.

[Kor]

Ha... Big discovery getElementsByClassName() :rolleyes: And do I need a JS Framewok for that? :eek: No Sir, I can write myself such an constructor within seconds

function getElementsByClassName(c){
var allO=document.getElementsByTagName('*'), objs=[], i=0, o;
while(o=allO[i++]){
o.className==c?objs[objs.length]=o:null;
}
return objs;
}


I don't need a library which, after all, uses a similar code (as there is no other reasonable alternative) for that. :)

[Kor]

Maybe people who use often Frameworks and libraries are too lazy to perform a professional Object Oriented Analysis followed by a neat Object Oriented Design before they start to build a site. They prefer to engulf an "universal" library first at all, and think later what in fact they have to do, probably no more than a simple roll-over. :)

That reminds me of the faux prince Tom (in the novel "The Prince and The Pauper" by Mark Twine) who used to crack nuts with the Great Seal of England.:rolleyes:

[fside]

Programmatically perfect

What you have with these libraries - are dialects. What is the dollar sign? In one it's the 'new' DOM element by id. In another it's a gang of 'em. In another, maybe it's something more.

As long as you know what the function is, it need not go in the global space. Just surround the code with an anonymous function. The top link of the hierarchy outside can be declared outside, or inside as a member of, window.

My take on libraries is that they might work, and be cross-browser corrected. But the modules interest me. I guess you could say that I like 'harvesting' various functions. Once you have a module, it's worth keeping in your code. I don't use the libraries, in their entirety. I just prefer to write my own scripts. These modules can also point out things one might have overlooked. They might even be superior technique.

[Kor]

Better learn javascript, mates. You will discover that things go faster and better when you learn the language itself, not the pseudo-classes libraries or frameworks could invent.

[jkd]

To be fair, using a framework takes the cross-browser guess work out of the equation. For minor projects I would consider using jQuery, though I would otherwise roll my own code.

[sybil6]

learn javascript, frameworks are much of a hype

[jaywhy13]

I'm a recovering Dojo user... I'm completely into jQuery. Right now, it's the best thing next to sliced bread.

[fside]

learn javascript, frameworks are much of a hype

There is certainly hype. And you can buy books on the shelf for JQuery and Prototype, maybe YUI, etc. There are so many of these libraries, now.

A) Some companies insist upon one or more libraries. So their staff have to use them.

B) There are some things that may be done which are better than you yourself were planning. There is some interesting stuff in these libraries.

C) They can save some work. And while you are working on your part of a project, these and other guys are working out future compatibility problems with their library, so you don't have to, at least as long as it interests them.

It'll be interesting to see how it 'shakes out' in a few years. Will a lot of this just be standard ECMA or DOM by then? Scripts for animated sliding could easily be system level, same for closure 'binding', or elaborate class-rule searches. Some of that probably is going to be part of the next ECMA.

On balance, it's not so bad, the scripts. The overhead would be parsing, not loading. Even small images are already far bulkier than a lot of serious and complete libraries, even before they are gzipped.

[Kor]

A) Some companies insist upon one or more libraries. So their staff have to use them.

There is no such an entity "companies". There are only some rookie managers who have no idea what a programming language is and believe that web developing is a sort of writing documents in MS Office.

B) There are some things that may be done which are better than you yourself were planning. There is some interesting stuff in these libraries.

Never if you are a good programmer. Frameworks are made for lazy and weak programmers.

C) They can save some work. And while you are working on your part of a project, these and other guys are working out future compatibility problems with their library, so you don't have to, at least as long as it interests them.

Apparently you save some work. There is no universal framework, thus you always should customize something here and there. At this point you will spend more time than if you would have build the application in clear clean javascript. Working with a framework is hard enough, as it uses a lot of custom "unnatural" methods. If 2 or more people work on the same project on the same framework the errors probability will be multiplied with 2 or more.

It'll be interesting to see how it 'shakes out' in a few years.
The evolution trends to an opposite way. Javascript might become a combined language, class-oriented and prototype-oriented (now is only a prototype-oriented). In this case, all the frameworks and libraries will become history :)

Believe me, some time ago I worked for about a half year for a huge project along a lot of people, on using Ruby On Rails and Scriptaculous. It was a nightmare. What I was to develop during the day, a colleague was to spoil during the night and bacwards. The specifications frequently overpassed the framework's possibilities. Almost nothing was really crossbrowser in the end. We all became nervous and paranoid. I swore I will never ever repeat that experience again :rolleyes:

The last autumn I had a similar project. I managed to make it in 2 1/2 months, alone (the client-side part of the project), without any frameworks or crazy libraries. Clear HTML, CSS, javascript, AJAX, PHP, mySQL.

[Bill Posters]

Ha... Big discovery getElementsByClassName() :rolleyes: And do I need a JS Framewok for that? :eek: No Sir, I can write myself such an constructor within seconds
function getElementsByClassName(c){
var allO=document.getElementsByTagName('*'), objs=[], i=0, o;
while(o=allO[i++]){
o.className==c?objs[objs.length]=o:null;
}
return objs;
}

I don't need a library which, after all, uses a similar code (as there is no other reasonable alternative) for that. :)
Your method doesn't catch elements which have multiple classNames which include the targeted className.

e.g. Your method would only catch the first and third divs.
getElementsByClassName('book');

…

<div class="book">…</div>

<div class="book thriller">…</div>

<div class="book">…</div>
I'd consider that a major flaw in your method, rendering it unreliable and consequently unusable.

With all respect, I'd say that you could benefit from reassessing whether your own methods compare favourably to the published alternatives included with the prominent frameworks.


Fwiw, my own, pre-jQuery take on getElementsByClassName was as follows…
var libJS = {

hasClassName: function(obj,cName) {

var cNameRegEx = new RegExp('(^|\\s)' + cName + '(\\s|$)');

return (obj.className && obj.className.match(cNameRegEx));

},

getElementsByClassName: function(cName,trgtTagName,trgtNode) {

// Require: libJS.hasClassName

if (!document.getElementsByTagName) return true;

var tName = (trgtTagName) ? trgtTagName : '*';
var tNode = (trgtNode) ? trgtNode : document;

var trgtEls = [];
var trgt = 0;

var els = tNode.getElementsByTagName(tName);
for (var i = 0, tEl; tEl = els[i]; i++) {
if (libJS.hasClassName(tEl,cName)) {
trgtEls[trgt] = tEl;
trgt++;
}
}

return trgtEls;

}

}
A while back, I had my own, brief library of common functions (http://dev.akabillposters.com/dom-js/_library_final/lib.js), including the above.

I broke down certain functions into reusable components. The hasClass was reused by my getElementsByClassName, addClass, removeClass and toggleClass functions.

Note that hasClass catches targeted classNames used by elements which have multiple className values.
The equivalent methods in YUI and jQuery both catch targeted classNames when appearing within multiple className values.


I switched to YUI for a while, prefered on account of its clear DOM structure and the trustworthiness of the code*.
However, in more recent times, I've become a jQuery user by default, seduced by the selector-based approach (and the lightness and modularity of the core code compared to Prototype).

* I find the notion that you don't 'trust' frameworks a little odd, given that those such as YUI and jQuery are written by those who are likely to know far more about js than either you or I. Taking your majorly flawed getElementsByClassName method as an example, it's even more ironic that you don't trust the major frameworks.
In the case of YUI, they have extensive browser-testing processes which produced their 'graded support' model. In the case of jQuery, they have an outstanding js-er at the helm and an extensive community able to identify and remedy browser issues.

So, whilst it might satisfy me to grown my own, in practical terms what's offered and backed up by frameworks such as YUI and jQuery beats what I can achieve by a country mile. The satisfaction of reinventing the wheel is trumped by the reliability and sheer expedience of certain frameworks.


You seem to have an awfully lot of bad things to say about frameworks and those who use them. Alot of the stuff you say on the subject is simply ego talking, common misconceptions about framework users and completely misses the value that using a framework can add to a project of any decent size and expected longevity.

I think that there's a great deal that you're missing, not only about established, 3rd-party frameworks, but also about your own coding skills.

[Kor]

It was only a quick example. It is awfully easy to create a prototype in order to retrieve multiple className as well. No, thanks, I don't need frameworks for that either.

Alot of the stuff you say on the subject is simply ego talking, common misconceptions about framework users and completely misses the value that using a framework can add to a project of any decent size and expected longevity.

Nuts

[Bill Posters]

It was only a quick example. It is awfully easy to create a prototype in order to retrieve multiple className as well. No, thanks, I don't need frameworks for that either.
Setting aside that the W3C DOM is, itself, just a framework…

Awfully easy? Your flawed example suggests otherwise.

Despite your experience, you failed to remember to account for it, thereby demonstration the frailties of attempting to reinvent the wheel every time, rather than demonstrating the superiority of self-written functions, as had been your intention.

My point is that you should perhaps open your mind to the fact that there are people out there, with vast experience using and developing for js, who appreciate that there can be considerable value in frameworks.
Or do you consider people such as John Resig, Dustin Diaz, Nate Koechley, Doug Crockford and those at the YDN to be lazy, weak developers?
Do you consider the developers behind these sites (http://docs.jquery.com/Sites_Using_jQuery) to be lazy, weak developers?

If so, what impact do you think it's likely to have had on their output or the effectiveness of the sites in which they've utilised js frameworks?


Of course, having a solid foundation in js can only help (in the event of bug occuring in the framework itself).
I completely agree that frameworks work best in the hands of those who do have a solid, though not necessarily exhaustive, foundation in js.
However, imo, there's absolutely nowt wrong with using a framework shorthand to enable developers of all levels to expedite the development process or to open a project to progressive enhancements from which the project might benefit, but which the budget or time restraints would otherwise rule out.

If you're happy writing your own 'DOM Ready', AJAX requests, class handlers and assorted other functionality every time, go for it. But, that's a personal thing and has little, if anything, to do with supposed limitations of frameworks or those who use them.

Sure, there are going to be a fair amount of framework users using it because they don't know how to do it well using the W3C's own API, but there are significant numbers out there using them because they'd rather get on with the job than waste time trying to impress either themselves or their peers with their js ninja skillz.

Nuts
Now who's being lazy and weak.
I'd say about as much thought went into that as went into your getElementsByClassName function. ;)

[jkd]

I feel like Javascript programmers are among the only coders who insist on reinventing the wheel for every website (myself included). In reality, there is no need to rewrite a bulletproof XMLHttpRequest wrapper every time you need to send data to the server, yet we still feel the need to do it. I think it is because for a long time, very few people actually knew how to write good Javascript, and we've learned not to trust others. Big archives like DynamicDrive don't do much to inspire it either, but lately I've been willing to accept that JQuery just might be alright, and that instead of rewriting methods I perceive I can do better, maybe I will just rewrite their methods and resubmit it.

[Bill Posters]

I think it is because for a long time, very few people actually knew how to write good Javascript, and we've learned not to trust others.
That's a very good observation and certainly rings true for me.
I like to take pride in the quality of my coding output and it took me until well after the initial frameworks hype to even dip my toes in a framework (YUI).

The abstraction of jQuery seemed too alien and I was resistent, but I gave it a go and it does make life easier in terms of moving from idea to implementation without compromising on reliability.

[snoodle]

Wow. This is the first time i went through all the entries in this thread. I find it all very interesting having spent the better part of the past year going from framework to framework, and working on my own in between. Ruby/Rails, CakePHP, prototype, dojo, ExtJS, etc, etc, etc... they all have their brilliance in their own right. I came really close to going with Ext but in the end, I just couldn't quite commit (sounds like my relationships). One day, I decided I would make JQuery the project of the day, and by the end of the session, although I was starting to "get it", a lot of the code I was looking at just looked a bit too cryptic. After a few more days I was hooked. The terse coding and DOM manipulation is exactly what I was after in my own framework. Access to pre-fab plug-in widgets that fit your needs without any or little modification is nice, but not a real convern or goal for me. I'm a widget kind of guy and don't mind recreating the wheel here and there. As somebody said in something I read recently, the DOM is already a framework, so a thin layer, like JQuery, that allows you to perform many functions in a short line of code is perfect for me. The jury is still out regarding JQuery U/I and the plug-ins. I'll know more as days and weeks unfold.

The only problem, so far, that I'm having with JQuery is their forum. I love codingforums.com. There are some pretty smart people out there and they're usually pretty responsive and forthcoming with info. So far the JQuery forum, which, if I'm not mistaken, uses google's forum deal, just ain't the same; at least not yet.

Anyway, in answer to the question, as of today, JQuery is the winner for me. The developers really "got it" when it came to Javascript, or even did things to javascript that the original developers never saw coming.

[Kor]

so a thin layer, like JQuery, that allows you to perform many functions in a short line of code ...
It's an illusion. Ok, I accept that a framework could be a an acceptable tool when you are in a big hurry and you have not your own subroutines. But for a certain job there are the same line of codes (in fact more) already written in a framework, except that they are written elsewhere, in the main library. It's like the law of conservation of energy. You can not shrink a javascript code more than the language itself permits. So that a framework does not bring a shortage of code as you may have thought... :)

[snoodle]

What's an illusion? What do you mean by bringing a "shortage of code as you may have thought"? I took the time to learn DOM, Javascript, PHP, and SQL (I already knew SQL). That along with almost 40 years of programming experience has given me the ability to understand what's holding up the JQuery code I'm writing (not to mention, simply looking at and tracing through their source code).

The comments on terse code refer to what I have to write. As far as how many machine instructions are taking place to carry that out, well, if it's few enough to result in responsiveness that is good enough for your needs, then who cares. The idea is not necessarily shrinking the entire piece of code, it's shrinking the code I have to write. Then, of course, there's the community you get to talk and exchange code with.

As far as being in a hurry, if I had to whip something together today, my fastest way to get there would be using my own framework, which I know inside-out. But everything in my framework doesnt' work on all the "A" browsers, and is simply nowhere as complete as JQuery. Not to mention, I knew that learning JQuery would help continue my education of Javascript, which it has.

Perhaps I didn't understand your comments. Where is the illusion part? What you talkin' 'bout, Willis?

The core of JQuery is actually quite small. JQuery UI and the many plug-ins that people have contributed may be where all that code you're referring to resides, and it is totally reasonable that one would not use some of those widgets, even recreating the wheel on ocassion. It's the core, the essence of JQ, the part that lays out the basic core architecture that your project will be built upon that I'm interested in (that and ongoing browser independence).

[Kor]

Once again. JQuery is nothing but javascript in a library. It does not make shorter codes than javascript language supports. It is an illusion to think that JQuery (or whichever framework or library) is able to invent fewer and shorter code lines than javascript is able to use. That is all.

JQuery is not a new version of javascript. Nor another client-side language. It is only a half-prepared javascript. Javascript fast-food.:)

TI took the time to learn DOM, Javascript, PHP, and SQL (I already knew SQL). That along with almost 40 years of programming experience

40 years ago Timothy John Berners-Lee, the father of HTML, was only a 13 years old child, so I seriously doubt there were any DOM, Javascript a.s.o. at that time... :rolleyes:

Sir, you are not the only programmer on the world... I work also as a client-side programmer (along with php/mySQL) and a web designer for a long time (well, not for 40 years... :rolleyes:, but enough to have seen the IE3 and NS4 on work) so that I might have some experience as well.:)

[snoodle]

Who said anything about programming DOM 40 years ago? I was typing BASIC on a PDP-4 (or whatever it was) with a paper tape and a teletype. How can you make a remark about me being the only programmer in the world when you are the one shunning other peoples code. From your previous posts it seems you rely more on your ego than your experience - at least when it comes to coding.

Anyway, I'm sure you are a very nice fellow. But... what happened to your answer to my question about your "illusion" comment? How could you confuse "40 yrs of experience" with 40 years working on DOM, javascript, etc. It appears you prefer talking to listening; which makes perfect sense as far as your relutctance to learn some other person's nightmare that is supposed to make your life easier (ie framework). I say nightmare because I'm actually the same way. Most of my early apps were in pure assembly. Why, when I was a boy we had to write our own floating point math routines.

I felt very much the way you describe for the past year, as I muddled through the various frameworks. I always ended up going back to my own to get something done. I hated the bulk, unknown code in my project, and having to learn someone else's ways. But... are you telling me that there is nothing to be gained by all the JQuerys and Prototypes and CakePHPs, and on and on? You haven't, at least, learned from them? I know about the piles of crappy javascript code on the internet; I'm not talking about that stuff. I'm talking about the developers of the top shelf frameworks. Don't you think some of these people are pretty brilliant and put their hearts and souls into their creations? Shoot, I may end up going with my own framework in the end, but right now I am intrigued by JQuery, and it has been the best teacher of the finer points of javascript for me of any book or framework. No matter what, I have great respect and admiration for the developers.

Anyway, I'm not in the mood for an online fistfight. I'm here to learn. My many years of experience involved little internet programming. Javascript and PHP and ajaxing between the 2, are all new concepts for my aging peabrain. If you have something to offer me in the way of educating me about the ways of the web, or telling me something I don't already know, I want to hear it and I very much appreciate it, regardless of how arrogant or annoying you may be in your delivery.

[snoodle]

OK, shoot me. I think I'm with Kor. I just spent all day and night using JQuery to put my site together. By the time I've recreated the functionality I have in my own framework+application I'll be even older than I am now. Much. Things like floating palettes and login/authentication, admin controls and reports, scrolling lists, tables, a generalized mechanism for viewing DOM tables of sql-tables (including joins and other goodies), etc, are tough to come by, and I've already done all this stuff. JQuery is kind of cool but the plug-ins aren't really quite there yet, I think. Although I don't have everything JQuery has in its core, and I probably won't support as many browsers (maybe), my framework is OOPS and clean and fun to use (especially since I don't have to go googling every few minutes for samples, explanations, or places to post questions).

I guess the other consideration is whether you want to join a huge group of programmers you don't really know (yet) and get into contributing and sharing code (plug-ins). I actually would like that, just not right now I guess.

So I am going back to my own framework once again, but I still have learned much from JQuery and might end up back again for all I know. I apologize to Kor but I still find your comments... well... who cares. Everyone's entitled to their own style I guess; codewise and otherwise.

[Kor]

Q.E.D. :rolleyes:

[snoodle]

Y.a.c.

[jkd]

This semester I took a graduate level computer graphics course; the professor was the guy who wrote the seminal textbook (http://www.cs.brown.edu/~jfh/papers/vanDam-CGP-1995/main.htm) on computer graphics.

We were implementing seam carving for one of our projects, and he remarked that we could choose to use C++ or Matlab. Now, he also remarked that Matlab would do it fairly quickly, but not as fast as C++ could. He continued, however, and noted that it would be silly to write it in C++ because it would only take a couple hours to write in Matlab while it would take a day or two in C++. After all, what's more important -- expensive programmer time, or cheap CPU time?

I think the same thing can be said about using frameworks. There is some inherent overhead in using them, but it can save you or your company a lot of time by providing functionality for you.

[o0O0o.o0O0o]

X.v.T :D

[ahallicks]

I've found that, whilst learning javascript from a very very weak point (where I basically knew next to nothing), the easiest Framework I've manged to click with has been the YUI because it has great documentation, is very easy to read, and I've found very easy to write. Maybe that's because it's written in a very 'javascript-like' way, but that suits me for now as one who is merely learning the language. Once I have a very firm grasp of it I will look elsewhere, but I can safely say that i have completely gotten to grips with DOM in javascript thanks to YUI (and personal experimentation) as well as namespaces and many other aspects of the uses and manipulation of web pages via javascript.

I've begun looking through the sample files and framework files to see how they have written things and it's all fairly easy to understand, so coming from that point of view (of one who still has a lot to learn) the YUI has made the journey so much easier than I found jQuery could do.

[dicicco2]

I've worked in AJAX land for just over 2 years. Over those 2 years I have come so close to the DOM that I sometimes have dreams about it. I created a couple libraries that helped me pretty significantly in cutting down some code and cross browser deficiencies.

But now, over the past couple months I have come in tune with jQuery. I've let my inhibitions loose and am diving in. My libraries were great and all but the fact that jQuery has a full time team working on it and strong community support I can't help but give in to the fact that it saves me time. The overhead of keeping my own library stable, standards compliant, and new features being added are just too much.

So for all you DOM scripting, AJAX beginners, here is a good path to go down:
1. Spend a couple months not even thinking about a library, just using standard DOM scripting on your sites (you'll be much more grateful when you start using a library like jQuery to see how many less lines you have to write).
2. Think about some ways to cut down the code yourself, consolidate it, make it reusable(creating your own mini library).
3. Understand that you can't do everything yourself. Realize the benefits you will have from using a widely prevelant library like jQuery.

[NancyJ]

I've recently switched to jQuery from prototype. I just got fed up with prototype + scriptaculous' ever increasing file size - up to 300Kb for the whole thing, which is ludicrous for what I'm using it for - I probably don't even use 1/10th of the functionality but my attempts to slim it down to just what I need failed since every bit is dependent on another bit.
jQuery on its own is about 30% smaller than prototype and they provide minified and packed versions for you. (plus prototype can go a bit funky when you try to minify it)

I also find the the jQuery documentation is much better. I've never really used the prototype docs site because its basically unusable, I've never found anything helpful there