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.
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?
# Why do we Build Apps Differently Now?
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.
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
Here’s a quick overview of the most important frameworks and libraries and when they became publicly available.
|Name||Year of Publication|
|Angular.js (Angular 1)||2010|
|Angular (Angular 2+)||2016|
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.
# Angular.js (Angular 1)
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.
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.
# Angular (Angular 2+)
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.
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.
# Vue.js (2)
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?
Does that sound too good? Well, of course it has weaknesses, too.
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.
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)?
<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.