Get best of the week

Modern Front End Architectures (Part 2)

image

The second part of the article " Contemporary Front-end Architectures ", which discusses the architecture of the front end in terms of the distribution of data streams. Start here

Implementation


Algorithms generated by DOM (DOM-infused algorithms)


The technique, introduced and mastered by the jQuery library , really was the beginning of writing large-scale client applications, although in fact jQuery did not solve architectural problems. It was designed to make it easier to manipulate the DOM tree when there were too many inconsistencies in browser behavior. This provided a browser independent API.

I do not think this was intentional, but jQuery has simplified the DOM API to such an extent that it was difficult to distinguish it from the usual programming language APIs. This, in turn, allowed developers to literally mix the DOM API level ( View ) with the business logic ( Model ).

Once again, we are still in the context of the same server-side MVC. This is just a sequel. There is no real inversion of control. General control over views / pages is still determined by server-side code.





In the code snippet above, the Model, Presentation, and Presenter / Controller are in some way combined into one monolithic code structure. This is the case when the Model consists of only one property. Imagine trying to create a web application without a server browse cycle (like SPA). It would be impossible to handle all of this in any convenient way. The code for interacting with the DOM is penetrated by the rest of the application logic, and therefore it is known as the DOM-infused algorithm (I'm not sure that there is such a term officially)

Backbone.js - MV *


As we have seen, in jQuery, when developing applications, the way to structure and organize our code is clearly absent. This is where Backbone.js appeared as the next evolutionary solution. It was one of the first libraries to bring the benefits of client-side MVC style.



If we look at the Backbone data flow diagram, we will clearly see the model and view, but there is no object equivalent to the controller. Templates are evolving, and client-side MVC is simply an evolution of previous MVC architectures. During this evolution, much of the JavaScript community agreed with the definition of the model and view, but there was no consensus on the controller. Given the client environment, the idea of ​​Controller is not very suitable. The controller is left open for interpretation.

As for Backbone, there is no controller in it. So what is this? Is it MVC, MVP or MVVM? Borrowing from the definition of server MVC, the controller has two responsibilities, namely: to respond to user actions in the form of incoming HTTP requests and control the model to create the view (HTML page). In the case of Backbone, these responsibilities are shared between View and Router . But the independent notion of Controller or Presenter is missing.
, Backbone — MVP, View Presenter, Template — View, Model Collection Model.

, Backbone - . , Backbone MVC, MVP. , .

This is how MV * or Model-View-Whatever ("whatever") is born. For a detailed discussion, it is strongly recommended that you check out Addi Osmani's blog.

Compared to previous jQuery, Backbone helped create more structured code.









Earlier in this article, I called Backbone the next evolutionary solution. The reason is that he simply extended the server side MVC to complement it. For example, if our server is RESTful and implies that the front-end code is just a means to represent the model on the server side, then Backbone is pre-configured to synchronize with the API:



And besides, there are many other small conventions built into Backbone that just feel like an extension. In conclusion, I say that Backbone might not have been the only solution at the time, but it was truly groundbreaking work in terms of code structure and organization. Like jQuery, it has been used by many products.

Knockout.js - data binding for the front end


Knockout.js is our latest example of using basic templates. It aims to implement MVVM - Model-View-ViewModel for JavaScript. And so it is. While Backbone dealt with the problem of organization and code structure, Knockout is an efficient implementation of the View layer using Declarative Data Bindings . The advantages of declarative bindings are the same as with any declarative programming constructs:

  1. Easy to read: declarative code helps programming
  2. Shortening the standard template: bindings allow us to automatically update the DOM every time the ViewModel changes, and also update the ViewModel every time the View changes through user input.
  3. Observable: Knockout provides a higher level of abstraction for events. This allows Knockout to automatically track dependencies between ViewModel properties. If necessary, we can subscribe to Observable properties.





While Knockout provides well-defined constructs for the View and ViewModel, it doesn't say anything about what the application model should be. This makes Knockout extremely focused and versatile, as it can be used as a library instead of a framework. From my own experience, I saw that it was used to create SPA mini-applications, where a web application consists of several pages, and each page is a small Knockout application. This answer to StackOverflow clearly defines the scope of MVVM in Knockout.
It is often assumed that with the model, Knockout is on the server side. ViewModel simply requests a server-side model using Ajax or its equivalent.

Knockout replaces jQuery and template solutions like Handlebars for DOM updates, but still uses jQuery for animations, Ajax, and other utilities. In combination with Backbone, it can serve as a full implementation of the MVVM template. Theoretically, this could happen, but before this could happen, these concepts were already developed in the tools of the next generation.
Here begins the revolutionary movement of Angular 1, Aurelia, Ember.js, etc.

Due to its close connection with the .NET world, Knockout has been widely used in the ASP.NET MVC application. Like Backbone, it was another evolutionary solution to a slightly different problem. And again, the assumption that client-side code is simply an extension to the server-side MVC pattern has not changed. The server side was still the dominant architecture.

Both Knockout and Backbone are JavaScript libraries. One way or another, Backbone was seen as a framework. Why? There is no definite answer, but it was probably in perspective. Backbone has always been handled with a higher level abstraction due to its emphasis on code structure. Moreover, Backbone was never intended to replace the ubiquitous jQuery (even in 2019, 70% of the top 10,000,000 websites use jQuery), while Knockout overlapped with the jQuery core, i.e., DOM manipulations, which naturally complicated Knockout. Thus, Knockout's adaptation was limited compared to Backbone. But it was still one of the first implementations of declarative data bindings for the front-end community, and it deserves special mention.

Angular 1 - give me control


What jQuery did with the DOM, Angular 1 did with the front-end ecosystem as a whole. This forever changed the idea of ​​creating large-scale client applications. He presented many concepts as a basis - a modular system, dependency injection, control inversion, easier data binding, etc.

It was then and remains now a difficult task to choose the right JavaScript libraries and create the perfect technology stack for the frontend. Angular 1 simply provided a simpler but more cohesive alternative. The same can be said about Ember.js and other similar systems, but the applicability of Angular 1 was on a different qualitative level than its alternatives of that time.
Angular 1 is a revolutionary solution in the sense that it clearly marked a departure from the idea of ​​a simple server-side MVC extension with client-side code scattered across pages. Angular 1 has made SPA a first-class, almost de facto solution for creating next-generation user experience.

Framework or library?


Previous solutions were more libraries than a framework. Angular 1 is without a doubt a well-defined structure. A necessary distinguishing factor between the platform and the library is IOC - Inversion of Control. Further, to qualify Angular 1 as a framework, we can note:

  1. Well-defined MVVMs: Angular 1 has clear Model, View, and ViewModel objects.
  2. (DI): Angular 1 DI, Model. Angular 1 (Service). , .
  3. (data binding) : , . , MVVM. . (Angular 1 ). . . MVC. , .
  4. Modular system: Angular 1 introduces a modular system specific to the framework. Modules are the basis for organizing code for almost every language. JavaScript did not have a modular system until 2015 (browsers did not support it until 2018). Angular is far ahead of its time in terms of organization.

At the same time, Angular 1 was also criticized for the complexity that it introduced. The most important criticism is that it was modeled on server-side designs. This is not typical for frontend developers. Some things were frankly bad:

  1. Namespace collision: Although DI was great, it was implemented using the Service Locator pattern that used the global namespace. This made the prefix of services almost mandatory.
  2. . , , , . React . -, .
  3. . , Angular 1, . , Angular 1 $scope, ViewModel, Controller, $scope. , VMFactory . , Angular 1 , .

There were many other minor issues. Angular 2, or just Angular, was a complete breakthrough to the extent that it looked like a whole new framework. I find nothing in common between them, except for the name and a few concepts.



Over the years, there have been small releases of Angular 1, in which many of the small complexities of its use have been fixed. The most significant of these was the addition of the Component Model , in which most of the front-end development trends converged.

Angular 1 lived long and continues to live among the front-end community. With all its pros and cons, it helped the community understand the importance of software architecture and provided the basis for writing scalable applications. Its disadvantages and shortcomings became the basis for solving problems for future architectures.

More articles:


All Articles