DEV Community

Cover image for Excessive variability in Front-end Stack: essence and reasons

Posted on

Excessive variability in Front-end Stack: essence and reasons

In this article, I want to share my views on the Front-end Stack and answer the question of why there are so many different frameworks in the Front-end and what contributes to the emergence of new ones. I also want to highlight the criteria by which I choose certain technologies in large projects.

I will not consider the specifics of solutions for small projects, this implies slightly different approaches to working with performance and scalability.

Problem statement

Suppose you are competent enough and know how to develop accurately and without code smells in JS or TS, or without PSD to HTML services even though it is a great service.

What front-end stack will provide reliability and good performance as your application evolves, without becoming obsolete over time?

It would seem that the React library and the Angular framework have long taken leading positions. But their ratings could get shaky in the coming years, as competitors like Svelte, Stencil, and others constantly enter the arena. Their authors quite ambitiously declare that it is their tools that are better, faster, more convenient. And what if large corporations are engaged in their development, which in their characteristics will catch up with or even outperform the good old "reactors" and "angular" ones?

I do not think that React and Angular will leave the top positions, but, firstly, this is my personal opinion, and secondly, I am guided by certain principles when choosing a stack, which affects my preference for front-end engines. in the future.

Our industry is extremely dynamic today and for good reason. There is a technical background that is the main reason for the constant change in everything: in browsers, frameworks, and libraries, in design patterns, and many other things.

We need to be able to work in an environment where development tools are updated and changed faster than building a single product.


Where does excessive variation manifest itself?

It is generally difficult for newcomers to Front-end development to understand which toolkit to choose and whose recommendations to follow. What to do after you've learned how to write in JS? Is it worth learning Angular, React, Vue, or maybe Svelte?

An internship in a good company will not answer these questions. Most companies and training firms focus on a particular set of tools. The focus on Angular, React or Vue is shaped historically and economically. It depends on which specialists there are more.

Few people want to move in breadth and spend time mastering the entire available arsenal unless it is a corporation with an unlimited research budget. Each company hones its skills in using certain tools. This is most beneficial when you have the same technical stack across the company as a whole and can easily switch people between projects.

The set of approaches to the development of finished products in each company is determined by the knowledge and personal preferences of its specialists, as well as the technical preparation of existing projects.

For Android developers, the problem of tool variability is not so pronounced. Android Studio is used as the main IDE, while in terms of code architecture there is a "mainstream" approach - Clean Architecture, which is already loved by the Android community and established in it. Guidelines, code style, tools are largely recommended by Google.

The situation is similar for iOS-developers. There is an ecosystem that Apple has carefully created and supports. For most cases, it is enough to use native Swift modules without resorting to third-party library modules. And in terms of architecture, there is Clean Swift Xcode - the most popular IDE.

Back-end technologies also have many well-established stacks. Literature written for Java developers is not as quickly outdated as for web developers. The most used framework is Java Spring. This is already enough to decide what to learn in the initial stages.

The .NET developer ecosystem is maintained by the .NET Foundation and Microsoft itself.

The frontend looks different because there is no single “top” private corporation (such as Google, Apple, Oracle, or Microsoft) that centrally governs the development rules for everyone. Such applications should work equally well on all popular operating systems and browsers.

These teams work with standards from non-profit organizations such as W3C, WHATWG, TC39, and others. And here, on the one hand, there is complete freedom of action, on the other - complete chaos. Google and Facebook, as well as smaller companies, compete to create the most “correct” tools and architectural approaches.


Variation in standards for web applications and the reasons for it

There is no well-established opinion on how to write applications for the Internet yet. The direction is actively developing, and the situation is unlikely to change shortly. First, let's understand what a web application is.

A web application is a client-server application in which the client communicates with the server using a browser and the webserver is responsible for the server.

The front-end is the front-end, and this front-end can technically take many forms.

The main forms are the multi-page application (the form of classic websites that originally existed), the single-page application, the server-side rendering application, and the now-fashionable progressive web application. Other options may appear shortly.

It is also important to understand that you can deploy the Front-end part of a web application in different ways: it can be a classic monolith, JAMstack architecture, or so-called micro-interfaces.

What is important to keep in mind when choosing Front-end Stack

To choose the most appropriate framework, you should read as much as possible about the experiences of your peers around the world, I believe so.

For front-enders, and most developers, the community plays a huge role.

Explore opposing views in the community, read thematic resources, channels in messengers, attend conferences, various meetups, and just communicate.

Many people want to learn how to filter out technologies that are just hype and find those technologies that will help.

Remember that every new tool that has hype around it performs well on simple demo applications like TodoList, but its real effectiveness can only be determined by using it to develop something really big and complex.

If some new framework seems interesting to you and you need more in-depth knowledge, try to come up with a case for a test project or start your own. This is where you will experience all the nuances of using it.


There are no established approaches in Front-end yet, experimentation with technologies, engines, and performance, optimization continues at the level of js engines, frameworks, companies, and even standards.

You are free to choose the solution that best integrates with your technical environment, fits your coding style preference, and uses certain design patterns.

Study real cases of your peers, read performance studies.

Discussion (0)