Very subjective review of JS frameworks. AmpersandJS, part 0

From the translator: when I started to deal with MVC frameworks for the front end, this article by Henrik Joreteg somehow caught my eye. Now they have reached out to translate it for Habr, all the more so that AmpersandJS on Habré is not audible at all . I will try to organize a cycle of articles on this tool from & yet, I think it is worthy of attention.



As part of our educational seminars, I give a brief overview of JS frameworks. I didn’t really want to publish most of my opinions about these tools on the Web, because such things tend to stir up the masses, offend people, and unlike face-to-face conversations, there’s no really good bidirectional Internet discussion. communication with the audience.
But I was often told that my review is extremely useful and helps to get a concise and, at the same time, a good understanding of the question “who is who in JS frameworks for creating single-page applications”. On this occasion, I decided to materialize it and publish it as Something , but please remember that I just express my opinion, I am not telling you what to do, and you should use those tools that better suit you and your team. You can easily disagree with me, write about it on Twitter, or, even better, post a separate post explaining your position.
')

Angular.js

behind

1. very easy to start using. you can simply insert the script tag, add some ng-attributes to your application, and you magically get the behavior you need
2. Angular is well supported by its core development team, many of whom work on Google on an ongoing basis.
3. large audience / community

vs

1. If you choose Angular, then you learn Angluar.js instead of learning how to solve problems with JavaScript. If I translated our team to write applications using Angular, what would happen when {here the name of the beautiful new JS framework} wants to change the world of front-end development? Or if we find out that in specific tasks Angular cannot do exactly what we want from it and we want to do this part using something else? How relevant are Angular development skills in this case? Instead of JS developers, I would get people who have Angular as their main skill, not necessarily JavaScript itself.
2. Violates the division of responsibility. You can say that I have outdated views, but I still think that CSS should be used for decoration, HTML for the structure, and JavaScript for the application logic. But in the case of Angular, you spend a lot of time describing the behavior inside HTML instead of JS. For me personally, this is the most significant minus in Angular's reputation. I do not want to describe the application logic in HTML, it is simply not enough expressive means for such a task, because it is a markup language for defining the structure of the document, and not for describing the logic of behavior. To get around this point, Angular creates, in fact, another language inside HTML and sprinkles it with a small amount of JS to describe additional details. Again, instead of learning how to build applications in JavaScript, you learn Angular, and everything gets complicated. That's why my friend Ari's book on Angular is 600 pages thick!
3. Too much magic. For the magic you have to pay. When you work with something at a high level of abstraction, it becomes much more difficult to figure out what exactly is wrong when something starts to work crookedly. And, of course, when you get off the beaten path, very few people can help you. I may be mistaken, but I assume that most people using Angular have little understanding of the framework to such an extent that they can change or even debug Angular as such.
4. Almost does not provide structure for applications. I'm not sure that there is any canonical way to build a single-page application on Angular. Do not misunderstand me, I think that this is good, at least there is definitely nothing wrong with tools that do not impose any particular style of work, but it also means that it will be harder to understand someone else’s angular application or someone else. understand yours, because the writing styles are likely to be very different.

my subjective (and not insured from errors) conclusion

Too much logic is described using a pseudo-language inside HTML instead of JS, and all this gives the impression of being too abstract and magical.
I would rather like my team to be well versed with DOM and JS instead of learning high-level abstraction.

Ember.js

behind

1. A strong emphasis on doing the “The Ember Way” (note the first point in the “against”). This is a double edged sword. If you have a large team, which can potentially lead to a lot of confusion, the presence of a rigid structure can reconcile the desire to have common basic code and new developers who want to throw out everything written earlier to go away. If they are all Ember-developed, they are likely to quickly join a new Ember project for them.
2. Gives most of the complex problems encountered when building single-page applications to some incredibly intelligent people who will make a lot of difficult decisions for you (see the item in “against”).
3. Great responsive community.
4. Good site with docks.

vs

1. A strong emphasis on doing the “The Ember Way” (this is also in the pros). There are a lot of rules in Ember. Despite the fact that there is an opportunity to turn off the standard path, few people actually do it. For example, you are not required to use handlebars with Ember, but I would be very surprised if there are many Ember applications in production that do not.
2. The Ember code contains many specific opinions on how to solve a particular task. If you do not agree with these views and decide to replace individual pieces of functionality with your own, you still send all the unused code to the browser. Not that I like to count bytes, but it is conceptually better to be able to give the client only what is actually used. In addition, if you give only what you use, then you will have less code that you need to look through to detect the bug.
3. Big appetites for memory can also be considered a disadvantage, especially when Ember is launched on mobile devices .
4. Ember intentionally has no structural flexibility. Do not believe me? Then believe Yehuda (one of the two main Ember developers; the rest of the discussion is also quite interesting).

my subjective conclusion

The lack of flexibility and the feeling that when using Ember you either need to take it entirely or not to take it at all - these are the main reasons why I would not really like to deal with it.

React

It is worth noting that the truth is not quite honest to include React in this list. This is not a framework, but a presentation layer. But he is being so actively discussed that I decided to include it in this review. Basically, when you add a Facebook flux to it, it can already be considered a framework.

behind

1. The ability to rebuild the DOM without worrying about cleaning it up. React compares the virtual DOM that you have rendered to those in the real DOM at the moment, and makes minimal changes to synchronize them.
2. Virtual DOM also makes it easy to solve problems related to event handling in different browsers, providing a browser-independent and standards-compliant model of the emergence and "ascent" of events. As a result, you get a compatible event model in any browser.
3. React is just a presentation layer, not a framework as such. So you can use any tool when developing an application that you like. It fits well with Backbone, since Backbone does not provide a boxed solution to bind a view to a model, offering to re-render the view when the model changes, and it is for this process that React is sharpened.

vs

1. The template syntax and DOM creation method (using JSX) is a bit strange for a JS developer, simply because you need to store unquoted HTML in Javascript code as if it were valid. Yes, JSX is optional, but alternative: React.DOM.div (null, "Hello", this.props.name); - in my opinion, not much better.
2. If you really need complete and explicit control over changes in the DOM, React will not give it to you. For example, you need to clearly control how changes in style-attributes occur to create interfaces with the ability to drag and drop elements. You can not easily establish the order in which classes are added and so on (I want to note that I would call it a disadvantage, but I personally have no problems because of this, at the same time I communicated with the developers who suffered precisely with this feature React; in general, do not rely heavily on my opinion in this matter)
3. Despite the fact that it is possible to rebuild the entire view of React at once, if its components are complex enough, there is a strong suspicion that in some cases, finding out the differences between a virtual and a real DOM can become quite a laborious process. I heard that some developers using React implemented updating only those elements that were known to have changed, and this, in my opinion, discredits the very idea of ​​non-interference in the model rendering process. Again, in this matter I have little experience.

my subjective conclusion

A quick note about the “FLUX” architecture. For me, this is not a new information or idea, just a new name. And it seems that I am not alone in this opinion .
I understand the concept of FLUX as having a data layer with a reasonably made event system in something like Ampersand or Backbone with the transformation of all user operations and updates from the server into changes in the state of this layer.
If you want to ensure that user actions never lead directly to a DOM update, you will eventually come to the same unidirectional chain of events as in FLUX + React. We intentionally did not include any bidirectional binding of the model and representation in Ampersand for this reason. In my opinion, bidirectional binding is a potential source of danger. We have been using an architecture for many years in which only one layer deals with inbound events, no matter whether it is user input or server response.

Polymer

This guy is a bit weird for me. It is built on the basis of a standard that was developed to enable custom elements (document.registerElement for creating new HTML tags with embedded behavior), import HTML (‹link type = 'html'›) in order to import these custom elements into other documents ), and shadow DOM (to isolate CSS from the rest of the document)
All these things are great (except for HTML import, in my opinion).
But judging by the description of Polymer, there is a feeling that this is a universal tool to make all web development easy and beautiful, and that this framework is good for virtually everything. Here is a quote from the official site:

Web components are entering a new era of web development, based on encapsulated and interoperable custom elements that extend HTML as such. Made on the basis of these standards, Polymer makes it easier and faster to create anything from a simple button to an entire application for the desktop, mobile devices and anything else you can imagine.

Despite the fact that I consider the possibility of creating custom elements and encapsulating their behavior just fantastic, I am disappointed with the positioning of the framework. It feels like we now have to use it literally for everything.
A simple argument: I don’t know of any significant Google apps that would use polymer at least for something.
This is for me as a red traffic light. Don't get me wrong, obviously this is a new thing, but change takes time. The problem is simply that the text on the site, which is also an appeal from Google engineers working on Polymer, does not reflect this novelty.
In addition, even if you were creating a bunch of custom elements covering all your code for the presentation layer in a single-page application, the process of managing the creation / deletion of these elements should be organized. All of you also have to manage the state and choose the tools to build the internals of the application, which leads us to the fact that all these custom elements are in truth just another way of writing the equivalent Backbone view. In the world of one-page applications, I don’t see a big gain from the fact that we just go into coding these things inside custom elements.

behind

1. A wonderful opportunity to create such things as custom form elements, without waiting for their support in browsers.
2. Polymer is quite polyphilic, so you can start using and experimenting with its functionality right now.
3. Isolating widget creation styles has been a web problem for many years. New standards solve this problem at the browser level, which is just great.

vs

1. Personally, it seems to me that one of the main incentives for Google to create such a tool is the desire to embed their services, which include behavior, styles and functionality, into pages so simple that you don’t even need to know JS itself. I may be completely wrong in this assumption, but I cannot get rid of the feeling that marketing motivation is the main driving force for promoting new standards in this case.
2. HTML import seems like a bad idea to me. In fact, this is the same rake as in the case of CSS import . If you import something, you need to wait until the answer comes from the server, after which it turns out that this is something that imports another component and so on. Thus, if you really stick to a component-oriented approach for building a page that is presented as the best, you will have to deal with a bunch of network requests. True, there is a “vulcanizer” for the layout of dependencies. But the inline layout does not seem to me the right decision. A voluminous post about problems with HTML import was recently written, where this issue and some other problems are discussed.
3. I just don’t understand why Google is so aggressively promoting Polymer as if it were a panacea for development, despite the fact that the only example of a Google product where they use it that I managed to find is the Polymer site itself. The site states that "Polymer makes it easier and faster to create anything from a simple button to a whole application for the desktop, mobile devices and everything that you can imagine." From my experience with Polymer, the opposite is rather obvious, I feel that they want to deceive me.

my subjective conclusion

For some reason, Google does not eat what he himself is preparing. The specification on document.registerElement is fascinating, I see no other use for Polymer, except as a polyfile for this functionality, I'm sorry.

Backbone

There is no more common framework for building single-page applications used in production versions of sites than Backbone I know of. The examples section in the Backbone documentation lists a large number of known sites, and it’s far from complete.

behind

1. This is a fairly small and flexible set of well-tested blocks for building applications.
   
   • Models
   • Collections
   • Views
   • Router
   
   
2. He solves most of the major problems.
3. Its focused functionality allows you to quickly figure it out. I always let me examine the Backbone.js documentation as the first task for all new front-end developers who come to the & yet team.

vs

1. Backbone does not provide solutions for all problems that you encounter during development. Therefore, from my experience, everyone who uses backbone has to create their own “framework” on top of the Backbone base.
2. Most likely when using pure Backbone you will miss the following things:
   
   • Ways to create secondary properties for models
   • The way of binding properties, including those secondary to the representation
   • The way to render a set of views inside any element
   • A simple way to work with subviews, dependent layouts and the like
   
   
3. Despite the minimalism of Backbone, its components are too connected with each other. For example, until a release involving the merge of my pull request , it was impossible to use any other type of Model within the Backbone Collections without local changes to internal methods. This may be noncritical for some applications, but this is necessary if, for example, I want the model to store observable data in a library, with which other code, not necessarily dependent on Backbone, should be able to work. The only way to use Backbone Models is to include the entire Backbone in the project, which seems to me wrong and ineffective.

my subjective conclusion

Backbone was the discoverer of many wonderful things. I have been using it since version 0.3 and I am very impressed with its minimalistic concept.
He stimulated the emergence of a new generation of applications that have begun to use the browser as a medium of execution, and not as an engine for rendering documents. But its narrow specialization leads to the fact that developers have to write their solutions on top of Backbone. Despite the fact that this is not bad in and of itself, it just becomes obvious that the development will have to deal with a large number of problems.

No framework

There is a subset of developers who believe that frameworks should not be used at all. This point of view is close to me in many respects and I agree with the main arguments, but such an approach is simply not expedient, especially in the case of team development.
I tend to agree with the position indicated in the post by Ryan Florence , which is best described in this quote:
When you decide not to use a public framework, in the end you will come to the conclusion that you still use the framework, only it will be your own.
He further says that this is not a bad decision by default, but you need to be serious, maintain your code, and so on. I highly recommend reading this post, it is just great.

behind

• Ultimate flexibility
• You can include in the assembly only the code that you actually use in your application.

vs

• A large amount of work on the invention of bicycles and, as a result, the high cost of development
• It is more difficult to understand which modules to use and which ones are better suited in this situation.
• Lack of clear documentation and agreements for new developers
• Difficult adaptation and reuse of code in new projects
• You will have to learn from your mistakes instead of taking advantage of someone else’s proven code.

HUGE abyss

In the process of conducting our seminars and preparing my book Human JavaScript , as well as within our team as such, we came to understand that there is a huge gap between the process of choosing a tool, framework or library, and directly developing a complete application.
I’m not saying that the question “how to create an application by the team’s forces so as not to crush each other’s legs and other parts of the body?” Confronts us with a number of serious problems. After all, apart from the question of choosing a framework, we still have a lot of ways and patterns that we can use to structure, build and deploy applications.
A very small number of people write about these issues, although this rabbit hole seems no less profound than the one we find ourselves trying to choose a framework.

What we really want

• To make it clear where to start
• Understandable, but not the only possible way to solve typical problems.
• Extremely clear division of responsibility for easy replacement and combination of different parts of the application.
• Easy dependency management
• Ability to use existing proven solutions without inventing bicycles
• Development infrastructure, in which we can switch between dev and prod modes by simply changing the boolean variable in the config

What do we offer about this?

So, if you have not yet guessed, we have done a terrible thing for the world of JavaScript. Namely, the "new" framework: Ampersand.js . Slightly reminiscent of the lightweight Backbone or its offshoot.
Feedback is extremely positive so far, we announced it in the middle of summer, and a number of great guys have already joined the work on its development. There were already reports about him at conferences , and Jeremy Ashkenaz, the creator of Backbone.js, Underscore.js, and CoffeeScript asked me to make a keynote about Ampersand.js on BackboneConf 2014.
How did we try to take into account all the shortcomings that I listed above with respect to other frameworks?

1. Flexibility and Extensibility
   
   • Ampersand has a set of “kernel” modules (see the documentation) that roughly correspond to the set of Backbone components. But they can all be installed and used separately. It is not assumed that you must use RESTful or the Ajax API in general. If you do not need these things, you simply use Ampersand-State, and not its decorated version, the Ampersand-Model, which complements State RESTful methods.
   • Included is no template. Templates can be specified by elementary strings with HTML, functions that return such strings, or functions that return DOM elements. In the demo application, there are examples of using more complex templatizer templates, but in fact, templating can be done with anything. For example, there is a remarkable approach in the style of handlebars / htmlbars + Ember with the declaration of bindings inside the template itself, implemented in domthing by Philip Roberts. There are developers using React in conjunction with Ampersand views.
   • In views (views), you can set data bindings, regardless of the template engine. That is, if necessary, you can use just HTML strings as templates and still completely control the process of linking data with their presentation. The lack of a template in the standard package allows you to create modular / reusable views without having to drag the template with them.
   
   
2. There must be some obvious starting point and a conceptual scheme for setting the structure of the application, but these things should not be turned into obligatory ones. We created a CLI that you can use to create a framework for new applications. It takes as a basis a number of such agreements, and can serve both for the initial stage of development, and simply as a source of useful knowledge. More information can be found in the manual .
3. We decided that it is better to base something with a good reputation than to create a new framework, just to create a new framework. Therefore, we took Backbone as a basis, and did not do everything from scratch.
4. I also wanted to have a more complete manual that eliminates this chasm, which I mentioned above. It should pay attention to all surrounding concepts, tools and paradigms. To do this, we wrote the book Human JavaScript. It can be read entirely online for free, and it is also available in e-book format.
5. We wanted to make it easy to use existing solutions of common problems to minimize cycling in projects. Therefore, we use npm to manage all the packages, and have made a catalog of our favorite clientside modules with a convenient search.
6. I also wanted to have the possibility of a smooth transition from the dev-environment to the production. We solve this problem using moonboots , which adds this functionality to browserify. Moonboots has a plugin for hapi.js and express.js , where everything you need to do to change the mode of the application from the production version (minified, cached static assemblies with unique names) to dev (reassemble the code for each new request, do not minify and do not cache anything) - this is to change the value of one boolean variable.
7. We did not want this project to belong exclusively to ours & yet. We already have about 40 contributors since we told everyone about Ampersand.js and we recently added the first of, I hope, many non-of-yet-contributors to the framework core project. All parts use the extremely loyal MIT license, and the modular weakly-connected framework structure in itself makes it possible to replace or expand any of its components to meet your requirements. We also got a separate organization for this project on GitHub.
8. I also wanted to provide additional support and training if necessary. To do this, we made the IRC channel # & yet available on freenode for questions and support. In addition to free resources, we did an online course “Human JavaScript code-along” and offline seminars with practical exercises and feedback.

So you want to say that Ampersand is definitely the best choice?

Not. He certainly has his own list of compromise solutions. Here are some of them that are obvious to me, probably, there are more:

• Naturally, Ampersand has a few more immature code base compared to some other similar tools. Recognizing this, we, however, use it in all single-page applications developed by us, and all basic modules have good test coverage. It is worth noting that if you still encounter a problem, most likely you will be able to deal with it yourself. , , , - . . npm -. , , . , , - . , , - -, . , , .
• Ampersand . , , , , . , , , Ampersand.
• Ampersand. , , IE8. , jQuery 2.0 , Google IE IE9 , Microsoft . ? , . , , , . , , ( , ). , IE8 . - browserify transform, , . , , , , , IE 7 8 Ampersand-State.

Finally

, . - - , .
. , . .