This is the 4rd and a last post of the series, Part 1, Part 2, Part 3.

The initial release of AngularJS happened just one week after the release of Backbone.JS, but was pretty much ignored for a while. It took some time to understand that in addition to Javascript, HTML and CSS, frontend developers that wanted to succeed with Angular had to learn ng-extensions too. Within a few years, Angular became very popular among developers. The only problem was that it was very easy to get started with it, but pretty complicated for more advanced things.

Exactly one year later, ex-Rails core engineer Yehuda Katz released Ember. The first version was super opinionated and had a high entry barrier. Instead of trying to solve some small tactical issues, Ember directly targeted full-featured client-side web applications.

Two years after that, Facebook released the first version of React - a breath of fresh air for frontend development. No monolithic applications, no misplaced MV (whatever) patterns, no extensions. Yes to Daft Punk’s Random Access Memories, album released that same year. The concept of React was very simple: representation is a function of an application state. Just implement the render function as a function of a state, include optional lifecycle callbacks, and React will take care of the rest.

Later, Facebook introduced Flux, frontend application architecture with unidirectional data flow. Dan Abramov’s react-redux based on Redux is probably the best implementation of the same concept of unidirectional data flow. It took about a year and a half for the community to catch up and by the end of 2014, React became extremely popular.

And at the beginning of 2015, Facebook released React Native, a framework for building native apps with React that introduced the concept of “learn once write many”. iOS and Android applications will not share 100% of the code, but it is possible to reach 60-90% depending on the requirements. Compared with 0% code sharing when developing ObjectiveC/Swift for iOS and Java for Android, this is quite an achievement. Especially when taking into account that development is mostly done using React and Javascript.

Angular 2 entered the beta stage in late 2015 and was released in September 2016. Its breaking changes and a few concept shifts deprecated most of the knowledge and experience that developers had accumulated while working with Angular. Some developers were angry about these changes because they had to re-invest time to basically writing everything again from scratch using Angular 2. But some were happy because the new version was better engineered and more fun to work with.

Initially released in 2014, Vue gained popularity around the same time that Angular 2 was released. It was what Angular JS should have been from the beginning.

At the end of 2015 and most of 2016 there was a popular joke: two new Javascript frameworks were probably released while you were reading this sentence. And another three have just died.

Q&A

So, what should I use now?

React. Unless you have someone on board who is familiar with Angular, then use Angular or Vue and consider React anyway.

What should I learn if I am just entering this field?

React. It will allow you to develop desktop/mobile web apps, native mobile apps, and even Windows applications using react-native-windows.

What’s next?

Progressive Web Apps are the next stage in web frontends. It deserves its own series of posts.

This is the 3rd post of the series, Part 1, Part 2, Part 4.

Ok, so now initially loaded web pages have almost no HTML code, but have tons of Javascript and CSS instead. This is good, because these assets could be served from CDN which in theory makes the whole page load much faster.

But the page load time is not the optimization objective. What really matters is the time that it takes for the page to become usable, in other words - when users can start consuming the content on the page.

So besides the time that it takes to load all of the assets, we also have to consider the time spent inside the Javascript to fetch relevant data using APIs and to render it on the client side by updating the DOM. It’s user CPU time that renders the content in this case. User CPU seems free from an application vendor perspective since the user pays for it and for the electricity to power it. But that’s not 100% true.

The first iPhone was launched about 2 years after the original AJAX piece was published. And that triggered a new epoch of mobile browsers. But mobile browser CPU time is not free. It doesn’t cost money directly. The price is the user’s disappointment with battery life. Now users don’t blame lazy developers who wrote suboptimal code, they blame mobile device vendors for using bad batteries.

Anyway, Prototype JS was released in the same month as the AJAX article and attracted a lot of attention. It allowed direct DOM manipulation, contained cross-browser abstractions, and was bundled with its own Javascript effects library. Prototype JS was probably the most important advancement in frontend development since the invention of CSS in 1996. In any case, the first version of jQuery was released 18 months later. It becomes a de-facto standard for the next 9 years because it was direct DOM manipulation done right.

A crazy mix of server-rendered HTML pages and lots of jQuery based mostly on spaghetti code to update these pages, plus a few JSON/XML APIs here and there, was characteristic of Web 2.0 development for many years. By that time, the prestige of frontend development had significantly declined. Backend engineers looked down on HTML/CSS/JS folks that spent most of their time showing and hiding divs and changing the colors of different elements.

Barack Obama inaugurated as the 44th President of the United States of America just 4 months before the first release of Node.js. Node.js was accepted quite sceptically as a nice try to bring Javascript to server side, and there was no significant adoption of Node.js in web development. Probably a release of Express a year later became a trigger of a wide adoption of Node.js. Today Node.js is a quite popular choice for backend development, especially taking into account that modern frontend frameworks allow the same Javascript code to perform rendering on both sides: server and client.

The state of frontend development was now where backend development had been in the late 1990s - a zoo of approaches and technologies. Different groups tried to come up with a frontend framework that would straighten out the mess. Jeremy Ashkenas came up with the most successful one at the time, Backbone.JS. Released in 2010, this client-side MVC framework restored some order to jQuery-based frontend apps. A few years later, Marionette came along to attempt to enhance the functionality of BackboneJS and to become a Rails-style opinionated frontend framework.

Then more and more engineers began to develop frontend-based apps. And the fun was about to begin.

This is the 2nd post of the series, Part 1, Part 3, Part 4.

So the main question is - what does the backend code do in order to render its output? Static assets aside, the response will most probably include data that was fetched from some sort of database. If the output is a full HTML page, it should also include proper HTML markup around the data. This is called server-side rendering because the content of the whole HTML page is rendered by the server.

The bigger the HTML page the more expensive rendering will be.

In earlier web applications, each request type was handled by a separate script file. The script was interpreted line by line to render a web page. Several approaches were introduced to make the code more maintainable and MVC was one of the most successful ones. It’s worth mentioning that Rails, a Ruby-based MVC implementation that was initially released the same year that Zuckerberg launched Facebook, contributed significantly to the wide adoption of the MVC design pattern in web development. Model-View-Controller frameworks for many languages were released in the late 2000s.

MVC separates the concerns of the backend code. Requests are handled by a controller, it uses models to fetch data. The data is passed to views which are responsible for rendering pages. It’s a much better solution than a single script file that does all of the above. But tons of CPU and memory are still used to prepare HTML pages that became bigger and bigger.

And then along came Asynchronous JavaScript + XML, aka AJAX, almost nine years after the FastCGI specification was published and in the same year that the 3rd episode of Star Wars was released. The AJAX approach suggests fetching extra data from the server to update the current screen without reloading the entire page.

Web servers can render many types of content in response to an XMLHttpRequest - including HTML segments that can replace an existing part of the web page, Javascript code that can do anything (including UI effects and replacing parts of the HTML page) once it is evaluated by the browser, and pure data that is serialized in XML/JSON format.

Javascript code running in a browser uses XML/JSON data to update the content of a page. Beforehand, Javascript was used mostly for UI effects. This marked the beginning of a significant shift in the concept of web development. It was the beginning of client-side rendering. This shift actually affects backends as well, that no longer have to render expensive HTML pages. Instead, their main function is serving APIs. It almost makes the V-portion of the MVC framework redundant, because JSON format doesn’t include anything but the data itself. Now server CPUs and memory can be used for better purposes.

Two months after the end of WWII in Europe, Vannevar Bush published an essay called As We May Think. He introduced a concept called memex, which became the forerunner and inspiration for hypertext.

Forty-six years later, Tim Berners-Lee released the very first web server, called CERN httpd, and a browser that worked on NeXT. Later that same year, Nicola Pellow developed a text mode browser for other platforms. At the same time, on the other side of the planet, Pablo Escobar surrendered himself to the police. CERN httpd’s latest version 3.0 is available on GitHub.

Two years later, NCSA published a specification for calling command line executables. The output of these executables could be rendered back via the web server over an HTTP protocol as a response. This was basically the birth of the dynamic web and ultimately resulted in a formal CGI standard.

Three years of extensive use of this solution showed that launching a separate process for each request and tearing it down at the end of the request was a waste of resources. Let’s ignore the forgotten Netscape server API for a minute and note that Fast CGI was the greatest achievement since CERN httpd. Requests from the web server could be routed to a FastCGI server (via a socket, TCP or named pipe). The FastCGI server keeps data-rendering processes running for a series of requests, so that responses are returned to the web server and then to the client. This approach significantly reduced server load and response time.

Another popular approach that was actively developed during that time is called embedded interpreters. Some well-known examples are Apache’s mod_perl (released in 1996) and mod_php. They basically keep the interpreter running constantly in order to save launch/tear down overhead and to transfer the script code to the interpreter process, which in return renders back the response body. Interpreters usually have access to the web server’s internal APIs and act as extensions of the web server.

CGI, FastCGI and embedded interpreters are still widely used today (Apr 2018).

But all this has nothing to do with frontends. I just mentioned it to give you an overview of how backends render their outputs to a browser. Of course I skipped some basic things like sessions, caching, reverse proxies, database connections because they are less relevant to the big picture.

The big picture is quite simple. A request is received by a web server, which somehow gets the output of the backend application code and renders it back to a client application. In most cases that client application is a browser. As for static HTML / CSS / Javascript assets, the backend application code just reads content from a file (database, Redis, Memcache, tape, punch card or whatever storage is used) and sends the content back.

This is the 1st post of the series, Part 2, Part 3, Part 4.