The World of JavaScript

How did we develop the frontend for our web applications like 5 to 10 years ago? We didn't have that many frameworks. We barely had any and they looked different. Frontend development mostly meant adding some JavaScript to open the occasional modal or display a carousel.

That of course meant that the JavaScript code itself was relatively simple and that we didn't write that much code. Don't get me wrong: There were more complex applications and it's not like JavaScript was brand-new. But we didn't control the vast majority, leave alone all, the frontend with it.

Most applications were server-rendered, which means that we had some server-side language like PHP return HTML for every request the user sent. This actually is the pattern used by most web pages as of today, too. There's nothing wrong with this approach but 5 to 10 years ago, not much was happening on the frontend thereafter. The page was loaded and we were done.

Since, on average, not that much JavaScript was written for the application frontends (i.e. the page the user views), not only were the frameworks/ libraries simpler but we also didn't need that many tools for our build workflow and process. Why would you want to split your code over multiple files if you don't write that much? Why would you want to use some next-gen features if you're not using all features of the current generation? Why would you want to unlock all kind of other features in your code if the existing libraries do the job?

Therefore, your typical frontend HTML code looked like this

<script src="js/libraries/jquery.js"></script>
<script src="js/app.js"></script>
...

Of course you probably had more than one script import but in general it was not that complex, huh?

With the advent of mobile phones and apps, we quickly realized that users (and therefore us, too) prefer reactive content. This means that we don't want to send a request and wait for a response on every click we make. Things should happen instantly and we don't want to spend time in front of empty pages.

What allows us to create reactive user experiences and change the page after it has been loaded? JavaScript of course! That's one of the major reasons why more and more JavaScript is used on web pages and why libraries like jQuery became very popular.

jQuery solved a big problem. Selecting DOM elements, traversing the DOM and sending asynchronous Http requests (AJAX) manually, was very cumbersome and error-prone. jQuery made all of that way easier and also made sure that we could use a standardized set of commands which would work across all browsers. But jQuery wasn't the final solution. Whilst improving the way we work with JavaScript a lot, it still left some issues unsolved. Or maybe we started realizing these issues now after other things became easier.

Some of the reasons were

• We still had to select all elements we wanted to work with manually

• We had to control where we add or remove elements and CSS classes

• We had to keep track of the state of the DOM

Welcome to the JavaScript world as it is now! Frameworks like Angular, React.js or Vue.js became popular because they solve a fundamental issue jQuery left unsolved: Keeping track of the state of our page/ the DOM and interacting with it without having to control everything on our own.

Here's a quick overview of the most important frameworks and libraries and when they became publicly available.

Of course, there are way more JavaScript libraries available but these are the most popular ones, already powering thousands of web applications like Facebook, Twitter, Google Adwords and more! Let's briefly dive into all mentioned frameworks and libraries.

As written above, jQuery was the first of the mentioned frameworks (actually, it's better described as a library).

It made DOM selections and manipulations, animations and working with data much easier. Additionally, it added a lot of other utility tools like a very comfortable-to-use AJAX functionality.

jQuery still powers almost any web page you're visiting and it's therefore still extremely popular. It has its strengths but as mentioned above, it also has some (potential) weaknesses, depending on the size and kind of your web application. Whilst giving you a lot of tools which make it easier to work with the DOM you might still reach a point where keeping track of all your DOM manipulations and the current state of your app and DOM can become very hard.

You can kind of think of Angular.js (= Angular 1) as the "answer" to the issues jQuery left unsolved.

How could we control the state of the DOM? In bigger applications this could become a problem and Angular, a framework developed by Google, added a lot of functions, ideas and concepts to solve that.

It's most famous for its two-way databinding which basically means that it would automatically update and output that updated data either on user input or changes from some other source.

This framework therefore opened the gate to a whole new way of creating applications. Suddenly, JavaScript was everywhere and you could create very reactive applications. Since tracking the state of the DOM was less of an issue, you could become way more fancy with your apps.

It was not just that DOM-thing though, AngularJS added a lot of other great features and kind of introduced a new type of applications: Single-Page-Applications (SPAs) . The great advantage of SPAs of course is that the user doesn't need to wait for anything at all. Even route changes, in the past a guaranteed source of delay, now happened instantly. Of course SPAs still might require some server data or send some data to a server but that happens behind the scenes via AJAX. This allows developers to always 'keep the page active' and only display some spinner or loading bar when fetching some data in the background.

AngularJS was and is a great framework but of course it introduces a certain "way of creating the application". That's just what frameworks do. Not everyone's liking this exact way so of course there was (and probably still is) room for other "ways" or frameworks.

React.js is one of these frameworks, it was developed and is actively used by Facebook, and is the second-most popular (after AngularJS) as of now (mid-2017). If you're interested, I do have an article comparing these frameworks !

React.js is a very lean framework and it imposes less "rules" on you than AngularJS does. It therefore is often simply called a "library for creating UI components". And that's what it's really good at: It allows you to split your UI (view) into components which are then rendered and controlled by React.js.

With that, you can interweave your HTML code with JavaScript and build your whole app from your set of (re-usable) components or simply drop some of these components into your existing view. Kind of it's core "rule" is that it uses JavaScript only, no HTML code is mixed in or anything like that. Everything which should get rendered at some point is written in JavaScript. To be precise, it's typically written in JSX, an extension to JavaScript introduced by React.js which allows you write HTMLish code directly in JavaScript.

That's not everyone's taste but if you like it, React.js gives you a very lean, focused and efficient way of creating your JavaScript apps. Whilst being a "library for UI components", it's also used a lot for SPAs, too.

AngularJS still is the most popular framework and yet the Angular team at Google decided to completely re-write it and released that rewritten version of in late 2016. Why?

AngularJS (= Angular 1 to avoid confusion) adds a lot of great concepts and ideas but it also has some flaws. Performance in bigger apps is an issue and the often-praised two-way-binding can also become a curse and lead to these performance issues. Since these issues have its roots in the core concept of the framework, there basically was no way around re-writing it.

Angular 2, or just "Angular" as we should now call it (Angular 1 = AngularJS), is the future of Angular and receives frequent updates. These updates are NOT complete re-writes but still bump up the version numbers as new (and possibly breaking) features are added to keep the framework evolving and up-to-date. The current release schedule can be found here.

Angular (remember, that's Angular 2 etc.) doesn't use vanilla JavaScript, instead it uses TypeScript, a superset to JavaScript . That can make getting started with the framework a little bit more challenging since you not only have to become used to TypeScript but also can't drop Angular into any existing HTML page anymore.

Instead, you'll need a more complex project setup - thankfully we have the Angular CLI to take care about this. The whole framework also shifted its focus. It's simply not meant to be dropped into existing pages and add some reactivity to them.

That's not what it's good at. Instead Angular is heavily focused on creating (potentially very big) SPAs. If that's what you're planning to do, and more and more people are doing so nowadays, Angular is a great choice with a lot of great ideas and concepts that make the creation of big applications easier, more predictable and flexible. With baked-in features like Dependency Injection, Routing, Animations and more, it allows you to use the complete toolbox to create amazing user experiences driven by JavaScript .

With AngularJS being very popular, React.js powering a lot of apps and the re-write of AngularJS (=> Angular 2 etc.), do we really need more frameworks?

That of course depends on you, if you already love some of the above frameworks, you might not need another one. But all the mentioned frameworks have some concepts or issues you may not like. AngularJS can run into performance issues, React.js uses JavaScript for everything, the syntax may be confusing at times and especially styling can become a nightmare due to the way you write your "HTML" (JSX) code. And Angular (Angular 2, 4, ...) is the all-in-one package which may be overkill for your app. Or you're planning to build a big app but don't like TypeScript and the complexity Angular introduces. These would be cases where you might consider looking for an alternative.

Vue.js (2 - released in late 2016) is such an alternative and I like to describe it as the result of Angular and React.js having sex. It uses vanilla JavaScript, it can be used for small, medium and big applications, you may use it to drop it into existing HTML pages or build SPAs with it and it offers some very clever concepts which make creating frontend apps fun.

Does that sound too good? Well, of course it has weaknesses, too.

Or you might not find it as much fun as I do but it kind of picks up some ideas from React.js (use vanilla JS, "control parts" of an HTML page to render Vue.js components in) as well as some ideas from Angular (use directives to place instructions directly in the HTML code, have some separation of HTML, CSS and JavaScript). Another important difference to Angular and React.js is that Vue.js is basically a one-man show. No Google or Facebook is backing it, instead it's mainly created by Evan You (an ex-Google employee) and an active contributors base on Github.

Vue.js does not only mix features of Angular and React.js, even though that would probably already lead to a great framework. It also adds a nice and relatively intuitive way of managing application state, template (~DOM) bindings, computed properties for greater performance, mixins and more. Overall, a lot of nice ideas which make both the creation and usage of apps a great experience. To find out why it might still not be the #1 pick, we have to do a detailed comparison of the three frameworks.

The "World of JavaScript" has more components than just some frameworks and libraries though. Or to be precise: It needs more components (most of them) due to the existence of these frameworks and libraries.

We had a brief look at the libraries and frameworks, but what's the role of Webpack, Babel, ES6 and TypeScript (and similar packages or languages)?

The frameworks we work with today - Angular (1 or 2/4), React.js, Vue.js etc - come in different flavors and "languages". Yes, they all use JavaScript but not all use ES5, the version supported by the majority of browsers. Instead, Angular 2 (now 4) uses TypeScript, a superset to JavaScript which adds features like strong typing, interfaces or generics. React.js works best when using ES6.

Besides the different languages we may (need to) use for different frameworks, the way we write our JavaScript code also changed. Since we do way more in JavaScript than we did 7 years ago, our codebase grew quite a lot. Therefore, you typically don't just have two or three JavaScript files - we have a lot of them! We want to split our code over multiple files to keep it maintainable. And we want to get as much debugging support and features during development whilst shipping lean and optimized code once we are about to deploy the app.

These requirements and this way of developing JavaScript apps mean that the "old way" of just importing some scripts via <script src="js/my-script.js"></script> doesn't work anymore. Managing all our files, ensuring the correct import order and updating our app doesn't work with this approach once our app exceeds a certain size.

This need for a managed development workflow which would allow us to use nice features, have an easier life as a developer, maintain and optimize our app led to advent of various build tools and packages. Such tools would allow us to define steps in our build process. For example, we could define a step which would compile ES6 JavaScript code to ES5 code to ensure that it runs in all browsers. Thereafter, we might want to bundle all compiled (ES5) code into one file so that we only ship one file to the server and therefore user in the end (one bundle = fewer Http requests required). And we might also define a final step which minifies the bundled code so that it becomes as small as possible.

Grunt and Gulp would be examples for such build tools. A lot of libraries and packages for these build tools were created by a vibrant JavaScript community. npm, Node.js' package manager, became the de-facto management tool for frontend/ JavaScript projects (although it now faces competition by Facebook's yarn package manager). With it, we could and can define which packages (including the build tool and all its libraries) our project might use. This allows us to easily replicate the project since all dependencies are stored in a central file (package.json). With npm and build tools like Grunt of Gulp, creating, managing and maintaining frontend/ JavaScript projects certainly became easier. Or at least, we could utilize the powerful tools the JavaScript frameworks gave us.

Nowadays, the popularity shifted and Webpack is the cool kid on the block. It really is an awesome tool and whilst it follows a different philosophy then Grunt or Gulp do, it in the end also is used to control our build workflow, bundle our code, transform it if needed and optimize it before we ship it. But whichever tool might be popular right now or in two years, one new problem arose: The JavaScript/ Frontend developer world became very complex. Learning vanilla (ES5) JavaScript is not enough anymore. Instead, you have to understand what ES6 and supersets like TypeScript are. You got plenty of frameworks let alone libraries to choose from. And understanding all build tools like Webpack and their plugins can become a real pain.

Hopefully, the JavaScript world is a bit less painful after reading this article.