How to choose JavaScript framework

You have probably found many articles describing what are requirements that one JavaScript framework has to have. Some of them are (they are not listed in any particular order):

• list of supported browsers
• documentation
• community
• intuitive API
• speed
• extensible

and so on.

But many of this articles fail to mention one of the most important things. This article will introduce you to one of the most fundamental thing in cross-browser scripting - feature testing technique.

Basically, there are two browser scripting techniques (as far as I know):

• browser detection
• feature testing

In short - browser detection relies on user agent string to detect browser and then scripting is done based on browsers features. The problem with this approach lies in unreliable user agent string. Many browsers send wrong user agent string, but things are even worst - detecting rules are far from perfect. Sometimes, same browser is being detected differently depending on OS (for example, IE8 is being detected as IE6 in Windows Vista, because it's user agent string contains number 6). That way, when new browser comes out on the market, new version of browser detection has to be made. It's constant struggle with time and new browsers.

Better approach is to use feature testing. Basically, you test what browser supports and provide fall-back in cases of lacking support or of feature not working correctly. This approach is better from browser detection because it does not rely on user agent string, instead of that it test what is browser capable to do. This way, when new browser comes out, no new version of feature testing has to came out (everything is tested the same way) and that makes it future proof. Even more - it will work on unknown and rare browsers.

There are some great articles about feature testing:

• www.jibbering.com/faq/faq_notes/not_browser_detect.html
• peter.michaux.ca/articles/feature-detection-state-of-the-art-browser-scripting
• perfectionkills.com/detecting-event-support-without-browser-sniffing/
• perfectionkills.com/feature-testing-css-properties/

Now, before running to Google and start searching for JavaScript frameworks that are based on feature testing - STOP.

Before choosing JavaScript framework you should learn language upon which framework is based on. Your starting reference should be ECMA-262 standard, you can download it here:

• http://www.ecma-international.org/publications/standards/Ecma-262.htm

Also, you should learn HTML and CSS specifications which can be found at W3C web page.

Any questions regarding browser scripting you can ask at: 

• http://groups.google.com/group/comp.lang.javascript/topics

Sometimes it's not so pleasant place because of some bad attitudes and not so pleasant language, but you should use your Zen skills and ignore people you don't like. There are some people there with great knowledge and pleasant language.

At this point you can search for JavaScript frameworks that are based on feature testing. But you'll get disappointed because most of today's modern JavaScript frameworks still relies on browser detection.

Many of you probably uses JQuery. JQuery from version 1.3 claim not too use any form of browser detection. Well, that not so true - it uses object inference to detect browser (www.jibbering.com/faq/faq_notes/not_browser_detect.html#bdOI).

History has shown that JQuery authors weren't so convinced that feature testing is right way, but recently have shown some wisdom, although not entirely. 

But then, you should ask yourself, why should I use something that they "borrow" from someone ... why not use framework from people that were feature testing evangelist from the start. Well, there were some frameworks, but me personally didn't find them useful.

Recently, a new JavaScript framework started to show up, it's called My Library (http://www.cinsoft.net/mylib.html). I think, maybe it's not yet ready for real usage, but you should keep an eye on it. It's maintained by David Mark, man of big mouth (well, that's his way of doing marketing :) ), but man of great knowledge. Despite the fact that most of the time he just spits on other mayor JavaScript frameworks, there have been some great technical reviews which can be found on JavaScript Google group. Me personally would like more technical speech from him, but I think My Library speak for it self. Check for it's speed tests and task tests, try them in many browsers and see for yourself.

Probably, some of you will comment about his widgets and they design, but you shouldn't (they will look cool in near future). JavaScript framework shouldn't be chosen based on nice graphic. There are graphical designer to do nice graphic on one hand, on the other hand do you really want to use same widget look as many other people? I don't want, I want to have unique design.

JavaScript framework should be chosen based on following things (not in any particular order):

• feature testing
• small in size
• speed and task tests on slow machines and slow JS engines
• future proof - so you don't have to upgrade every time new browser version comes out
• intuitive and self-describable API 
• good documentation with advanced examples and good explanations
• community
• useful plugins and widgets
• quality
• stupid proof - that means, framework and it's author should stop you from doing stupid things (learn instead)

My Library JavaScript framework is close to official 1.0 release (I'll write review after it's release). Soon, it's page will have new design, it widgets will look nice, documentation is getting finished, new widgets are on their way ... so, there is no need for you to just stand there and wait. Try it!

IE6 and CSS ":hover" pseudo-class

In my last post I've forgot about one important thing - IE6 doesn't support CSS ":hover" pseudo-class for "span" elements (actually, it supports it only for "a" - anchor elements).

There are some solutions for this problem and you can find it easily with search engines. I prefer using IE conditional comments in which one can include what ever is specific for IE. In this case, ":hover" pseudo-class functionality can be achived with JavaScript using "onmouseover" and "onmouseout" events. I won't show you how to do that, instead of that, I'll hopefully write a plugin for new and promising JavaScript library called "My Library".


Stay tuned ...

Don't use "javascript:" pseudo-protocol

I see many web pages uses "javascript:" pseudo-protocol in the "href" attribute of "a" (anchor) element.

For example:

<a href="javascript:myFunc();">Click me!</a>

But that's not a good practice. IE6 produces some side effects when using "javascript:" pseudo-protocol (newer versions of IE seems to solve the problems). One side effect is that it blocks "gif" animation (you can try and see that)!
The main problem is that using "javascript:" pseudo-protocol shifts IE6 into "wait state" and it blocks some functionality like mentioned "gif" animation but there are more, for example it changes execution context - "this" doesn't reference current element, but window:

<a href="javascript:myFunc(this);" onclick="myFunc(this)">Click me!</a>

If function is executed from "onclick", "this" is reference to "a" element, while in "href" attribute, "this" is reference to the window.


Anyway, there is no need to use "javascript:" pseudo-protocol in the first place. Anchor should be used for it's purpose, so if you want to execute some JavaScript function when user clicks on the element's text, you can use some other element ("span" for example), add "onclick" attribute which executes desired JavaScript function and style it if you want it to look like anchor:

<span class="anchor" onclick="myFunc();">Click me!</span>

You can also use anchor element to execute JavaScript code. But, here comes the problem with "javascript:" pseudo-protocol - users add "onclick" attribute to "a" element, but then they don't get desired behavior:

<a href="#" onclick="myFunc();">Click me!</a>

This way, when user click on the anchor, document is scrolled to the top of the document since in "href" attribute there is just "#" (a fragment) character - which has semantical meaning of the top of the document (that's why scrolling happens). And here comes the "javascript:" pseudo-protocol to solve that problem - but it introduces another.

There is (are) better alternative(s).

You can just return "false" in "onclick" attribute:

<a href="#" onclick="myFunc(); return false;">Click me!</a>

This way, event won't be propagated and there won't be scrolling to the top of the document.

Another way (which I prefer since it's semantically correct) is to add reference to current anchor element:

<a href="#anch" name="anch" onclick="myFunc();">Click me!</a>

This way there will be scrolling to this anchor, but that's what anchors are used for (and you'll execute JavaScript function).

And the last way is already mentioned - use "span" element insted of "a" element.