written by Alex Macra (Tech Lead) in the March 2022 issue of Today Software Magazine.

Read the article in Romanian here

With 2022 just a few months away, we are already thinking about the years to come. Technologically speaking, we have changed the way we relate to the future. From an agile sprint that ends in two or three weeks, to a deadline of a few months, to an answer to the questions "Where do you see yourself in five years? What about ten?".

At the same time, we all know that experience defines our present and shapes our future. At some point, we may find ourselves searching for the truth we already suspect and see what is known as confirmation bias.

Throughout the article, I will answer one of the most challenging questions in the history of web application development: "What framework should I put on the project?".

There's a lot of talk on the web about frameworks versus libraries. Whether we choose a framework or a library, although they are different things, they are often a turning point for an application and the most important decision.

A briefly mentioned superficial difference highlights that a framework gives us a model or a particular design. In contrast, a library is a collection of functions or classes but is not limited to design. Currently, the library/framework with the best state management wins.

This is pretty much the most common situation on the web: state management. In short, web applications until recently were essentially stateless. A user called a web page, and the server responded with information (usually HTML). From there, user-server communication stops until the user requests another page or form. The state resets, and the whole communication process with the server starts again.

And the state is currently the difference between a document page and a web application like Gmail, with its drag & drop functionality, email interactions, and impressive user-server communications, all without the page moving out of place! Apparently.

As for servers, I have yet to be convinced - at least personally - by JavaScript. The debate about putting JavaScript on the server has many pros and cons. As far as I'm concerned, there are more cons. But for those who want to be adventurous, the best option in recent years is Node.Js and the Express framework.

I'll stick with this quick answer and propose we go back in history.

History (Word Back)

Sometime around 2009, when I first got in touch with this programming language, JavaScript had been around for 14 years, and the first and most extensive library at the time, jQuery, was three years old.

Back then, I still needed to understand that Microsoft decided not to implement an interpreter for JavaScript in Internet Explorer browsers but for another programming language, JScript, which was, after all, a reverse-engineered language strikingly similar to the original. JavaScript was then that programming language for which you had to write at least twice as much code as the alternative in jQuery.

Therefore, this jQuery framework was mainly the answer to the compatibility problem between browsers, with the motto "write less, do more!" Although it is a library that many consider being on its last legs, it is still present in over 70% of live sites. Not for nothing, we still have the saying, "Not working? Well, put jQuery on it."

In 2013, when I arrived in Cluj-Napoca, I discovered that jQuery and knockout.js were already dull. This was my first wake-up call to jump out of the seemingly sinking boat of these tools.

Colleagues in the guild were raving about a new AngularJS framework developed by a team at Google back in 2010. It has come out on top because it responded to outside demand to move away from static pages to build dynamic, animated and not least, smartphone-friendly interfaces and content. And away we went, carried away.

I dreamed of a new library developed by Facebook and launched around 2013. This library answered the call again, this time solving the "too many tools and lines of code for a simple app" problem. The 2016 model follows.

The transition from Angular to React was full of twists and turns. The many (opinionated) tools I had available in Angular disappeared in React. I felt like I had to build a skyscraper using Lego pieces. But as the years went by, the Lego pieces got taller, and the learning curve became exciting and less complicated.

Opinions could be found here, and the atomic way of developing an app could be applied before. But this library won me over with its perfect balance between programming very close to the language's syntax, having some valuable concepts from the library sphere up its sleeve, and also one of the best compatibility with state management systems I had seen before. I venture to say, like others: that the reactive programming ideology will endure for many years after the inevitable demise of the React library.

Rightly so, many developers believe that React was and still is a direct competitor to Angular. To this statement, I would add that we have only now started to develop a stable ecosystem in a relatively new programming language. What appears to be competition is stability in a growing field.

VueJs could be one of Angular's direct competitors, and React would only be one of them if we consider the transfer of developers from one technology to another. But this is mainly happening on both sides.

In the years that followed, I began to delve even deeper into this language, and the enthusiasm with which I said that "JavaScript will be everywhere, we'll put it on satellites, we'll put it on the fridge, we'll practically put it in the coffee!", was embarrassing. It turned out not to be so. If something were to be said about this language today, I would say the opposite.

Every decision to put a programming language into a particular medium, just for its sake, eventually becomes quite impossible. Because, more often than not, a programming language's place is where it was designed to be.

And the position of the JavaScript language remains in the browser or a browser engine. Now that we've started putting browser engines in cars and satellites, the above statement may no longer make sense, but it still applies!

As of 2021, I'm looking excitedly toward another library, Svelte. This one promises that you can write less code. It doesn't hold virtual dom and is a genuinely reactive library. And this time, the bookstore seems to be written just for me!

So, we can have two possible answers to the question, "me, what framework should I put on the project?". One, for the present: What sounds better to you between Angular, VueJS, or React? These are still in full expansion.

Choose your preferred variant with your preferred coding style, and you'll have peace for a few years. And another, for the future: Svelte is the best variant for looking into the future for the next three to four years. This tool can potentially dethrone bookstore after bookstore every year, including in terms of full-stack.

Decisions, Decisions

What can we notice in the history of this language? The oldest frameworks are still relevant, although jQuery is gradually losing popularity. I would have said ten years ago (when even then it was on its last legs) that it is already old! It remains a niche library, used when needed or in the background, popular enough even today.

As for Angular and React, they have a mature ecosystem that has been constantly improved for years, but is it enough to last in the battle for supremacy, where the "new is better" is defined? Probably not, probably yes. If we look at them as mere brands that reinvent themselves every chance they get and innovate so well that they push the programming language from behind to keep up, we could say that in ten years, we'll still be talking about Angular versus React.

What factors could dethrone these two giants? One would be a library that provides answers to problems and causes us to ask questions we didn't know we had. The second would be the language itself.

The JavaScript language has finally reached maturity and has the advantage of stability. We can lay some foundations on it; foundations that can stand today and tomorrow. The only disadvantage of a mature language is that it competes with other languages. For example, Dart excels in performance, and Python excels with its Django framework in complexity and machine learning capabilities.

Influence and inclination toward a library start primarily from the outside and take shape according to one's own experience.

How do you know if you've chosen the perfect library? A quick answer is that you don't. Then, even if you've chosen wrong, the baggage and experience you go to other bookstores and frameworks are essential.

We're back to the "me, what framework should I put on my project?" question again. To find the answer, we also need to ask the following questions and prompts: What is your current knowledge background? Did you learn Python in college? Build around them. Give Django a chance before diving into another ecosystem.

So, if we're asking the question from the JavaScript ecosystem, I'd recommend perfecting the language itself. Subsequently, what comes next can be categorized as a helpful factor.

Professional vs Personal Choice

Unfortunately or fortunately, things don't stay very fixed in this constantly changing field, and yesterday's truth is today's true until proven otherwise.

Years of programming experience are becoming less and less relevant, surfacing the importance of continuous development. So, we lose more than 40% of pertinent information every year. However, we are left with the certainty that this time we can still venture into the unknown, be it a new programming language, a new project, or an entirely different field. From here on, we are helped by the neural pattern that remembers similar events and supports us unconsciously.

Therefore, to the question , "For what kind of project?" we answer that only one thing is certain: the more complex the project, the more it helps to be able to control the library or to align as closely as possible with the programming language, for a control of everything that means performance and stability. At the other extreme, the smaller it is, you can try any library or framework, no matter how experimental. For the most part, the truth is somewhere in the middle.

When the Choice Is No Longer Ours

External events in the surrounding world and climate change can and will influence the way we work and how we ultimately manage energy in applications.

This new normal may mean that the days of adding libraries upon libraries, each loaded with more lines of code than operating systems saw in the 20th century, are beginning to fade.

Leaving aside performance, code efficiency, and the need to get as small a stream to the server with an even smaller response to users, was an external factor necessary to force us to realign? Most likely, yes.

In recent years, it has become standard for a web page consisting of a form and some text, along with a core framework and a few dozen other libraries, to end up weighing in megabytes. Did climate change need to put us in a position to reflect on the carbon footprint our applications can have?

So write less, do more!

The Final

Let's look strictly from the point of view of the maturity of a library or a programming language. We notice that the older, the better principle is constantly fighting with the New is better principle.

When we try to solve an existing or future problem, new languages or frameworks and often new libraries usually appear. By insisting on solving new or non-existent issues, we may forget those that have already been solved or those waiting for solutions. However, what is essential to consider is that unsolved problems always surface.

Join our community of problem-solvers