Angular vs Derby. There must be only one

Such a loud name suggests that today we will compare the MVC concept on the client (Angular, Ember, Backbone, Marionette, Knockout, and so on) with the Full-Stack concept (Derby, Meteor). Let us examine the pros, cons, myths, delusions.



')

Background

Long ago, when MVC was just beginning to be popularized in the minds of web developers, it was on the server. Django, Ruby on Rails, Asp Net MVC, Yii are examples of great MVCs on the server. Everyone chose their own language to their liking, static pages flew over wires, jQuery - oh, it was a great time. Thunder struck suddenly. It turned out that users do not want to wait after each click until the entire page is reloaded, and they want to work on the web more like working with regular programs - interactive. At first glance, jQuery + Ajax could solve this problem, but as soon as the web developers began to sink into unstructured code in the browser, it became clear that more dramatic changes were required.

The idea was that if MVC had already successfully structured the code on the server, then it could solve the problem on the client. The first truly popular MVC on the client was Backbone, which is a very elegant and simple solution. Then everyone tried to create the framework of their dreams and the world saw Angular, Knockout, Batman, Ember and many other similar frameworks. There were whole projects that help not to get lost in this abundance. Router, templates, backend, REST-api, data over wires are all symbols of this joyous era. Happiness seemed to last forever and nothing could darken the serene future.

Problems

The first to run into problems were Twitter. In general, they went all the way. We started with Ruby on Rails and generating html on the server, then copied everything on MVC on the client and at some point realized that the user was waiting for 4 seconds to read 140 characters of text. Now they generate part of the html on the server using Scala, and part on the client using JavaScript. Google does this, they generate html on the server using C ++, and on the client using JavaScript. This architecture is difficult to maintain and is not available for small companies and start-ups.

Search engines like to get html from server more than Javascript. Sometimes they try to solve the problem by generating html on the server specifically for search engines in addition to MVC on the client for users. Others abandon MVC on the client in favor of MVC on the server, sacrificing interactivity for SEO.

In an era of interactivity, users want to see in their browser data changes made by other users immediately. Data synchronization between clients is not a trivial task, it requires the server part and cannot be solved in MVC categories on the client.

Replaceable backend

One of the main arguments for MVC on the client is the ability to easily change the backend. Changing the backend is not an easy procedure, because MVC on the client assumes that the server has at least REST-api, validation, work with data, authorization. In real life, the backend almost never changes.

The ability to change the backend also limits us in that we waive the benefits of using the same language on the server and client in advance:
- one language, one medium, some terms
- the same modules (browserify)
- code repeatability
A framework can use all of this only if it has a Node.js backend.

Node.js

The main myth about Node.js is that it is not stable and requests are sometimes lost. With the advent of cluster and domain, this is no longer relevant.

Another myth is Node.js slow. Here one could say that v8 is only 3-5 times slower than C or that Node.js spends only about 8 kb of memory to maintain the connection. But perhaps a million simultaneous connections on one server will be sufficient argument.

The third myth is the imminent callback hell. The asynchronous nature of Node.js is its ideology and gives it a unique advantage: the new request does not have to wait until all requests are processed before it. Writing code in an asynchronous environment is not exactly the same as in synchronous, it requires a habit. In the capable hands of Node.js, the code is beautiful and transparent.

The fourth myth is that JavaScript is not a very good language. Douglas Crockford allowed himself to disagree with this statement.

Full stack

The main myth about Full-Stack frameworks is that they are a monolithic construction and deprive us of the flexibility to choose specific components. There is a contradiction between flexibility and usability. And the right decision would be to seek a middle ground. For example, Derby consists of components: express.js , racer , share.js , live-db , tracks , etc. Each of them performs its own function, some can be replaced.

The second myth is that Full-Stack frameworks are very complex and only suitable for large projects. Derby can be used for static sites without a database as well as for multiplayer games and large interactive applications.

The third myth is that code reuse between a server and a client or synchronization of data between clients can cause some security problems. It is always possible to execute the entire secret code only on the server, so that the client does not know anything about it. Data synchronization mechanisms provide a way to restrict data access.

The fourth myth is that Full-Stack frameworks are still damp, not stable, they experience performance problems when synchronizing data. At the moment there are several projects in production that are under load. There are no problems.

Full-Stack frameworks combine all the best MVC on the server and MVC on the client, multiplying this by the advantages of using the same language, which, coupled with unique features such as built-in data synchronization, gives the web developer a powerful tool for implementing his ideas , previously available only to monsters like Google and Twitter, and brings the future of the web closer today.

Derby materials