Overview of JS frameworks. Journey through the jungle javascript MVC. Part 2

(End of translation of Eddie Osmani’s article on comparing and choosing a library for a project with a significant JS role on the client.)
Content of the first part :

■ What is MVC or, better, MV *?
■ When do we need a JS * MV framework?
■ Where are we going to need MV *, and where not?
■ The problem of choice: too many options?
■ TodoMVC: a general app for learning and comparing
■ Our proposed criteria for choosing a framework
■ Dojo and JavaScript framework complications
■ TodoMVC collection (frameworks on which implementations of the Todo test application are made)

■ What is the framework when to use?

To narrow the scope of search frameworks, we want to offer a choice of a high-level framework based on features that we hope will help select several options for sampling.

I want something flexible, with minimalist solutions for separating tasks in my application. It supports persistent connection and REST synchronization, models, views (with controllers), event-driven data exchange, templating and navigation (by anchors in the URL). When the model changes, the view changes immediately. I would like to manage the architecture properly. Ideally, the solution has been used by many large companies for non-trivial applications. Since I can get something complicated, I would like to see an active community around the framework, which you can always try to ask not too simple questions ( Marionette, Chaplin, Aura, Thorax ). Ideal to also have build tools ( grunt-bbb, brunch ). Use Backbone.js .
')
I want the foundation of desktop applications for the web. This framework must be high-level, modular, MVC, without the need to put everything together manually, maintain persistence (fixed objects with file metaphor, devices), calculated properties and auto-update of templates. This is necessary for intelligent state management instead of manual configuration, compatibility with many adjacent frameworks. This should be with good documentation, use templates, build tools ( ember.gem, ember for brunch ). Use Ember.js .

I want something lightweight, with templates connected on the fly, navigation, integration with main libraries (such as jQuery and Dojo ) and fast, with support for MVC component inheritance, which may not yet be done on large applications, but it should be. Ideal if done by people with experience creating complex applications. Use CanJS .

I want a declarative style wrapper that uses View to collect data about user behavior through customizing HTML and components according to the rules of the application. With simple test system support, URL navigation and task sharing via MVC or its variant. This gives a customized approach to adjacent libraries that compile HTML in order to build your own DSL (domain-specific language) in HTML. This is necessary for such elements of the network platform as web components; and still need to have assembly tools ( angular-seed ). Use AngularJS .

I want a good basis for large-scale applications, with a proven and tested infrastructure of widgets, modules with post-loading; possibly with asynchronous and simple integration with CDNs, with a choice of modules and widgets (graphs, charts, tables, etc.), with good multilingualism (i18n, l10n). We need support for OOP, MVC and a block builder (modules) to create complex architectures. Use Dojo .

I want something optimized for working with YUI extensions. With support for models, views and navigation, which would make it easy to write an application with different ways to display information, with transitions of display options from one to another and the like. It is a complete solution with widgets / components, with the ability to describe the architecture of the application. There may be build tools ( yuiproject ), but with possible replacement with others. Use YUI .

I want something simple for asynchronous interfaces and not having dependencies, flexible when building an application, with MVC support, events, navigation, while remaining compact. Optimized for CoffeeScript, with detailed documentation. Use Spine .

I want a tool to build complex dynamic UI based on a data model and a declarative binding style. For UI updates with model changes, using bidirectional binding and dependency support through data tracking. I should be able to use it with any framework or even with a ready-made application. You need to have built-in templating and easy extensibility. Use KnockoutJS .

I want something for simple web applications and sites. I do not expect to have a lot of code there, so it will not interfere much. Crossbrowser to focus on the task. Easy event handling, interaction with remote services, extensibility and a huge set of plug-ins. Use jQuery .

■ What do developers think about the most popular frameworks?

As part of the study on MV * frameworks for TodoMVC and this article, we conducted a survey among developers. What framework do they use more often, and most importantly, why would they recommend it? What will they feel if this framework was not in the project?

Here are some of the most interesting answers:

Ember.js

“For” : the combination of live templates and related (observable) objects has changed the way that JavaScript is handled. At first it may seem a little confused, but you finish the work with a good division of responsibility in the code. I found that once everything is described in me, adding quite complex features takes a couple of lines. Without Ember, these same features would be hellishly complex to implement.

"Against" : Ember , after all, should reach version 1.0. Many things are still in motion, such as a router and Ember data . The new website is very useful, but there is no such documentation for Ember like other frameworks, especially Backbone . With so much magic in the framework, it's a bit scary. If something breaks, you can't figure out exactly why. Yes, and error messages in Ember are often inaccurate.

“For” : key factors:
a) Features that allow me to avoid masses of template code (bindings, computed properties, presentation layer with good control).
b) development team. I am a rubist and I know what Yehuda Katz is worth. I trust the guy =).

“Against” : documentation. It is really sad that Ember does not have good documentation, training programs, screencasts like Backbone, Angular, or other frameworks. Right now we are reviewing the code, looking for documentation that is not perfect.

Pro : configuration agreement. Ember takes a lot of small work for you; this is by far the easiest way to build an application on the client side these days.

"Against" : the threshold of learning. The lack of a mass of tutorials for beginners that exist for other frameworks like Backbone is partly due to the small community, but I think it’s more because of the code mobility in preparation for version 1.0.

“For” : ease of binding, tight integration with management, easy modularity in my own code.

“Against” : I would like to have a stable integration with Ember data and integrated support for localStorage, synchronized with the REST API - all these are false dreams.

Backbone.js

“For” : simplicity - only 4 main components (Collection, Model, Presentation, Router). A huge community (ecosystem) and many solutions on StackOverflow. Higher order frameworks like Marionette or Vertebrae - with a lot of smart code inside. Someone likes “low level” - you need to write a lot of sample code, but get the architecture made for yourself.

Con : I do not like inheritance - the content of the parent object is copied to a new one. You need prototype inheritance. Sometimes I don’t read “real world scenarios” in examples from docks. You have to do a lot of research after reading the tutorial with TODO to figure out how to build a slightly more complex application.

I do not use official AMD support in DocumentCloud projects ( Backbone, Underscore ) [but this is not a problem with the new shim () method in RequireJS 2.0 ].

“For” : after the initial puzzling study of the work of Backbone, all of this is extremely practical. Practicality - in a well maintained, lightweight and constantly updated library in the right environment. Friendly support for Underscore, jQuery / Zepto , the tools that most projects from my studio would work with.

"Against" : the number of tutorials on how to work with Backbone is different for different versions. I asked other developers to take a look at Backbone , and they would write code for version 0.3. Unconsciously. While there are no problems, Backbone can fix it, but this is perhaps the main inconvenience associated with it.

Theoretically, the same can be said about anything, but with Backbone it periodically repeats before my eyes. Hell, I even saw an article a month ago, which uses ancient methods and techniques.

Regardless of my attitude to the framework, it is this problem that could be corrected by the community with reasonable edits and approaches. For me, Backbone deserves respect, because of community support.

“For” : provides only minimal abstraction without unreasonable restrictions - it gives the opportunity to assemble a project according to needs.

Con : I would rewrite or delete Backbone.sync . It is built for the HTTP protocol and does not adapt well to the features of WebSocket.

Pro : Extremely easy to get started, offers a good familiarization path. It is relatively well customized, and there are tons of other people using it who can help.

Cons : the fact that there is no default view binding (although you can set it). Updating an entire view when a single property changes is uneconomical.

The REST API has many advantages, but there are difficulties with a large number of entries (admittedly, the problem with REST is its own, but still remains) and unpleasant problems in obtaining various URI schemes for working with various types of operations.

AngularJS

“For” :
a) Bidirectional data binding is a very strong approach. You think more about your model and condition instead of organizing a series of events. The model is the only source of truth.
b) Speed. AngularJS is easy to download. It templates by building nodes instead of innerHTML, which, in theory, is more productive.
c) If you are guided by modern browsers and / or are quite frugal, you can do without jQuery.

Cons : I would like to be able to specify UI state transitions that are changed by the model. Namely, items using ng-show / ng-hide , I would like to hide or minimize a simple declaration.

Pro : He is very intuitive, with excellent documentation. I like their data binding approach, HTML, based on Views, nested environments (scopes). I went from Backbone / Thorax to Angular and never looked back. A new extension (addon) Chrome Batarang integrates with Chrome Developer's Tools and provides real-time access to Angular data structures.

Cons : I would like to have built-in support for functions like drag-n-drop, but this can be added through external components available on GitHub. I would like to see more third-party components suitable for reuse. I think it is only a matter of time for the ecosystem around AngularJS to become more mature, and then they will be available and diverse, as in communities like jQuery .

“For” : It drastically reduces the template code, allows you to reuse the code through components, extends the HTML syntax so that many complex features become as simple as writing attributes in HTML, and are extremely easy to test thanks to the complete description of dependencies.
You can write a non-trivial application without jQuery , without directly managing the DOM. To make such a tool is a real skill.

“Against” : its threshold of learning is somewhat higher than that of Backbone (which is very easy for the master), but the result is worth it. Documentation could be better.

Knockoutjs

Pro : I don't always use it, but KnockoutJS is great for single-page apps. Very easy subscription to changes of objects; Much better API for the so-called Backbone “collection views”, using observable arrays. And user events on observed objects for effects, etc.

"Against" : it is felt that the API is difficult to expand; I would probably prefer to choose Backbone on large applications (also because of community support).

Pros : I like the data binding mechanism and its convenient use. I especially like the way the templates were replaced by binding control logic.

Cons : It’s bad that there is no best practice guide with the structure of the application. In addition to having a View Model, the framework does not help you in describing a well-structured View Model. This will end very easily with a large unmanaged feature.

Dojo

Pro : syntactically - Dojo is very simple. This is good for dynamic and stable builds, with a loader's initial file, usually 6 KB in size. It is AMD-compatible (post-loadable), which makes it very compact, and comes out of the box with a ton of extensions, from basic work with DOM to complex SVG, VML and canvas. The widget system Dijit is great in ease of use and ability to expand. This is a very well-chosen and complete set of tools.

Cons : dojo / _base / declare functionality is not a 100% rigorous managed tool, now there are some overlays due to backward compatibility, although this will mostly be fixed in Dojo 2.0 .

“For” : good components: tabs, tables for data, form manager ... Equally for all browsers. Working AMD. Easy tests with data simulators. It integrates well with other frameworks thanks to AMD (I will integrate with JMVC ).

Cons : The project is configured by default for out-of-fashion components. Not fully html5. Documentation is so-so. Bad templating system (no binding on the fly).

YUI

“For” : YUI3 is a modular and “do-what-want” type of component library that includes all the advantages of Backbone and even more. In my opinion, it even improves some concepts of Backbone by sharing some things (for example, an attribute is a separate module that can be mixed into any object - the “module” of an event can also be mixed).

Con : I would like to see that YUI3 supports wiring from Ember . I think this is a really great achievement for Ember ; otherwise, I see YUI3 as an excellent component library where you can find what you need. I want to see improved AMD compatibility of the module loader. It works well today, but it would be better if I could start new projects on AMD modules and insert into third-party YUI3 components and other things that AMD also uses.

JavascriptMVC

Pro: It has all the tools out of the box, all that remains is to run the commands and start the build. I used 6 months and it was really good.

“Against” : the only thing I would like to see is the acceleration of the development of the next version. The developers know about the problems and solve them, but the process could be different - not months for some problems that I want to fix and send a solution - then I could make a patch and pull-request.

Maria

Pro : Since Maria is a pure MVC implementation framework, it focuses on being an MVC framework. No more and no less. Everything is strict and simple.

“Against” : a bit more documentation than what is written in the source code, plus a few test cases. A tutorial showing the basics of Maria’s real MVC usage would not hurt.

Cujo.js

Pros : For real-world applications, MV * out of the box is almost never enough, and the most important toolkit is often outside the box. With cujo.js , you define a box.

Yes, cujo.js has high-level MV * -like features for creating Views, models, controllers, etc., but each application is different, and no framework can be a 100% solution. Instead of trying to please everyone, cujo.js also includes low-level tools, architecture settings and a rich plugin system that can even combine and extend other MV * frameworks.

Create the architecture best suited for your application, instead of laying the application in the framework of someone else's architecture.

“Against” : the broad masses of javascriptors are completely unprepared and not trained in the development of large-scale applications. Most of them do not even know about the existence of design patterns and architectures.

Since cujo.js is so different from others, it needs something more than just referring to the API and code examples. Without tutorials, educational materials, and developing examples, cujo.js will look weird and depressing for the un-minded eye, but documentation is expected soon.

Extjs

Pro : I think ExtJS works best with Ext Designer . It separates itself from other GUI frameworks, allowing non-programmers to design UIs, and programmers fill in the blanks. Comparison with Backbone type MVC frameworks is, in my opinion, illegal: the power of ExtJS is in creating a rich GUI, and not lightweight web applications.

For commercial, remote office, rich-applications, I think that ExtJS remains the best choice when it comes to JavaScript solutions (except GWT , etc.). For public web applications, I have something else that gives me more control over markup (and ideally fulfilling greaceful degradation).

“Against” : it has a high threshold of entry, above many other modern structural (structural) frameworks. It can be said that if they invest in ExtJS for long-term development, the time to study will pay off, but I think that solutions like this should strive to minimize the team's training time.

“For” : I think that the special property of ExtJS 4- that he throws you into MVC concepts and the required file structure right off the bat. The initial tutorials of Dojo speak mostly about improving existing sites, and ExtJS assumes that you are starting a site from scratch.

ExtJS doesn’t really show that you are dealing with HTML. The component library is rich enough to work for a long time without touching HTML when building the application.

It would be interesting to see how this fits together if web components are more fully supported. This finally would allow the DOM to be managed without fear of breaking widgets or having to become inconsistent with the internal state of your application.

"vs": licensing is considered restrictive and difficult to understand by some. More people would invest in ExtJS if it were clearer what the deposit was and what the long-term costs would be when it was used. There are no such problems with some other structural tools, but this is probably not a cause for concern in a large business environment.

“For” : ExtJS is a fantastic package for quickly building an RIA for an intranet. I, for example, like to write with HTML and JavaScript, and for me there is a great satisfaction to dig at this level. Although ExtJS makes you feel that you are not working with HTML, it still gives you a lot of control over the document, especially when creating a complex UI.

"vs": Nevertheless ... I completely agree that this is a very heavy shell, and I do not think that I will recommend it for frondend on the web. My biggest complaint about the package is that it is a big headache for tests than I could imagine. Our tester ended up switching to Sikuli , because trying to work at Selenium became too big a battle.

Batman

“for” : he has a large and convenient system for viewing bindings. Games with Rails are very enjoyable and these are all configuration requirements.

Cons : Documentation could be much better, and I feel that Shopify will not add new features, although they say they will.

■ Do not be afraid to experiment

Although the developer is unlikely to learn how to use more of this handful, I’ll support the study of frameworks that you don’t know. There is a cart (with a small trolley) of interesting facts and techniques that can be learned between times.

I had a case: I found that Batman.js requires a minimum of self-written code in the implementation. I am not a constant CoffeeScript-box or a user of Batman.js , but the result gave me some food for thought. It is possible that I will be able to take some of the source of the tool and use it myself. Or, perhaps, in the future project, I just use Batman.js when it is overgrown with community and support.

Regardless of whether you use what you see and build in a day, you will get more knowledge about what is there and how to work with it.

■ Going beyond MV * concepts

Although the MV * family of patterns is very popular for structuring an application, they are limited in that there is no difference in the types of application layers, the connection between different Views, no services that perform work or anything else. Developers may have to explore other patterns.

We turned to developers who went further MVC, penetrated into the essence of the requirements with their own patterns or extensions of the existing one.

. , Backbone , , . Backbone (, ), . Initializer .

, MVC . — , , .

, Marionette . — , ( ) , .

Marionette TodoMVC, Backbone , MV*.

Derick Bailey — Marionette

JavaScript MVC, . , API , , .

, , , MV* . « », — , - . , , JavaScript .

J2EE. , «PHP Objects, Patterns, and Practice», Matt Zandstra, , ! J2EE , , URL . , , , .

J2EE , .

Dustin Boston — Aura

■

Given that there are several ways to structure the data of a web application, it is important to pay due attention to the choice: take the time to fully evaluate the options in order to arrive at a viable and maintainable code. A variety of frameworks help innovate results, and a lot of similar tools only create noise.

Projects like TodoMVC help narrow the selection of tools to the most interesting or convenient for a particular project. Remember that it is not necessary to rush to a choice, do not feel forced, choose what best suits your needs.

Experimenting with frameworks will introduce you to ways to solve common problems that will help you program better.

Thanks to my colleague, a member of the TodoMVC team Sindre Sorhus for his help with the corrections and proofreading of this article.

Author: Addy Osmani is a development engineer on the Chrome team at Google. A passionate JavaScript developer, he wrote books with a free distribution license: “ Exploring JavaScript Design Patterns ” and “ Backbone Application Development, ” and participated in the development of the open source projects Modernizr and JQuery . He is currently working on Yeoman , an original workflow for creating attractive applications.