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

(dated July 27, 2012)
When writing a native web application, it's easy to start feeling ~~like a god~~ , able to work simply with a DOM library (such as jQuery ) and a handful of service plugins. Soon there is a problem in the form of a pile of nested jQuery return functions and scattered DOM elements without any structure instead of an application.

In short, we get stuck in spaghetti code . Fortunately, there are modern JS frameworks (libraries that specify, apart from functions, code organization rules - approx. Transl.) , Which help to maintain structure and organization in a project, which facilitate maintainability in the future.

■ What is MVC or, better, MV *?

These modern libraries give developers a simple way to organize code using variations of a design pattern known as MVC (Model-View-Controller). MVC divides the tasks in the application into 3 parts:

The model (logic) represents problem-oriented knowledge and data in the application. Think of them as the type of data you can model, such as User, Photo, or Note. Models should inform about something when observing their current state.
')
The view (view) is usually designed as a user interface, such as markup and templates, but not interactive. They should be aware of the existence of Models, but not directly communicate with them.

Controllers (dispatchers) process input data (clicks, user actions) in the application, and Views can be viewed as an output processing product. When the Controller changes the state of the Model (for example, editing the title on a photo), it does not directly change the View. This is the case where Model and View relationships work.

Javascript MVC frameworks that help in structuring code do not always strictly follow the described pattern. For some, the Controller will be responsible for the View ( backbone.js ), self-confidently mixing the components, believing that it will be better so far.

Therefore, we call such frameworks MV * patterns, that is, the View and Model will most likely be, but something else will be added to them (than just the Controller - approx. Transl.) .

Remark There is an MVC variant called MVP (Model - View - Presenter) and MVVM (Model - View - ViewModel). If you are new to these concepts and resist taking them on faith, do not worry. It will take time to get comfortable with the patterns; I wrote more about them in my online tutorial " Learning JavaScript Design Patterns " in case you need help.

■ When do we need a JS * MV framework?

When building a one-page application or when creating a complex user interface, or simply reducing the number of HTTP requests, you will probably invent many parts of the structure of an MV * framework such as Backbone or Ember .

At the beginning of work, it is not very difficult to write a framework (framework) of an application that offers some ~~kind of bike~~ mechanism to avoid spaghetti code. But to say that it is not more difficult than to write "some" Backbone , it would be too wrong.

There is much more to structured applications than tying up DOM manipulations, templating and identifying links. MV * Mature frameworks usually not only contain many pieces that you would write, but also contain solutions for future tasks. This saves time, which cannot be underestimated.

■ Where are we going to need MV *, and where not?

If you are writing an application for communicating with an API or for processing backend data, where the main burden of viewing or managing data will be in the browser, the JavaScript MV * framework will be useful in it.

Good examples of applications of this kind are Google Docs and GMail . Typically, such applications load the payload once with all the scripts, styles, and markup for common tasks and then perform many small actions in the background of the page. These are just transitions from reading a mail or document to writing letters, and you don’t need to load new pages at all.

But if you build an application that requires a server for a large amount of Views (pages) and use a little JavaScript or jQuery for sharing, the MV pattern can be deadly. Of course, there are complex applications on the web, where a partial presentation of views CAN live well with a single-page application, but for everything else, it’s better to choose a loading mechanism easier.

■ The problem of choice: too many options?

Over the past few years, the JavaScript community has experienced something like a renaissance, building increasingly complex and voluminous applications. Their style is still very different from the classic Software Architectures , which are built in C ++, Java, which are also used on the web along with languages for web development (PHP, Python, .Net, etc.). As a result, we often borrow ideas about building applications from what we see in other languages.

In my topic “ JavaScript MVC classification: Abuse or Evolution? ” (Eng.) , I raised the question that there is now too much choice of tools for structuring your JS application. Part of the problem is how different JavaScript developers choose the organization of a scalable application: MVC, MVP, MVVM? Or something different? Every week, new MV * frameworks are born with a large excess, because we are all looking for the “right way”, if it exists at all. Many developers believe that it is not.

We are going to choose new frameworks, which often arise like 'Yet Another Framework Syndrome' (or YAFS). As innovation, of course, something is welcome, but YAFS can lead to great confusion and frustration when developers want to start writing an application, and they need to manually evaluate 30 tools in order to choose something not very unsuitable. The differences between some frameworks will be very subtle, if not difficult to see.

■ TodoMVC: a general app for learning and comparing

(Was in April a note in Russian: habrahabr.ru/post/142301 )

We see a huge boom in the number of such MV * frameworks over the past few years.

Backbone.js , Ember.js , AngularJS , Spine , CanJS ... The list of new and workable solutions is growing every week; developers can quickly get lost in a sea of options. They have plenty to choose from. There are many strong competing solutions from minds working on complex applications that inspired the creation of libraries (such as Yehuda Katz and Jeremy Ashkenas ). Question: what to use and how to choose?

We realized this position and wanted to help developers make the selection process as simple as possible. We created TodoMVC , a project that implements the same Todo application on various MV * frameworks that are currently popular. Consider it as a data rate meter for frameworks. Implementations live and work in the same way and help us compare the syntax and structure of different frameworks; thus, we can choose the one that feels most comfortable, or at least a comparison will help narrow the circle of choice.

This week (July 14, 2012) we are releasing a completely new version of TodoMVC , the details of which are given below in the application section.

In the near future, we want to further develop the work by providing notes on the differences and recommendations on which types of applications the use case of one or another framework should be considered.

■ Our proposed criteria for choosing a framework

Choosing a framework is, of course, more than a simple comparison of the ToDo application. Therefore, when your choice leaves a few candidates, we recommend a little step back and look around. It is possible that the framework will have to support non-trivial functions, and it may turn out that it will have to be supported for many years. Try to answer the questions.

What is the framework really capable of?
Take the time to read the framework source code and the official list of features to find out how they meet your requirements. There will be projects that may require changes or additions to the source code, and if you find it feasible for yourself, the code has passed the test.

Has the framework been tested at work?
Are there any developers who have built and implemented large, publicly available applications with this library? Backbone has a serious list of such (SoundCloud, LinkedIn), but not everyone has one. Ember works in a number of large applications, including user tools in Square. JavaScriptMVC is used in large applications in IBM, not counting other places. It is important not only to know that the framework works, but also to be able to look at the real code and understand how this can be built.

Is the framework working out?
We advise developers not to simply “choose this and go to work”. New projects are often accompanied by a lot of release discussions; don't forget about them when choosing a release for a production-level application. You do not want to have the risk of being stopped in the project due to urgent refactoring or other breakdowns, which are more predictable if the framework has been worked out and debugged. Mature projects are usually better documented, officially or through the community.

Is the framework flexible or tough to manage?
Know that there are libraries of different "nature". Hard-control frameworks want programming from you within certain limits. They limit the design of the application and pay less attention to the developers, who independently figure out how this should work.

Have you really "played" with the framework?
Write a small application, without a framework, and then try to remake the code to work with the framework to assess whether it is easy to work with. Since working with the code will affect your decision, it is important to write working code to make sure that you are comfortable with its designs.

Is there full documentation?
Although demo applications are useful for reference and viewing, you will almost always communicate with the official developers of the framework, learn about API support, how to solve common tasks, how to create components, and what bugs are noticed. Any worthwhile framework should have detailed documentation to help developers understand it. Without it, you can find IRC channels with groups of developers or conduct independent research, which is beautiful in itself, but often takes a lot of time compared to a previously provided set of documents.

What is the volume of the framework, the ability to minify, compress, modular?

What dependencies does the framework have?
For frameworks, there is a tendency to specify the size of their file, but not to mention the size of the dependency libraries. A small library will be unexpectedly large, if, say, depends on jQuery or other libraries.

Have you familiarized with the community of developers of the framework?
Is there an active community of project participants and users who would be able to help if there are problems? Have a lot of developers used the framework, are there links to running applications, tutorials, and perhaps even screencasts to learn more about it?

■ Dojo and JavaScript framework complications

As many know, the Dojo Toolkit was one of the first attempts to give developers a tool for developing complex applications. Some may say that it inspired them to think more about tasks for unusual applications. I asked [in the letter] the Dojo developers - Dylan Schiemann , Kitson Kelly, and James Thomas what they thought about the emergence of MV * frameworks.

Q : Could the Dojo library solve all this? Why did it not become the preferred solution for those who want to build more structured and non-trivial applications?

A.: A few years ago, when the JavaScript environment evolved from adding simple Ajax and effects to a page, Dojo preached an “instrumental” approach to building complex applications on the Web.

Many of those features were far ahead of most developer needs. With the advent of the browser as the dominant application platform, many innovations have been introduced into the Dojo Toolkit , and now they appear in new tools. MVC was just another package that provided Dojo for quite a long time along with other code modules: OOP in JS, UI widgets, cross-browser graphics, templates, internationalization, data access, data warehouses, test frameworks, system builds, and much more.

Javascript libraries should not have a “complaint” about why Dojo from an early stage focused on the full cycle of developing enterprise-level applications. MVC has the same focus now, it's just one “tool from the set”.

Why is Dojo not the dominant toolkit? Her goal was never to be the only choice. The goal was to provide an open set of tools that can work with something else within projects and with portability to other projects. Dojo was criticized for being slow and even after it was taken, she was criticized for being slow. Attempting to get rid of the shortcut is a difficult task. It is difficult to document the features of a rich set of tools. Dojo 1.8 has 175 sub-packages and more than 1,400 modules.

This is not only a question of achieving the goal of documenting, it means that Dojo does more than one task. It's good when you write a program, but it's very difficult to first figure out where to start. Improved documentation and tutorials try to help with working with Dojo 1.8.

Q : Why should developers choose Dojo and which list of ideas do you have for a future project? It is said that after 1.8 there will be another goal.

A .: In Dojo 1.8, the dojox / mvc package takes another step toward maturity. Much wasted time, effort, testing and community attention to the package. He specializes in providing MVC models that enhance the rest of the Dojo . Together with the dojox / app application package for building rich applications for desktops and mobile devices, this makes a complete system for the client side.

And this is just one of the viable ways to build applications in the typical Dojo approach.

In 1.8, not only does the MVC sub-module become more mature, it is based on a stable framework. This not only provides a markup language to create your view components, express your models or develop a controller. This is much more than just connecting another module to a data source. Because it is connected to the rest of the Dojo , you can connect whatever you need.

In Dojo 2.0, we will try to take modularity to a new level, to make it even easier to take something else and put it all together. We also explore the concept of isomorphism, so that the user doesn’t matter where the code runs on the client or server, and ultimately it must be transparent to the developer.

■ TodoMVC collection

In our brand new release, there are now Todo implementations for the most popular frameworks with a large number of other moderately used frameworks running in Labs. These implementations have undergone many revisions, often taking onboard prompts from the best practices and suggestions from the authors of the framework, its participants, and community users.

Following the comments made by the author Backbone.js Jeremey Ashkenas and Yehuda Katz, TodoMVC now also offers corresponding implementations made on the official application specification, such as navigation (or state management). (?)

We do not pretend that more complex comparison applications are impossible (of course, possible), but the simplicity of the Todo application allows developers to perceive the structure of the code, the syntax of the components and the “flow feeling” sufficiently to start comparing frameworks and looking at the details of their solutions or several making.

Our applications include:

For those interested in AMD versions:

Backbone.js + RequireJS (using AMD)
Ember.js + RequireJS (using AMD)

Our Labs contain:

Remark We made one version of our Todo application in pure JavaScript , and another, using, above all, the jQuery approach . As you can see, these applications are functionally equivalent to what is written with MVC frameworks, but there is no separation of tasks, and the code becomes more difficult to read and maintain as the volume grows.

We consider it an honor that last year some framework authors involved us in discussions on how to improve their solutions, helping to reduce our experience with a multiple solution to a table. In addition, we slowly moved to TodoMVC, which was almost a de facto application; added new frameworks, which means that it has become easier to make initial comparisons.

(Here you will have to stop at the most interesting place - the text size grows - to stop the allowed speeches. Immediately after the break, the most anticipated question of modernity will be asked: what framework should I use? 9 delightful one-part maxims wrapped with the phrase "I want ...", completed amazing sauce "Use ...!" in recipes from Eddie Osmani himself!)

Further, in the final part:
■ What is the framework when to use?
■ What do developers think about the most popular frameworks? ("pros and cons")
■ Do not be afraid to experiment
■ Go beyond MV *
■ Conclusion.

A similar review: Rich JavaScript Applications - the Seven Frameworks (Throne of JS, 2012) , Steven Sanderson, 1th Aug 2012. Differences and coincidence approaches Backbone, Meteor, Ember, AngularJS, Knockout, Spine, Batman, CanJS - the results of the conference “Throne of JS, 2012 ”.

(Continued: 2nd final part .)

Source: https://habr.com/ru/post/149594/

All Articles