The world of frontend

The history of unifying and organizing JS code into libraries and frameworks can be traced back to the emergence of JQuery in 2006. At that time, there were already many browsers, and each of them had its own JS, so the library became a silver bullet for all the problems with supporting multiple browsers.

But it was a library for manipulating the DOM, which was not enough, because everyone was bolting their own bikes to the project, there was no clear structure of what a proper Front-end project should look like.


Angular is a full-fledged MVC framework from Google with support for Typescript and Web Workers out of the box, as well as a great CLI that allows you to generate templates for components, routes, and services using simple command line commands.

But the price developers pay for “everything out of the box” is the large size of the framework itself, which is 7-8 times larger than Vue.js or React.

Due to its clear and rigid structure, this framework is stable and reliable, but it requires a lot of resources to write an application, so it is rarely used for small projects, but it feels great in Enterprise solutions.


This is the brainchild of Facebook in 2013, and it’s also my main tool that I use on the front-end.

It is worth noting that React is not a framework, but a visualization library, if you take the MVC (Model-View-Controller) pattern, then React is just a part of View.

This is the first product to use Virtual DOM to optimize the update of the DOM tree (document object model, which is later converted to HTML and consumes a lot of resources). The idea behind the optimization is to update only the data that has really changed, and use a lightweight virtual structure to find the differences.

However, this does not prevent it from being the most popular library among frameworks.

It’s rarely used alone, but rather as a part of additional libraries such as React Router, React DOM, or their analogs.

React has a much lower entry threshold, more flexibility, and freedom, which is an advantage for small projects, but it is also powerful enough to be used for large ones.

The main problem is that you need to build the framework yourself from a large number of libraries. A typical React project looks like this: React, React Router, React DOM, Redux, Redux React. If you packed all this into a box, you would have a framework, but you have to do it all yourself.


This is a framework that has found a balance between restrictions and flexibility. Its core primarily solves data presentation problems, so it can be easily integrated into existing projects gradually. However, it is also suitable for creating full-fledged SPA (Single-Page-Application) applications, as it has a full set of functionality.

Thanks to its good documentation, low entry level, and small size, it is actively winning the hearts of developers

It has a CLI, routing like Angular, uses Virtual DOM, and has a fairly fast development time like React.

Still, it has a less flexible component approach than React, and lifecycle management that happens “under the hood” in large projects can be a challenge due to the lack of obviousness and difficulty of debugging.

So, we can conclude that Vue.js is great for developing most web applications, but if you need to do a very complex display, you should use React.


I can’t help but mention another interesting candidate in the frontend world – Svelte. This is a fundamentally new approach to front-end development, because while typical frameworks are loaded into your browser and then start working, Svelte is a compiler that translates code written using its own syntax into elegant and optimized pure JS code. No Virtual DOM, no abstractions, just pure low-level JS.

And it would seem that what are the advantages here, we lose all the bonuses that frameworks give us…

In fact, the big advantage is that we don’t need to drag the framework itself into the user’s browser, there are no additional loads to calculate the Virtual DOM, and the JS garbage collector can more efficiently clean up the memory used by the program.

It’s worth noting that for large applications, where 25-50 or even 170 KB of framework is only 1-2% of the total application size, and Virtual DOM provides more benefits than it uses resources, the advantages of Svelte are not significant.

Nevertheless, it is actively gaining popularity and may become a new breath in the frontend world. But there are very few vacancies at the moment. As of August 26, I found 6 vacancies on Djinni. This suggests that the market is not interested in Svelte yet and I do not recommend starting your way into the JS world with it.