What's your favorite JavaScript framework?

[1andyw]

Originally Posted by Kor

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]

Originally Posted by 1andyw

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.

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

[Skyzyx]

Originally Posted by A1ien51

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]

Originally Posted by Skyzyx

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() And do I need a JS Framewok for that? 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.

[fside]

Originally Posted by skyzyz

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]

Originally Posted by sybil6

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]

Originally Posted by fside

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.

Originally Posted by fside

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.

Originally Posted by fside

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.

Originally Posted by fside

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

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.