You are actually asking a few questions. I am currently analyzing the question “what framework should I use” for our company. This entails much more than you think. Below is what I have so far, and as I get more details I will try to update this item.
Meanwhile...
The question of architectural patterns is different from the question of libraries or frameworks.
ARCHITECTURAL DESIGN PATTERNS are useful for many reasons. One reason would be to get a loose connection in your modules. A great example of how to achieve free communication can be found in the "Mediator" .
The question is which structure to use has many decision points:
Speed tests:
This is what I consider FRAMEWORK :
I decided to limit my FRAME CHOICE :
- Dojo : Toolkit, Desktop, Mobil, Graphics and Vectoring
- YUI : developer tools, infrastructure, utilities, widgets, gallery, projects
- jQuery : Core, UI, Mobil, plugins, graphics, visualization
But ... you also need a breakdown of JavaScript LIBRARIES:
MVC is the most commonly used interface. However, my comments here are not yet complete. Even I had problems finding statistics on the use of the above elements.
Backbone.js (MVC)
Designed more to use REST data. Backbone has its own event system and thus competes with jQuery functionality.
Spine.js (MVC)
JavaScriptMVC (MVC)
MVC integrated development tools; used with jQuery; Very modular. Still not sure if it can just be considered a library or not ... but dad likey!
AngularJS (MVC)
Separation of problems, grip loosening and inversion of control Bidirectional snapping
SproutCore (MVC)
YUILibrary (MVC)
This is indeed part of the overall structure of YUI ... but was mentioned in the original article .
Broke.js (MVC)
The documentation is currently unsatisfactory.
Fidel.js (MVC)
Sammy.js (MVC)
Designed more for using REST data.
KnockoutJS (MVVM)
QUESTIONS:
- Why are there so few realistic MVVM implementations?
- Bilateral binding to the same as MVVM?
- If so, why do some of these libraries (which do two-way binding) consider themselves MVC?
MODULAR JAVASCRIPT: AMD , CommonJS and Promises -Based Implementations:
I still emphasize this area. However, below are some areas that I use for inspiration.
QUESTIONS:
- Are there different AMD flavors (various articles seem to say yes)?
- What does promises -based mean?
CREATING WIDGETS and PLUGINS:
Once you decide what kind of taste AMD should use your module, you can really start writing something.
QUESTIONS:
- What is the difference between a plugin and widgets?
GENERAL NOTES:
I would suggest looking at how each of your frameworks implements different modules. Look at the code that is required to execute something. Is it correct? It is not comfortable?
MY INITIAL FEELING:
By looking at the trends, usage, speed and simplicity of community support features ... jQuery is the way forward.
TARGET:
The ultimate goal is to choose a structure, all / all libraries, and determine a common approach for loading and creating loosely coupled JavaScript modules.
Quantitative assessment of the cost of risk:
The complex costs of quantifying are complex, but you can explain the risk. In your last sentence, you should also consider the trends listed above. But, in general, I would freely split the costs into 3 areas that define RISK:
- Acquaintance : How do you know your team now?
- Ramping : how much extra effort would it take to “build up” in each structure and library?
- Licensing : is there any interference?
Risk . After the assessment, you can rightfully explain WHY you can evaluate one option as low, medium or high.
@ErezCohen
We are an ASP.NET store, so we use the Web API for our RESTFUL backend. And since component-style JavaScript is the future, we decided to use jQuery and RequireJS as the standard baseline on all of our pages. In addition, we actively use Delays in our controllers.
As far as client side MVC is concerned, too many of the mentioned “frameworks” have more quirks than anything else (and many of them are weakening in use). In addition, it makes sense to consider the capabilities of MVC / MVVM as a one-time addition when requirements are dictated, rather than standard. And to be honest, since we find that simplifying Ajax calls, in an extensive framework for simple data binding, seemed silly (the only real advantage is two-way binding for some complex cases). Also, think about what pain it will be to separate some of these frameworks when they are no longer popular.
Of course, we have the talent to do this on our own ... you cannot. If your team doesn’t work very well with JavaScript, try Angular because it was designed for “designers,” not programmers. Alternatively, if your team is capable of working independently and wants to create an environment for controllers, then jQuery Widget Factory is useful. However, just using the module template for your controllers is also great (this is what we do). And ... it works great ... and VERY clean.