You're actually asking more than one question. I am currently analyzing the "what framework should I use" question for our company. This entails a lot more than you think. Below is what I have so far, and as I get more details I will try to update this item.
In the meantime...
The question of architectural patterns is different from that of libraries or frameworks.
ARCHITECTURAL DESIGN PATTERNS are useful for many reasons. One reason would be to achieve loose coupling in your modules. A great example of how to achieve loose coupling is found in the Mediator Pattern.
The question of which framework to use has many decision points:
- JavaScript Famework Usage
- Google Trends
- Comparison of JavaScript frameworks
Speed Tests:
- Slick Speed
- Task Speed
- Write your own test like this guy did
These Are What I Consider FRAMEWORKS:
- Dojo
- jQuery: Is a framework only when 'umbrella' modules are included (can be used as a lone library)
- YUI
- Mootools
- Prototype
I have decided to limit my FRAMEWORK CHOICES to:
- Dojo: Toolkit, Desktop, Mobil, Graphics & Vectoring
- YUI: Developer Tools, Infrastructure, Utilities, Widgets, gallery, Projects
- jQuery: Core, UI, Mobil, Plugins, Graphing, Visualization
But...a breakdown of JavaScript LIBRARIES is also needed:
MVC is the most commonly used front-end pattern. However, my notes here are not yet complete. Even I am having trouble finding usage statistics on the items listed above.
Backbone.js (MVC)
Designed more toward consuming REST data. Backbone has its own event system, and thus, competes with jQuery functionality.
Spine.js (MVC)
JavaScriptMVC (MVC)
MVC integrated development tools; is used with jQuery; Highly modularized. Not yet sure if it can simply be considered a library or not...but daddy likey!
AngularJS (MVC)
Separation of concerns, loose coupling, and inversion of control. Two-way databinding
SproutCore (MVC)
YUILibrary (MVC)
This is really part of the overall YUI framework…but was listed in the original source article.
Broke.js (MVC)
Documentation is currently poor.
Fidel.js (MVC)
Sammy.js (MVC)
Designed more toward consuming REST data.
KnockoutJS (MVVM)
QUESTIONS:
- Why are there so few outright MVVM implementations?
- Is Two-Way Binding the same thing as MVVM?
- If so, why do some of these libraries (that do two-way binding) consider themselves MVC?
MODULAR JAVASCRIPT: AMD, CommonJS and Promises-Based Implementations:
I am still outlining this area. However, below are some areas I am using for inspiration.
- A previous question of mine
- ARTICLE: Writing Modular JavaScript With AMD, CommonJS & ES Harmony
- ARTICLE: My Thoughts on AMD
- ARTICLE: Creating large-scale JavaScript Applications
- PRESENTATION: AMD Patters by John Hann
- Essential jQuery Plugin Patterns by Addy Osmoni
QUESTIONS:
- Are there different 'flavors' of AMD (various articles seem to say yes)?
- What does 'promises-based' mean?
CREATING WIDGETS & PLUGINS:
Once you decide on which flavor of AMD your modules should use you can actually begin writting something.
- ARTICLE: Coding your First jQuery UI Plugin
- ARTICLE: The jQuery UI Widget Factory
QUESTIONS:
- What is the difference between a plugin and a widget?
GENERAL NOTES:
I would suggest looking at how each of your frameworks implement various modules. Look at the code it takes to accomplish something. Does it feel right? Does it feel clunky?
MY INITIAL FEELING:
Looking at the trends, usage, speed and vastness of community support options...jQuery is way ahead.
THE GOAL:
The final goal is to choose a framework, any/all libraries and define a general approach for loading and creating loosely-coupled JavaScript Modules.
Quantifying Cost by Risk:
Quantiying cost outright is difficult, but you can explain-away risk. In your final desicion, you should also take into account the trends listed above. But, in general, I would loosely break-up cost into 3 areas that define RISK:
- Familiarity: What is your team most familiar with now?
- Ramping Up: How much extra-effort would it take to get "ramped-up" on each framework and library?
- Licensing: Are there any snags here?
Risk: Once assessed, you can rightfully explain WHY you might rank one option as low, medium or high.
@ErezCohen
We are an ASP.NET shop, so we use Web API for our RESTFUL backend. And since component-style JavaScript development is the future, we chose to use jQuery & RequireJS as a standard baseline on all our pages. Additionally, we make heavy use of Deferreds in our controllers.
As for client-side MVC, too many of the “frameworks” mentioned are more fads than anything else (and many have waned in use). Additionally, it made more sense to treat MVC/MVVM capabilities as a one-off add-on when requirements dictated rather than a standard. And, frankly, since we find making Ajax calls easy, brining-in vast frameworks to do simple data-binding seemed silly (the only real benefit is two-way binding for certain complex cases). Besides, think about what a pain it would be to decouple some of these frameworks once they are no longer popular.
Of course, we have the talent to do so on our own…you may not. If your crew isn’t very good with JavaScript, try Angular because it was developed for “designers” not programmers. Alternatively, if your team is capable of rolling-their-own and wants a framework for controllers then jQuery Widget Factory is useful. However, simple use of the Module Pattern for your controllers is fine too (that is what we do). And...it works great...and is VERY clean.
