Efficiencies. Projects live or die by them. A JavaScript framework
may not make you a better programmer, but it will make you more
efficient. That alone should be reason enough to choose a JavaScript
framework, or library if you prefer. Unless you decide to build your own, there are plenty of options available
to developers. However, choosing the right framework can be tricky, and
weeding through a mess of opinionated fanboys (myself included) is
intimidating.
The best advice I can offer is to be flexible in your approach, and
to ask the right questions. This list should help you get started.
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.
Does the framework support A-Grade browsers?
Once you know your audience, and your project requirements, you need
to consider whether or not your JavaScript framework should support
A-Grade 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. Regardless,
making the grade is an important consideration.
Is there a core team of developers?
Several JavaScript frameworks are built by a single developer, but
the best are maintained by a core team of developers. This helps to
ensure regular updates, prompt response to bug reports, and open access
to get questions answered in a timely fashion. With a core team of
developers, it is likely that the code is more rigorously tested, and
adheres to specific style guidelines. A single set of eyes can more
easily overlook the obvious.
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?
Even though there is no hard and fast rule, you still need to ask
this question. 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 differentiator 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?
I have yet to discover a JavaScript framework that brags about bloat
and memory leaks. Yet, without benchmarks, how could you possibly know
either way? 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.
原文地址：http://blog.reindel.com/2007/10/30/how-to-choose-a-javascript-framework/