JavaScript throne: The seven great frames on swords

JavaScript throne: The seven great frames on swords

A week ago, the Throne of JS conference was held in Toronto, which should be the most material and the most unusual meeting I have ever attended. The website of the conference says:

Loading the entire page and then "progressive enhancement" to add dynamic behavior is not good enough to build a web app. To make your application load fast, responsive, and trend-driven, you must thoroughly review your development tools.

The Conference invited the creators of the seven JavaScript frameworks/libraries, who gathered and exchanged their own technical ideas in person. The so-called Seven frames/libraries are: AngularJS, Backbone, Batman, Canjs, Ember, Meteor, Knockout, Spine. 1

statement: I speak knockout at the meeting, so my view is clearly not neutral. In this article, I focus on the ideas and technical ideas of these creators, and try not to mention what I approve or oppose.

1 Yes, 8 frames, not 7. But what is going on, the organizers of the meeting did not give us a clear explanation ...

Article can be long, first outline:

• For many web developers, it is natural to use the client framework to build rich Web applications. If you don't have any frameworks, either you're not doing the app or you're missing out on a lot of good stuff.
• In terms of usage, these frameworks are consistent in many places (model-view-* schemas, declarative bindings, and so on-see below), so in a sense, whichever you choose, you get the same benefits.
• There are still many differences in the concept, especially in the view of the framework and the library, the differences are particularly large. Your choices will profoundly affect your architecture.
• The conference itself is lively and novel, and there are many exchanges and dialogues between the technical groups. I would like to have more meetings like this.

Technology: Consensus and disagreement

As each spa (single page application) technology is presented, some fairly obvious similarities and differences emerge.

Consensus: Incremental enhancement does not create a real application

Technology portals agree that real JavaScript applications must have the right data model and client-side rendering capabilities, not just the server processing data plus some Ajax and jquery code.

Using backbone to create a person Jeremy Ashkenas said: "Now, you say ' single page application ', and say ' no horse-drawn car ' almost" (meaning, it is not so fresh) 2.

2 "No horse-drawn car" (horseless carriage) is the car just invented when people call it. --Translator's note

Consensus: Model-view-XXX

All technical portals insist on model-view separation. Some emphasize MVC (Model View Control), some refer to MVVM (Model View ViewModel), and even someone refuses to explicitly say a third word (just mention models, views, and then add things that let them work together). The end result is similar to the factions.

Consensus: advocating data binding

In addition to backbone and spine, other frameworks have built a mechanism for declaring data binding in their own view (the design philosophy of backbone emphasizes the user "optional View technology").

Consensus: IE6 is dead

In the panel discussion, most of the creators of the framework said that their support for IE was limited to 7+ (in fact, the starting point for Ember and Angularjs was that Ie8,batman needed ES5 "shims" to be used in the IE version prior to IE9). This is also the trend: JQuery 2 is no longer intended to support the old version of IE under IE9.

Only backbone and knockout strongly support ie6+ (I'm not sure about backbone's internal implementation, but knockout will block out IE6/7 's maddening rendering and event-related quirks).

Consensus: Licensing and source code control

Everyone uses the MIT license and is hosted on GitHub.

Disagreement: the library, or the framework

This is the biggest disagreement at the moment. The following table categorizes the JavaScript libraries and frameworks:

JavaScript Library	JavaScript Framework
Backbone (9552)	Ember (3993)
Knockout (2357)	AngularJS (2925)
Spine (2017)	Batman (958)
CANJS (321)	Meteor (4172)--great, see below

* * The numbers in parentheses are the number of followers on GitHub at a recent point in time, roughly representing their respective influence. *

What do you mean?

• JavaScript library , plugged into an existing architecture, complements specific functionality.
• JavaScript Framework , which provides a schema (the file structure ah, and so on), you have to obey it, as long as you obey, the rest is to deal with the general requirements.

For now, the most mater hard of the advocacy framework model is Ember, whose creator Yehuda Katz was (similarly) a developer of rails and sproutcore projects. His view is that the lack of any component is not enough to be able to say that it is really driving technological progress. The opposite view is that the purpose of the library is clearer and therefore easier to master, adopt, customize, and help minimize project risk, after all, your architecture does not rely heavily on any external project. According to my participation in the dialogue, the audience is divided into two groups, there is support framework, there are support library.

Note that ANGULARJS can be said to be somewhere between the library and the frame: it does not require development to adhere to a particular file organization (similar to a library), but at run time it provides an "application lifecycle" that can be assigned to the code (similar to a framework). The reason for putting it in the framework is because the ANGULARJS team is happy to accept it.

Differences: flexible, or integrated

Each technology portal has varying degrees of mandatory requirements:

	view	URL route	data store
AngularJS	built-in base Template for Dom (required)	built-in (optional)	built-in system (optional)
Backbone	Optional (most commonly, string-based template library handlebars. JS)	built-in (optional)	built-in (overridable)
Batman	built-in DOM-based templates (required)	built-in (required)	built-in system (required)
canjs	built-in string-based template (required)	built-in (optional)	built-in (optional)
Ember	built-in string-based templates (required)	built-in (required)	built-in (overridable)
Knockout	built-in DOM-based templates (optional, you can also use string-based templates)	preferences (mostly using Sammy.js or history.js)	preferences (such as Knockout. mapping or $.ajax only)
Meteor	built-in string-based templates (required)	built-in (required?) Not sure)	built-in (Mongo, required)
Spine	Optional String-based template	built-in (optional)	built-in (optional?) Not sure)

It is not difficult to see that as long as a library is open in some way, their people will emphasize that this is the only way to ensure compatibility with third-party libraries in general. Similarly, the obvious objection is that only the built-in can guarantee seamless integration. Again, according to the dialogue I participated in, the audience also disagree, say what all have, basically can see each person to other technology combination of understanding degree.

Ember Tom Dale said: "We have added a lot of magic, but all are good magic, in other words, they can be broken down into normal operations." ”

Alternative translation Method

We use a lot of "spells", but all are good "spells", meaning they can be decomposed into reasonable basic components.
@ Liancheng 404 Our code is highly technical, but it is not heterodoxy, it is something that is made up of regular basic semantic elements.
@ Yuber is also called Condor we achieve a lot of clever integration, really very ingenious, these integration can be decomposed into normal operation.

Differences: string-based templates and Dom-based templates

(Please refer to the table above.) For the string-based template, almost all of us choose Handlebars.js as the template engine, it has become the Overlord of this field, of course, canjs use is Ejs. For string-based templates, the supporters think "It's faster" (not necessarily), and "Theoretically, the server can also handle it" (not necessarily, because the premise must be to run all the model code on the server, and no one does it in practice).

The DOM-based template, however, means that the process is controlled purely by binding in the actual markup (each, if, and so on) and does not depend on any external template libraries. The supported sounds are "it's faster" (not necessarily), the other "code is easy to read, easy to write, and there is no gap between the markup and the template, and how the CSS interacts with it is at a glance." ”

In my opinion, the most appealing claim comes from Angularjs, who think that in the near future, Dom-based templates will be natively supported by browsers. So we'd better use it now so we can handle the future with ease. Angularjs comes from Google, so they will consider this when developing chromium, and will persuade standard subjects to accept the proposal.

Divergence: To what extent server neutrality

Batman and meteor are obviously dependent on the server: Batman is designed for rails, and meteor itself is the server. Most of the others pursue server neutrality. But in fact, Ember's architecture, mandatory rules, and some tools tend to be for rails developers. Of course, Ember can definitely be paired with other server technologies, but it needs more manual configuration at the moment.

Technical Portal Overview

The following are the basic technical details of all JavaScript libraries/frameworks.

Backbone

• Who : Jeremy Ashkenas and Documentcloud.
• What :
  + use JavaScript to implement the model-view, MIT License.
  + Only one file, 1000 lines of code, smallest in all libraries!
  + features are extremely exclusive, providing only rest durable models and simple routes and callbacks (so you know when to render the view, but the view rendering mechanism is your choice).
  + The most famous, many big-name sites are in use (perhaps because it is the smallest, easy to deploy).
• Why:
  + Very small, before using it, you can fully read and understand its source code.
  + does not affect the way your server schemas or files are organized. Can run in a section of the page-no need to control the entire page.
  + Jeremy seems to have entered a kind of zen so-called Samadhi state, for everything can be accepted frankly. He was like an adult, watching a group of children debating there.
• Where: GitHub and its own site.
• When : nearly two years have been born.

Meteor

• Who : The Meteor development team (they have just raised a $11.2 million investment, so they can develop full-time).
• What :
  + A very forward-looking framework that can't figure out who's so aggressive (maybe Derby is one).
  + Connect a server-side runtime environment (built with Node+mongo) and a client runtime environment to allow your code to run on both ends and include the database. Use WebSockets to achieve synchronization between all clients and servers.
  + "real-time deployment" When code is modified-the client runtime can be updated without losing status immediately.
  + Take a look at this video and get a more complete understanding of it.
  + With all the people I have communicated with at the meeting, I sincerely hope that this framework will be successful--web development requires this radical reform to make real progress.
• Why : You really think it's too boring to be a regular web developer, looking for some excitement.
• Where: GitHub and its own site.
• When : The birth time is not long, in addition to its core team in use, do not know if there are other sites actually in use Meteor. But the team is really serious about doing something unprecedented.

Ember

• Who : Yehuda Katz (previously developed jquery and rails), the Ember team, and Yehuda's company tilde.
• What :
  + Everything you need to build a "super Web App", MIT License.
  + The most functions, the largest volume.
  + incorporates a number of design concepts, involving how to break down and hierarchical control of pages, and how to use a state machine-driven system to connect all levels.
  + is developing a well-functioning data Access library (Ember.data).
  + to control the entire page at run time, it is not appropriate to develop "rich apps" on large pages.
  + have a strict set of constraints on files, URLs, etc., but if you don't like it, you can rewrite it if you know what to do.
  + Design inspiration from rails and cocoa.
  + Tools: Provide project templates for rails (but you can also use other server-side platforms if you write code manually).
• Why : common problems should have a common solution--ember provides all the common solutions.
• Where: GitHub and its own site.
• When : version 1.0 has not yet been released, but it is fast. Then, the API will basically stabilize.

AngularJS

• Who : Google (which they use internally).
• What :
  + Implement model with JavaScript-view-Other, MIT license.
  + DOM-based templates with observable capabilities, declarative binding mechanisms, and quasi-MVVM code styles (they say model-view-whatever)
  + Built-in basic URL Routing and data persistence capabilities
  + Tools: Comes with a chrome debugger plugin that allows you to view the model while debugging, and a Jasmine test framework.
• Why :
  + Conceptually, they say this framework is equivalent to a "filler layer" that is covered in the current browser to enable future browsers to have the ability to be native (that is, declaring bindings and observable capabilities). So, we should start writing this code now.
  + does not affect the way the server schema or file is organized. Can be used in a small part of the page--no need to control the entire page.
• Where: GitHub and its own site.
• When : finished frame, Google has been out for a while.

Knockout

• Who : Knockout Team and community (the core team currently has three people, including me).
• WHAT:
  + use JavaScript to implement model-view-view model (Mvvm,model-view-viewmodel), MIT License.
  + Features focus on rich user interface elements: DOM-based declarative binding template, observable model plus automatic dependency detection.
  + No Limited URL routing or data access--can be combined with any third-party libraries (for example, using Sammy.js for routing, with pure Ajax for storage).
  + has done a lot to reduce the threshold of use, providing detailed documentation and interactive examples.
• Why:
  + Just do one thing (UI), backwards compatible to IE6.
  + does not affect the way the server schema or file is organized. Can be used in a small part of the page--no need to control the entire page.
• Where: GitHub and its own site.
• When : It has been officially released for almost two years now.

Spine

• Who : Alex Maccaw.
• What :
  + Implement Mvc,mit license with JavaScript.
  + Developed as an example code written by the first O ' Reilly, has become an OSS (open source software, open source software) project.
  + is a derivative version of backbone (see Name to Know 3).
• Why : you like backbone, but you want something different.
• Where: GitHub and its own site
• When : v1.0.0 has been released.

3 backbone and spine are all "spine" meanings. --Translator's note

Batman

• Who : A team of Shopify (an e-commerce platform company).
• What :
  + MVC implemented in JavaScript, almost exclusively for Rails+coffeescript developers, MIT license.
  + is the most mandatory in all frameworks. You must abide by its conventions (for example, how to organize files and URLs). Otherwise, as they say on the slide, "You should use a different frame."
  + A very well-developed framework with a fairly rich model, views and controllers, and routing. There are, of course, observable mechanisms.
  + DOM-based templates.
• Why : If you use rails and coffeescript, you find loved ones.
• Where: GitHub and its own site.
• When : current version 0.9 will release version 1.0 within a few months.

Canjs

• Who : A team of Bitovi (a JavaScript consulting/training company).
• What :
  + Implement Mvc,mit license with JavaScript.
  + Rest durable model, basic routing, string-based templates.
  + Not very well-known (I also heard it last week), but its predecessor is the original JAVASCRIPTMVC project.
• Why: It aims to set the strengths of the above-mentioned technical portals and provide them with similar functions while maintaining a compact size.
• Where: GitHub and its own site.
• When : version 1.0 has been released.

Summarize

If you are considering a selection question and want to know which of these frameworks/libraries are best for your new project, then I suggest you focus on the following two points.

• Functional Range . How much do you want the framework or library to do for you? Is your project starting from scratch, so you need a complete, fully functional architecture that runs through all the Times? Or, do you actually prefer to pick your own patterns and libraries? For different projects, different teams, any choice is valuable, is correct.
• Design Aesthetics . Have you ever looked at their code and built some small applications with a frame that didn't use your choice? Do you like to do it? Don't just look at their descriptions or feature lists to make a choice: the information is valuable, but not comprehensive. For example, if you disregard your own subjective coding experience, it's like choosing a novel with only a few chapters, or looking at a person's resume or personal description.

Despite the differences, I think all technical portals have a significant commonality: they both practice the idea of separating the model from the view. This idea existed before the advent of the web, and it is now almost 20 years old. Let's just say that even if you only do a basic Web application UI, the idea of applying this in the client is always correct.

Finish

http://www.ituring.com.cn/article/8108

JavaScript throne: The seven great frames on swords