JavaScript throne: the sword of the seven frameworks

A week ago, the ThroneofJS conference was held in Toronto. This should be the most expected and most different one I attended. The official website of the Conference said: loading the entire page and then gradually increasing it to add dynamic behavior. This method of building Web applications is not good enough. To make the application load faster... SyntaxHighlighter. all ();

A week ago, the Throne of JS conference was held in Toronto. This should be the most expected and most different one I attended. The official website of the Conference said:
Load the entire page, and then "incrementally enhance" to add dynamic behavior. This method of building Web applications is not good enough. To make applications load fast, be responsive, and take the lead, you must thoroughly review your development methods.
The Conference invited the creators of the seven major JavaScript frameworks/libraries to gather together and exchange their technical ideas face to face. The seven frameworks/libraries are: AngularJS, Backbone, Batman, CanJS, Ember, Meteor, Knockout, and Spine. 1
Statement: I will talk about Knockout at the meeting, so my point of view is obviously not neutral. In this article, I will focus on the ideas and technical concepts of these creators and try not to mention what I agree with or disagree.
1. That's right. It's eight frameworks, not seven. But in the end, the conference organizer did not clearly explain the problem to us ......

The article is long. Let's give an overview:
● For many Web developers, it is a matter of course to use the client framework to build rich Web applications. If you do not use any frameworks, either you are not doing applications or you will miss many good things.
● In terms of usage, these frameworks are consistent in many aspects (Model-View-* architecture, declaration binding, etc.-see below). Therefore, in a certain sense, no matter which one you choose, you can enjoy the same benefits.
● There are still many differences in concept, especially regarding the framework and database. Your choice will have a profound impact on your architecture.
● The Conference itself is lively and novel, and there are many exchanges and dialogues between technical teams. I hope to have more similar meetings.
Technology: consensus and disagreement
With the presentation of each SPA (Single Page Application) technology, some significant similarities and differences have surfaced.
Consensus: progressive enhancement cannot build real applications
Various technical teams agree that a real JavaScript Application must have an appropriate data model and client rendering capabilities, not simply the server's ability to process data, but also the simplicity of Ajax and jQuery code.
In the words of Jeremy Ashkenas, the creator of Backbone, "today, you say 'single-page application' is about the same as 'car without marat'." (meaning, it's not that fresh.) 2.
2 horseless carriage is what people call a car when it was just invented. -- Translator's note
Consensus: Model-View-xx
All technical teams adhere to Model-View separation. Some emphasize MVC (Model View Control), some mention MVVM (Model View ViewModel), and some even refuse to explicitly say the third word (only Model and View are mentioned, and then add things that allow them to coordinate operations ). The final results are similar to those of various schools.
Consensus: Data Binding
In addition to Backbone and Spine, other frameworks have built-in mechanisms for declaring data binding in their own views (the design concept of Backbone emphasizes "Custom view Technology" for users ").
Consensus: IE6 is dead
In the group discussion, most framework creators said that their support for IE browsers is limited to 7 + (in fact, the starting point of Ember and AngularJS is IE8, batman needs ES5 "gasket" to be used in IE versions earlier than IE9 ). This is also the trend of the times: jQuery 2 is no longer planning to support earlier IE versions earlier than IE9.
Only Backbone and Knockout firmly support IE6 + (I don't know the internal implementation of Backbone, but Knockout will block the crazy rendering and weird event BEHAVIOR OF IE6/7 ).
Consensus: License and source code control
Everyone uses the MIT license and is hosted on GitHub.
Differences: libraries and frameworks
This is the biggest difference currently. The following table classifies JavaScript libraries and frameworks:

* The numbers in the brackets indicate the number of contributors on GitHub at a recent time point, roughly representing their respective influences.
What does it mean?
● The JavaScript library is inserted into the existing architecture to supplement specific functions.
● The JavaScript framework provides an architecture (file structure, and so on). You must abide by it. As long as you comply with it, all the rest will be dealing with general requirements.
Currently, Ember is the most powerful advocate of framework models. Its creator, Yehuda Katz, was a (similar concept) Developer of Rails and SproutCore projects. In his opinion, the lack of any component is not powerful enough, and it cannot be said that it is truly promoting technological progress. On the contrary, the purpose of the library is clearer, so it is easier to master, adopt, and customize. It also helps minimize project risks. After all, your architecture will not depend heavily on any external project. According to my participation in the conversation, the audience members were also divided into two schools, with support frameworks and libraries.
Please note that AngularJS is a form between the library and the framework: it does not require the development to follow the specific file organization mode (similar to the Library), but at runtime, it provides an "application life cycle", which allows you to arrange the code (similar to the Framework) on the incoming seat ). The AngularJS team is willing to accept this statement.
Differences: flexibility or integration
Each technical school has different levels of mandatory provisions:

 
It is hard to imagine that as long as a database is open in a certain aspect, their people will emphasize that only in this way can they ensure compatibility with third-party libraries in general. Likewise, the obvious objection is that only built-in systems can ensure seamless integration. Once again, according to the conversation I attended, the audience also had their own opinions and said everything. Basically, we can see how much everyone knows about other technical combinations.
Tom Dale of Ember said: "We have added a lot of magic, but they are all useful magic. In other words, they can be broken down into regular operation primitives ."
Differences: string-based templates and DOM-based templates
(See the preceding table .) For string-based templates, almost everyone chooses Handlebars. js as the template engine, which has become the dominant in this field. Of course, CanJS uses EJS. For string-based templates, the supported people think that "it is faster" (not necessarily), and "in theory, the server can also process it" (not necessarily, because the premise must be to run all the model code on the server, but no one does it in practice ).
DOM-based templates mean to control the process (each, if, and so on) by binding in the actual tag, without relying on any external template library. The supported voices include "it is faster" (not necessarily). In addition, "the Code is easy to read and write, and there is no gap between the tag and the template, and how CSS interacts with it is clear at a glance ."
In my opinion, the most attractive argument comes from the AngularJS guys who think that in the near future, DOM-based templates will be supported by browser native. So we 'd better use it now to easily cope with the future. AngularJS is from Google, so they will consider this when developing Chromium, And will persuade standard subjects to accept this suggestion.
Divergence: to what extent is the server neutral?
Batman and Meteor are obviously dependent on servers: Batman is designed for Rails, and Meteor is itself a server. Most others are pursuing server-neutral. But in fact, Ember's architecture, mandatory regulations, and some tools tend to be Rails developers. Of course, Ember can definitely be used with other server technologies, but more manual configurations are required now.
Technical School Overview
The following are the basic technical details of all JavaScript libraries/frameworks.
Backbone
● Who: Jeremy Ashkenas and DocumentCloud.
● What:
+ Use JavaScript to Implement Model-View and MIT permission.
+ There is only one file with 1000 lines of code, which is the minimum among all databases!
+ The function is extremely specific. It only provides restful durable models and simple routing and callback (so that you can know when to render the view, but the view rendering mechanism is up to you ).
+ Most famous websites are used by many big names (maybe because it is the smallest and easy to deploy ).
● Why:
+ Very small. before using it, you can fully read and understand its source code.
+ Your server architecture or file organization will not be affected. You can run it in a certain part of the page-you do not need to control the whole page.
+ Jeremy seems to have entered a kind of status that Zen calls the final state, and he can accept everything with confidence. He is like an adult watching a group of children debate there.
● Where: GitHub and its own site.
● When: it has been around for nearly two years.
Meteor
● Who: Meteor Development Team (they have just raised $11.2 million in investment, so they can be full-time developers ).
● What:
+ A highly prospective framework does not seem to anyone who is so radical (maybe Derby is one ).
+ Connect a Server Runtime Environment (built with Node + Mongo) with a client runtime environment, so that your code can run at both ends, and contain databases. Use WebSockets to synchronize all clients and servers.
+ "Real-time deployment" when modifying code -- the client can be instantly updated without losing its status.
+ You can watch this video to have a more comprehensive understanding of it.
+ Like all the people I have talked with at the meeting, I sincerely hope that this framework will be successful-Web development will require such radical reform to make real progress.
● Why: You really think it is boring to do regular Web development.
● Where: GitHub and its own site.
● When: The birth time is not long. Except for the use of its core team, it is unknown that there are no other sites actually using Meteor. However, this team is seriously doing something unprecedented.
Ember
● Who: Yehuda Katz (previously developed jQuery and Rails), Ember team, and Yehuda company Tilde.
● What:
+ MIT permits everything required to build a "Super Web application.
+ The maximum number of functions and the maximum size.
+ It incorporates many design concepts, including how to break down and hierarchical control of pages, and how to use a state machine-driven system to link various layers.
+ A fully functional Data access library (Ember. Data) is being developed ).
+ To control the entire page at runtime, it is not suitable for developing the "rich application zone" on the large page ".
+ There is a strict set of constraints on files and URLs, but if you don't like it, you can rewrite it as long as you know how to do it.
+ The design is inspired by Rails and Cocoa.
+ Tool: provides a project template for Rails (if you write code manually, you can also use other server platforms ).
● Why: common solutions should be available for common problems-Ember provides all common solutions.
● Where: GitHub and its own site.
● When: Version 1.0 has not yet been released, but it is also coming soon. Then, the API is stable.
● AngularJS
● Who: Google (they are used internally ).
● What:
+ Use JavaScript to Implement Model-View-others, with MIT license.
+ DOM-based templates with observability, declarative binding mechanisms, and quasi-MVVM code styles (they themselves say Model-View-Whatever)
+ Built-in basic URL routing and data persistence capabilities
+ Tool: comes with a Chrome debugger plug-in that allows you to view the model during debugging. It also comes with a Jasmine testing framework.
● Why:
+ In terms of concept, they say that the framework is equivalent to a "filler layer" built on the current browser, in order to achieve the future, the browser may have native capabilities (that is, declarative binding and Observability capabilities ). Therefore, we should start writing code now.
+ It does not affect the server architecture or file organization mode. It can be used in a small part of the page-you do not need to control the whole page.
● Where: GitHub and its own site.
● When: finished framework, which has been developed by Google for some time.
Knockout
● Who: the Knockout team and the community (the core team currently has three members, including me ).
● What:
+ Model-View Model (MVVM, Model-View-ViewModel) is implemented using JavaScript, with MIT license.
+ Functions are concentrated on rich user interface elements: DOM-based declaration binding templates, and the observed models are added with automatic dependency detection.
+ There is no limit on URL routing or data access-any third-party libraries can be combined (for example, Sammy. js is used for routing and pure Ajax is used for storage ).
+ A great deal of effort has been made to lower the threshold for use, providing detailed documents and interactive examples.
● Why:
+ Only one thing (UI) is done, which is backward compatible with IE6.
+ It does not affect the server architecture or file organization mode. It can be used in a small part of the page-you do not need to control the whole page.
● Where: GitHub and its own site.
● When: it has been officially released for nearly two years.
Spine
● Who: Alex MacCaw.
● What:
+ Implement MVC and MIT licenses using JavaScript.
+ Developed from the sample code written in the oldest o'reilly book, it has become an OSS (Open Source Software) project.
+ Is a derivative version of Backbone (you can see the name 3 ).
● Why: You like Backbone, but want something different.
● Where: GitHub and its own sites
● When: v1.0.0 has been released.
3 Backbone and Spine both mean "Spine. -- Translator's note
Batman
● Who: Shopify (an e-commerce platform company) team.
● What:
+ Implementing MVC in JavaScript is almost customized for Rails + CoffeeScript developers, with the MIT license.
+ Is the most mandatory in all frameworks. You must follow the conventions (for example, how to organize files and URLs ). Otherwise, as they said in the slides, "you should use other frameworks ".
+ A very well-developed framework with rich models, views, controllers, and routes. Of course, there is also an observation mechanism.
+ DOM-based templates.
● Why: If you use Rails and CoffeeScript, you find your loved one.
● Where: GitHub and its own site.
● When: the current version 0.9 will be released in a few months.
CanJS
● Who: a team of Bitovi (a JavaScript consulting/training company.
● What:
+ Implement MVC using JavaScript and MIT permit.
+ REST durable model, basic routing, and string-based template.
+ Not well-known (I heard about it last week), but its predecessor was the original JavaScriptMVC project.
● Why: aims to integrate the strengths of the above technical teams, provide similar functions with them, while keeping them small.
● Where: GitHub and its own site.
● When: Version 1.0 has been released.
Summary
If you are considering the selection and want to know which of the above frameworks/libraries is most suitable for your new project, I suggest you focus on the following two points.
Function scope. How much do you want this framework or library to do for you? Your project starts from the ground up. Therefore, do you need an architecture that can provide complete functions throughout the entire process? Or do you prefer to select the mode and library? It is correct to make any choice for different projects and teams.
Design Aesthetics. Have you seen their code and built some small applications using a framework you have never chosen? Do you like this? Do not just look at their descriptions or function lists to make a choice: those information is valuable, but not comprehensive. For example, if you ignore your own subjective coding experience, it's like you only have several chapters when choosing a novel, or you can only view your resume or personal description when looking for an object.
Despite the differences, I believe that all technical schools share a major commonality: They all practice the idea of separation of models and views. This idea already exists before the birth of Web, and has been around for 20 years now. In this case, even if you only make a basic Web application UI, the idea of using the client application will always be correct.

Author: Li songfeng