Hello! My name is Dima Chudinov, tutor in the web department at TripleTen, and head of the Frontend Group at ABBYY.
Recently, my students raised a question. They asked: which is better, Angular or React? While trying to answer the question, I realized that I'd need to write an article in order to fully explain how React and Angular differ — and even then it's still not quite enough to give a full answer.
In this article, we'll focus on the history and creation of frameworks, as well as some of their features. Now, this article won't tell you which tool to work with — that's up to you. But you'll be prepared to understand any debates online, or your fellow web developers in the office break room (assuming you're not working remotely at this point). This article will be very useful for developers who have some familiarity with at least one framework, but it's also designed to give newbies a high-level overview of the frameworks and libraries that a web developer has access to in 2021.
Libraries and frameworks
Before we move on to the different frameworks, it's important to learn how libraries and frameworks actually differ.
Libraries
A library is a collection of functions and routines you can use in your code to perform a limited set of tasks, as defined by the library creator.
For example:
- jQuery is a set of functions that allows us to manipulate DOM elements and work with events, and it also can be used for client-server interaction.
- D3 is a library for creating data visualizations using SVG.
- React is a library for displaying data and manipulating a DOM tree.
Frameworks
A framework, true to the name, is more like like a ready-made scaffold for building an application. This scaffold is built using sets of different libraries.
Together, frameworks and libraries help build the functionality that a particular developer might need. A framework defines how you should build and structure your app's architecture and which approach you should choose while creating your application. Simply put, frameworks determine how you should write your code. For example:
- AngularJS is a open-source framework for creating single page applications (SPAs) that has tools for developing and testing. This framework allows you to implement the Model–View–Controller (MVC) design pattern and MVVM architecture.
- Vue.js is also a framework for creating SPAs that allows you to use a Model–View–ViewModel (MVVM) design pattern. Vue.js also has open source code.
- Ember.js is yet another open-source framework for building SPAs. It allows you to use the MVC software design pattern.
Choosing your solution
You can build an application using only libraries, or a framework. But in fact, web developers usually use third-party libraries and frameworks in tandem.
Your choice of framework or libraries to build a new project will depend on your proficiency level, and your knowledge about these tools.
As a rule, newbies start their journey either by using native JS without any libraries or frameworks, or by using one of the most popular frameworks. Once they choose a framework, they should take the time to study it and identify any disadvantages — and later on, they can actually help fix these!
Meanwhile, experienced developers often have thorough familiarity with a wide selection of tools and they know what pitfalls to avoid. Accordingly, they choose their technology stacks based on the tasks that they need to perform. For example, one of the most commonly used set of tools is React and Redux, which aren't particularly strict about implementation, and allow developers to experiment and be creative.
The old days
React, Vue, lodash, D3… these are a lot of names for a new developer to wrap their head around. Have you seen this post? This takes things to the extreme! On his LinkedIn profile, this developer says that he asks recruiters to identify the Pokémon on the following list — could you do it? Give it a shot:
Things weren't always like this. Back in the 2000s, the concept of a "web application" didn't even exist. Instead, websites had static layouts which were delivered by web servers written in PHP or in .NET (C#). Instead of cool SVG animated buttons, we just had static image tags.
At the time, frameworks were yet to hit the scene, and these ancient 2000s web developers were instead focused on implementing functionality and website content. But some web developers actually wanted to speed up the development process. To make that happen, they started creating libraries that would allow them to write less code. This, in turn, allowed them to focus on making their applications more dynamic, enriching them with the animations and the other cool stuff we've grown accustomed to.
Moving toward modern applications
In March 2005, some web developers introduced Dojo Toolkit. This is an open-source library containing widgets, methods for using local storage, and a REST client. Then, in June the next year, they released an alpha version of a JavaScript library called jQuery. This version offered methods for DOM manipulation, handling events, using animations, as well as using AJAX. These tools made it possible to simplify the web development process, using ready-made modules instead of manually writing the same utilities.
JavaScript: ES3 and ES5
At the time, JavaScript had different syntax and features and was different from the modern version we know today. In 1999, the ECMAScript 3 standard was published. This standard introduced new functionality that would eventually become the language that we work with today. ECMAScript 5, published in 2009, was an upgrade from ES3 and introduced several new enhancements. These included:
- The bind() method
- Expanded functionality of object properties and functions.
- Array methods: filter(), map(), and reduce().
- JSON parsing and serialization support.
- And the cherry on top, strict mode.
ECMAScript 5's upgrade was the first step towards fully fleshing out front-end web development, namely JavaScript. To get a better idea of how writing code became much easier, and how code got shorter, let's look at an example:
Where's ES4?
The ECMAScript 4 standard was quite an ambitious project, but due to poor ES3 compatibility, it never saw the light of day. After a long debate with the TC39 committee — which included members from Google, Intel, Microsoft, and Facebook — it was decided to continue developing ECMAScript 3.1. Later, in 2009, this project was renamed ECMAScript 5.