Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://www.imaginarycloud.com/blog/a-javascript-ecosystem-overview below:

JavaScript Ecosystem Overview

While JavaScript started its journey addressing the necessity of making webpages more interactive and dynamic, it has come a long way and over multiple iterations it managed to also consolidate a role as a back-end language.
After conquering the back-end, the mobile world was an open field.

‍

It was with the advent of AJAX in 1999 (standardised in 2006) that JavaScript gained a second wind. Before AJAX, JavaScript was mostly used to animate and provide interactivity to some webpages. Though, as this interactivity would not involve interchanging data with the server - it would only consist on accessory display-logic.

‍

With AJAX, JavaScript started to perform key tasks in our web-applications application-logic, to the point that nowadays it’s hard to find web-applications that do not require a browser with JavaScript enabled in order to work. It was after this change that the JavaScript ecosystem started to expand as a client-side programming language.

‍

The main needs of the developers working with AJAX web applications are:
• Performing AJAX calls;
• Manipulating the Document Object Model (DOM) - the data structure kept by the browser representing the webpage's structure;
• React to the user's interactions.

‍

The core JavaScript functions providing these features were not very practical and sometimes their behavior was not compatible with different browsers.

‍

The first libraries to become popular addressed precisely these three tasks, providing a collection of functions and objects that made these operations easy and functional on every browser. Some of these libraries would also provide plenty of other general-purpose functions:

‍

A JavaScript framework that was released in 2005 as part of the Ruby on Rails AJAX support. It directly extended many JavaScript core objects with behavior that would be somewhat similar to the Ruby programming language, also adding a class-based system to the language.

‍

These core extensions were regarded as troublesome by other programming communities and the provided functions was weirder than the following competing library:

‍

The jQuery framework was released in 2006 and - unlike Prototype - has let the language core as it were and rather focused on providing plenty functionalities related with the DOM, events, asynchronicity and effects.

‍

One feature to highlight is that jQuery supports a plugin system that allows library programmers to extend its functionality. This library was the most successful library of this kind, becoming the indispensable tool for front-end development, being used nowadays in the majority of the websites.

‍

Despite jQuery’s immense popularity, as well as its ability to provide many useful functionalities, it’s important to notice that modern versions of JavaScript already provide many of the functionalities that made jQuery popular. Maybe you might not need jQuery at all.

‍

It’s increasingly popular not to use jQuery and to rather rely on either only the current core JavaScript functions or on libraries that are specialized in each specific task (e.g. fetch for AJAX calls).

‍

While using DOM-Manipulation libraries, it’s common to keep the application data in the DOM itself, thus there are DOM-Manipulation selector functions that have to be called when needing to access or modify this data.

‍

This kind of code is often filled with selector-names and easily becomes a mess as the application's complexity evolves. There is a set of frameworks that allow us to address this problem in an elegant way by leveraging on application patterns that are similar to the famous Model-View-Controller (MVC) pattern.

‍

On the other hand, there is a recent trend in which web-applications are fully loaded in the browser on the first page-load, performing every subsequent operations via AJAX.

‍

This kind of applications is called Single-Page Application (SPA) and, as their code is often quite elaborate and complex, it’s recommendable to pick one of these frameworks when implementing a SPA. Let’s look into some of them.

‍

Backbone is an Model-View-Presenter (MVP) framework published in late 2010. it’s focused on SPAs and enforces the separation between application-logic, display-logic and templates.

‍

The communication between these entities is managed in an event-based fashion and it also supports a Router class that allows the applications to react to URLs and to update these according to the triggered events.

‍

Angular is a framework implemented by Google that used to follow a MVC architecture and that has evolved into an MVVC framework. Similar to Backbone, it’s focused on SPAs and enforces the separation between application-logic, display-logic and templates.

‍

It’s interesting to notice that Angular allows the programmer to extend HTML by creating new tags that can be used in the templates and that encapsulate parts of the page.

‍

Other distinctive feature is that it allows the establishment of two-way data-bindings in-between the templates and the JavaScript objects that are to be rendered by them.

‍

In this way, any update to these objects will automatically trigger HTML updates, and - in a similar way - the JavaScript objects will be updated when their corresponding template input fields are changed.

‍

As we have described on the previous sections, the display layer of our web applications moved from a simple computational model where the interface to display was only function of some data calculated by the server-side code into something much more dynamic and complex, where it would depend not only on the retrieved data but also on the user interactions and scripts that were processing these.

‍

This complexity often translates itself into complex code that’s hard to share and to reason about. Thus, some people at Facebook started experimenting with a simpler computational model to code the front-end. A computational model that would allow us to think of what is displayed in the page again as result of the state of some few variables instead of the result of the interaction between a "zillion" of Model-View-Controller classes.

‍

In order to make such change take place, something radical had to happen: if we wanted the display to only be the result of applying a function to some state variables we would have to stop manipulating parts of the DOM directly and instead render each version of the display as a whole.

‍

As rendering the whole DOM whenever changing something in it would be too slow, it was decided to map the DOM onto a lightweight representation of it that would be easy to regenerate and compare.

‍

Thus, whenever changing one variable, we are able to generate a new version of this lightweight representation and compare it with its previous version, thus calculating which parts of the DOM need to be updated. We call Virtual DOM to this lightweight representation of the DOM.

‍

React was the first framework to use a Virtual DOM. It was created by Facebook and the architecture that needs to be followed by the applications using it it’s minimal.

‍

Regarding MVC, React does not stick to it and is rather only about the View part of the code. With it, the View is represented as a tree of entities called components that might be composed of other components themselves.

‍

A component holds some state, can receive properties upon creation, and knows how to render itself for a given set of properties and state variables. Whenever its state is changed, a new version of its display's Virtual DOM is rendered and compared with its previous version, and the needed DOM is updated accordingly.

‍

If some interactions performed on a given component are to change the state of parent components, then the parent component has to pass the handling code to the subcomponent in the form of a callback. This approach guarantees that components are loosely coupled between themselves, thus making them quite easy to be reused.

‍

One rather controversial choice taken by the creators of this framework is, instead of using HTML templates like the other frameworks, an HTML-like representation of the code is written as XHTML mixed within the JavaScript code, therefore requiring the use of a compiler that knows how to transform this JS and XHTML mix (called JSX) into HTML-generating JavaScript.

‍

The component-based approach of React is effective for smaller applications, though for structuring bigger applications Facebook proposes an architecture called Flux, in which the state of the application is stored away of the components in something called state containers.

‍

The original implementation of the Flux architecture was rather complex but there is a simpler one called Redux that is the most popular one and has even been used to implement application's back-ends.

‍

Its architecture is functional and instead of directly mutating state, the programmer is meant to create new versions of it by applying reducer functions, thus allowing easy Undo/Redo and time-traveling debugging.

‍

Vue started as a MVC framework similar to Angular but focusing on being simpler and requiring less boilerplate. The last version already features a component-based approach and a virtual-DOM in a similar way that React does.

‍

The documentation describes it as a progressive framework, in the sense that it is thought to be progressively adopted and thus allowing a user to start by only using the view-part of the framework and later add more complexity if needed. There is a focus in reducing boilerplate and the number of files used when possible.

‍

When developing complex Web applications people noticed that when fetching data through AJAX calls there was often under-fetching and over-fetching as well as that it was not easy to manage caching.

‍

In order to sort out this problem Facebook developed a query language that allows describing the data each part of the interface needs. These queries are meant to be interpreted and aggregated into efficient sets of AJAX requests by a graphQL client.

‍

There are at least two GraphQL clients available:
• Relay, the former implementation by Facebook, highly tangled together with React;
• Apollo, which strives to be a framework-agnostic project.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4