Javascript libraries

Lots of Javascript libraries and frameworks have come up. It has been made to make the life of developer really easy. Here is the list of all available Javascript frameworks,

But, I have got a very big question to ask, “are these framework making the life of Developer really easy?”

With the increase in the speed and number of the javascript framework, its getting difficult for the developers to decide which framework is to be used where.

Here,, you can test the speed/validity selector test for some of the major frameworks available.

You can get comparison matrix for most of the Javascript framework here,

The following guidelines might help you to decide which framework you should go for,

What are your project requirements?

The first and most important question you need to ask yourself is what are your project requirements? Is this a Web site or application that requires AJAX, robust support for handling events, or how about a library of effects? How much functionality do you need out-of-the-box, and what level of experience will be required by other programmers and designers to support this framework? If you have few requirements, you could find success with an extremely lightweight, modular library. Also you need check if your project requires effects, AJAX, graphics, tools etc

Does the framework supports all the browsers?

Once you know your audience, and your project requirements, you need to consider whether or not your JavaScript framework supports all the needed browsers. Most frameworks do, but there are often some exceptions in the fine print — typically with Safari on the Mac. If you are building an internal Web application for an Intranet, you might only be required to support a limited set of browsers.

How mature is the framework?

More than anything, the maturity of a framework demonstrates a commitment to longevity, as well as a solid foundation. A mature framework will no longer be in beta, and will have been through a full release cycle. There should be a growing, if not thriving community, and depending on the open-source license, a mature framework might also support a Subversion or CVS version repository. Any bug fixes can be rolled into a build without a public release, which is a huge plus.

How often are updates publicly released?

If you find that the community questions or complains about the release cycle, then that could be a warning sign. Long delays and bloated releases are also a sure sign that you will not enjoy supporting the framework on future projects. Alternatively, too many public releases could indicate instability, or a lack of focus.

How friendly is the documentation?

A major differentiators between JavaScript frameworks today is documentation. This not only includes official documentation for the API, but also includes books, tutorials, and blogs. The worst documentation is the sort that is only focused on syntax. Look for a framework that includes examples with each method and property, and that is updated to meet the needs of the community. Documentation is simple to research, and it can be a lifesaver when dealing with tight deadlines.

Is there an active community?

An active community does not guarantee a quality framework, but it does help a framework evolve. The character of the community is also an excellent gage of the type of help you might receive in the future when caught in a bind. Are there forums, or a Google Group? Are experienced users willing and able to lend a helping hand, or will they send you elsewhere for assistance? Are developers creating extensions, or contributing to the core framework? All of these are important questions.

Are benchmark tests performed regularly?

Benchmark tests are often questionable when determining the quality of workmanship put into a framework, but they do demonstrate a developer’s willingness to adopt some quality assurance best practices. Even a modest gain in speed, or a decrease in download size during a release cycle can be seen as a positive improvement.

How extensible is the framework?

Extensibility is typically a requirement of experienced programmers, and is rarely a request of designers. Plugin support is definitely a plus for any JavaScript framework, but developers usually just want to know — how difficult will it be to troubleshoot the core library? Layers of functionality provided by an active community do give a framework uniqueness, but this is a beneficial byproduct, and not often a necessity.

Do you like the API style?

This is an important, but complicated question that is answered for most developers only after using several JavaScript frameworks on numerous projects. Complaints about frameworks like Yahoo! UI are generally in regards to the style with which the API has been designed. Terseness, as well as chainability, are two very important features that should not be overlooked. Remember, you can grow irritated quickly because of cumbersome implementation details.

Debug PHP on Windows

Following are the steps to debug your PHP code using Zend Debugger on Windows machine via WAMP,

1. Download or check for new version at

2. Locate or ZendDebugger.dll file that is compiled for the
correct version of PHP (4.3.x, 4.4.x, 5.0.x, 5.1.x, 5.2.x) in the
appropriate directory.

Get debugger from folder called “5_2_x_comp” or you may receive some errors about a non-thread   safe debugger if you take it from “5_2_x_nts_comp”

3. Configure php.ini for output buffering when debugging

implicit_flush = On ; Default: Off
= Off ; Default: 4096

4. Add the following line to the php.ini file:
Linux and Mac OS X:     zend_extension=/full/path/to/
Windows:                zend_extension_ts=/full/path/to/ZendDebugger.dll
Windows non-tread safe: zend_extension=/full/path/to/ZendDebugger.dll

(*) the windows non-thread safe is used only with Zend Core 2.0

if you don’t have a Zend section you may add this at the end of the fie.
correct the php path if it is not installed in c:\wamp\www and extension directory.

5. Add the following lines to the php.ini file:

This willl allow connections from local host and from your local network to addresses which start        with 192.168.1.

6. Place dummy.php file in the document root directory.

7. Restart web(Apache/Wamp) server.

8. To activate the debugger please use following query string:

above statement assumes that the debugger listens at or on port 10000.

Here are some of the screen shots from my debugger,

Breakpoint in Zend

Breakpoint in Zend

This is watch window in Zend which will show the values of the variables, you need to add the variable to the watch window to view its values.

Watch Window in Zend

Watch Window in Zend

This is the output window that shows the output generated by the code executed till now,

Output Window in Zend

Output Window in Zend

Hope this helps 🙂