Javascript State of the Union 2015, part 1

This article is a part of a 3 piece series about the Javascript State of the Union talk, presented in September 2015. Check out the slides here.

Part 2 | Part 3.

In the beginning of this year, I started studying the possibility of delivering a talk at a Front-End conference called Front-End Carioca, since I knew the organizers. At that point I didn’t have a subject in mind, but in mid-March it finally surfaced.

After a series of talks and workshops I delivered at Huge, where I work, a layer called Javascript Architecture was the start of what I came to present in September. Javascript Architecture brought up different reasons and scenarios that demanded code organization and ways to achieve it, such as modules (e.g.: AMD, CommonJS, ES6), design patterns, (e.g.: MVC, MVVM), frameworks (Angular, React, Ember), among many others.

As time went by, the idea of presenting an overview of Javascript in applications became a lot broader, specially due to my experience at Huge leading and hiring developers. I realized that, unlike on Back-End, it’s a lot harder for developers to have a sound notion of Front-End (what it is, where it came from, what it consists of, where it’s heading). That eventually brings up problems to professionals that want to pursue a career. I had an urge to present a deeper study concerning Front-End and Javascript.

State of the Union

The State of the Union is the address presented by the President of the United States to a joint session of the United States Congress, typically delivered annually. The address not only reports on the condition of the nation, but also allows the President to outline his or her legislative agenda and national priorities. — Wikipedia

The name State of the Union has been used in several talks and bulletins (e.g.: Design State of the Union) with the purpose of briefing about where we are and where we’re heading. Although it’s a bit controversial, I thought it was interesting to use the title Javascript State of the Union 2015.

I have to admit that it was quite an ambitious research, and I needed the help of a few members of Huge Rio’s development team. We ended up building an extensive timeline, that had to be reduced to fit into 45 minutes of speech.


Some JS frameworks and libraries, 2015.

To start analyzing, we have to take a quick look to what we have today. To sum up, we have tons of tools and frameworks. If we look closely, we’ll see that most of them only emerged in the last 5 years. It’s a lot to such a short period of time. There are so many tools coming to light that this slide is probably outdated.

From there we can think of three premises or questions: why are there so many changes; what has changed; what doesn’t change. In other words, what influences front-end? Are these changes only related to the form or the essence of our field? What if something hasn’t changed in this process?


To answer these questions, we ended up building an eight threaded timeline. All the programming languages were separated into imperatives or functionals; the outside part of the software was split into computers, processors and companies; front-end in browsers, html/css/js and javascript frameworks. All of this is highly connected.

The idea is that we can directly see the front-end’s emergence process and what it is based on (that is, its pillars). Thus we can understand what’s happening now and what’s important that we learn so we can move forward.

Our story begins in 1950. That’s when the first commercial computer was released, which boosted computer science’s development and advancement. Then, Fortran, the first high-level programming language, was annunciated, strictly followed by Lisp. Notice that these are in different lines; one is imperative and the other one is functional.

Imperative and functional are merely two of a whole lot of different programming paradigms. We, web developers in general, are used to the former, but this is just another way to write code. There are key changes from one paradigm to another. It’s interesting to know about their existence, specially because each has their own benefits and can be used in different situations. You must be thinking that functional programming is coming back at full steam, and you’re absolutely right.

The decade of 1970 was characterized by the release of the first programmable microprocessor, which was obviously an important milestone. Smalltalk, one of the biggest MVC diffusers, came up right after that, followed by C, the father of most languages we know. The notion of concurrency (the ability to execute several tasks at the same time) left room for huge improvements towards processors, and the first version of HTML, focused at texts and hyperlinks with no JS or CSS, came into view shortly after that.

When talking about MVC, it’s important to discuss Software Architecture. Those are design patterns that permeate the whole application. MVC is directly related to graphic interfaces and data exchange between the view and the data persistence layer. Decentralized and highly scalable systems can benefit from the microservices architecture, while a highly interactive application can resort to publish-subscribe. The point is to notice the complexity of such patterns at the time, over 30 years ago.

In 1990, the speed of technology development slightly increases (microprocessors + concurrency + OOP + C). Not only did the concurrency of processes already existed, but also the commercial dispute between Intel and Athlon, accelerating the advancement of processors.

In a short period of time, World Wide Web, followed by Netscape, HTML 2 and CSS came along. On the back-end timeline, today’s most well known languages emerged: Python, Ruby, PHP and Java.

After Microsoft publicly announced that they would suppress Netscape, the latter answered back with the creation of Javascript in only 10 days, by Brendan Eich. Sure enough, shortly after that, MS released Internet Explorer and the war between these two browsers, each with its particular Engine, began.

Note that Java brought along the notion of Binding. In its root was the intention of being a mother language, whose programs would be able to be executed in any platform. These softwares had graphic interfaces, the vast majority using MVC as its architecture pattern. The Binding technique was required to facilitate the synchronicity between view and model.

At last, 2000s. The biggest milestone on Front-End at that time was the creation of AJAX, which was originally implemented by Microsoft, followed by Mozilla’s alternative, subsequently adopted by all browsers.

Processors finally got to Pentium 4, providing enough input to technology based businesses, such as Google, Hotmail and Wikipedia.

Front-end, at that time, was simply declarative. It wasn’t really explored and there wasn’t a need for logical programming on the view layer. Many back-end frameworks used to generate HTML code (messy, obviously) and most of the layouts were made using tables.

It wasn’t really necessary to have a specific professional to write code or “program” in HTML. This need came along a little later, when internet users got more demanding and web products needed more and more customization and interactivity.

Even though AJAX already existed, its usage was still very mysterious due to different implementations and verbose methods. Most of Front-End consisted in declaring markup.

What can we conclude so far? Our area’s foundation started a long time ago. Concepts considered new by many people actually come from a lot of years of problems and challenges. Front-End is a recent area, in plain development and definition, but in no way isolated. On the following articles we’ll figure out how technologic evolution, hardware, Back-End languages’ progress and even commercial aspects directly influence our area.

This article is a part of a 3 piece series about the Javascript State of the Union talk, presented in September 2015. Check out the slides here.

Next: End of 2000s, first JS library, Node, AJAX and Single Page Applications.

Part 2 | Part 3.