Mr. Eich was working for Netscape and had to create a programming language that would allow web developers to embed small programs into webpages, making them more interactive and dynamic. The final product had to be flexible, easy to learn, have a popular appeal, and be easily implementable. it’s said that Mr. Eich only had 10 workdays to produce the specification draft… and here are some existing programming languages that influenced the result:
- Scheme - the functions as first class values and the dynamic typing
- Perl - weak-typing.
- Self - simple-to-implement prototype-based object-system
- Java - mainstream syntax and naming conventions
The Evolution of the EcmaScript Standard
In order to add new features to the language and to become compatible with the work of other standardisation organisations, the standard has been changing from time to time. The deliverables for each version are known as "EcmaScript <Version Number>". Here goes a brief description of some of the most relevant changes.
The first version of the language standard.
This version was produced in 1998 when the language was also standardised by ISO/IEC. It updated the Ecma standard so that would match the document produced by ISO/IEC.
In 1999 there were several new features being added to the language. The most conspicuous were:
- Regular Expression Literals
- New control statements
- Exception handling
This version draft was abandoned in 2008 due to disagreements about its feature set. It was decided that the output was too radical to be introduced and there was an agreement to create an intermediate version before such drastic developments would take place.
The version that supports by most browsers nowadays (early 2016) was created in 2009. Its most noticeable features are:
- High-order iteration functions (map, reduce, filter, forEach)
- JSON support
- Getters and Setters
- Better reflection and object properties
Just like EcmaScript 2, this spec was produced to align the Ecma standard with the document that was produced by ISO/IEC for EcmaScript 5.
EcmaScript 6 (aka ES 6, EcmaScript 2015, Harmony)
This version added several big changes in 2015, namely:
- Block-scoped variable declarations (let)
- Arrow functions
- Template literal
- Spread operator
- De-structuring assignment
- Parameter default values
- Rest parameters
The browser support for this version is still incomplete though there is a transpiler that converts ES6 code into older ES versions.
EcmaScript 7 (aka EcmaScript 2016)
This version was not published yet though it’s already possible to transpile what’s currently specified in its draft to older versions. Some proposed features are:
- Async functions
- List comprehensions
- Observable objects
This version is expected to be published in June 2016.
DOM Manipulation Libraries
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 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 sports a plugin system that allows library programmers to extend its functionality. This library was the most successful library of this kind, being used nowadays in the majority of the websites.
The MooTools framework was released in 2007 and followed the same path as Prototype.js, in the sense that it focused on improving the language core by extending it with extra functionality. It was notable by the class-based system implementation and by being modular, though it did not ever become popular enough to compete with jQuery.
Obsolescence due to later developments
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 sports 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 MVVM framework. As 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.
Virtual-DOM based frameworks
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.
The Virtual DOM
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. it’s to this lightweight representation of the DOM that we call Virtual 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’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 have passed 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.
Flux and Redux
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 and more recent one called Redux that’s becoming very popular and starting to be used even to implement application 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-travelling debugging.
As the React approach was so revolutionary there are new Virtual DOM implementations appearing and other frameworks based upon them. Riot is one of these, which is differentiates itself from React by:
- Using HTML templates
- Allowing the creation of custom HTML tags
- Being more minimalist
- Having a Virtual DOM implementation that’s more selective about what it re-renders.
The Back-end Ecosystem
On the other hand, both Chrome and V8 were released as open-source software (with a BSD license), thus allowing anyone to build their work on top of them and to distribute them as part of any software without having to pay royalties to Google.
- Asynchronous Module Definition (AMD)
- CommonJS Modules
- ES6 Modules
In the ES5 world, Node.js implemented CommonJS modules while front-end programmers preferred AMD, thus creating chaos on this field. There was thus invented a way to require modules and declare them called Universal Module Definition (UMD), which is rather ugly but makes modules compatible with both module APIs.
Anyway, this mess is about to be wiped by the adoption of ES6 - that already sports a language-level constructs aimed at dealing with modules.
When using modules while developing web applications there is often the need to merge the different modules' files into a single file to be included by the web application. There are two libraries that allow developers to perform this task:
Browserify is the oldest web module bundler and allows developers to use the CommonJS module syntax when programming web-applications.
Opinionated Full Development Stacks
There were some attempts to bundle both the tooling and the technologies aimed at creating full-stack applications. We talk about two of these attempts.
The MEAN stack stands for a package with the following set of technologies:
It also comes with the "mean" command-line, that allows generating projects, files and performing other useful command-line tasks.
Meteor is a web framework that uses MongoDB as database. It uses a publish-subscribe protocol applied to resources, allowing clients to get updates when the data is updated on the server. It can be used with any client-side framework.
- A brief history of ECMAScript versions, Alex Rauschmayer
- ES7 Features, Hemanth.HM
- Ajax (programming), Wikipedia
- Single-page application, Wikipedia
- Exploring the MVC, MVP, and MVVM design patterns, Joydip Kanjilal
- Knockout (web framework), Wikipedia
- Backbone.js, Wikipedia
- AngularJS, Wikipedia
- React Documentation
- Redux Documentation
- Riot.js guide
- V8 Terms and Conditions, V8 Documentation
- Node.js, Wikipedia
- NPMjs Documentation
- ES6 Modules: The End of Civilization As We Know It?,Brian Feroux
- Browserify, Wikipedia
- Webpack page
- The Battle Of Build Scripts: Guld Vs Grunt, Daniel Pataki
- Meteor (web framework), Wikipedia
- WebAssembly, Wikipedia
- Emscripten, Wikipedia
- Clojurescript's github page
- Live React: Hot Reloading with Time Travel at react-europe 2015, Dan Abramov
- Elm (programming language), Wikipedia