Frontend frameworks: Criteria & tips to become proficient with new tools

The goal of this post isn't to analyze which framework is better, but to provide a set of tools and a couple of tips to ease the learning of a new framework

In the early days of software development applications were made, from start to finish, monolithically. Since computers were expensive and not very accessible, clients had less processing power, so most of the code was on the server side. The evolution of software related areas and the arrival of web technologies forced the Software Development community to enhance and adapt former architectures and propose new different ones to keep the pace of this growth on its daily work. Nowadays, a client-server architecture seems inconceivable without the idea of frontend and backend. A full stack developer can't ignore this trend and has to learn how to place himself and feel comfortable on both sides.
At the same time, it is mandatory to have technical knowledge and criteria enough to know how to distribute the responsibilities of our application correctly. Delegating such responsibilities improperly to the client could generate serious security problems. Overloading them on the server could make us fall in a quasi monolithic model preventing us from taking advantage of the client processing capability to generate a better interaction with our application. These are just a couple of examples that prove why is essential to discriminate what goes where and why.
From my point of view, considering the way in which the software academic activity happens, there’s a tendency and a sense of comfort when working on backend, emphasized by our reluctance to the proposed web environment requirements (html,js,css...).
That’s why I decided to make a proof of concept (PoC) to compare different front-end frameworks, eventually arriving at the conclusion that, broadly speaking, they all share some key points that for each of them, define a “comfortable development environment". Some include: Visual elements reutilization (Components), state handling and management, navigation, interaction with external systems, etc.

At this point, I’d like to share and expand on these fundamental bases that any developer should know at the time of choosing a new framework and/or front-end oriented tool. These recommendations should be more useful to those who are starting working with this kind of technology, since those who had some experience with a particular framework probably will find the same similarities I found.

It's worth noting that the message of this post is not "every frameworks is the same". Not at all. We’ll definitely find intrinsic differences between them. This differences are normally based on implementation theories about concepts such as refresh, binding, and DOM management.
We won’t discuss or debate about which of these "ideologies" is better, instead we’ll give a number of tools and tips to ease the first steps on a new framework and, moreover, so the decision of which one to use isn't defined just by habit or affinity. If the developer's comfortable using a wide variety of tools, it gets even more interesting when he finally decides on one, because we’re prompted to analyze this "ideological" points the framework defends.

Don't run without debugger!

Before moving forward into the steps I’d like to discuss, it’s extremely important, to ease the learning of the tool, to use a debugger. Either the debugger of the tool itself, or the one in the browser, or some IDE’s; it is imperative to count on something that tells us what’s going on at every single instance.

Abstractions at sight

When working in front-end, we shouldn't forget that at the end of the day the most important point is that the user feels comfortable with the interface. It has to look good, it has to be easy to use, it has to be intuitive. All of these are essential attributes in this context.
That’s why once we start using a new tool, the first thing we need to know is what kind of structures we handle better for the modeling and reutilization of html components. Either through function or classes, with or without conventions, nowadays most of the frameworks in the market have structures which allow them to represent pieces of html and re-use them. The most used frameworks also feature specific languages that stand into html and js and allow us to use executable code inside a visual component.

Example of a "visual component" in React ^[1] (left) and ember (right)

Each component has its own

It’s useless to re-use visual components without a state that allows us to fully tap this abstractions. So the next step should be to find out in which way the tool allows us to give the component that state it needs to be showed.
Here differences get more definite. Frameworks like Ember or AngularJS determine a relationship between components and objects that represent their state. This way every component has an object behind it that is constantly shooting changes and serving the data that the view needs to get shown (obviously part of these data can be given when the visual component gets “built”).
React, for example, handles the concept of "state" and "properties" both embedded inside the component itself (more info in the react docs: https://reactjs.org/docs/hello-world.html). With each change on the view, it generates a new element (which represents a complete component ready to be showed) and renders it. Even though in terms of their nature these two examples are very different, the concept of handling state is always present.
Now we’ve moved forward on this concept, it’d be appropriate to analyze how we can link states between two components. Some frameworks are based on the idea of "binding", which basically consists of linking an object or reference with an element of the view. By this way, a relation is generated between both of them and when the value of one of them changes, it automatically causes a change on the other. The binding can be used to share state between two components. When you bind two components to the same object, this object becomes a sort of "shared memory" between them.
Others frameworks feature the concept of "event". Every update in the view is the result of an occurred event (e.g., a button click, a dropdown selection, a focus in X sector, etc). An event can generate changes in more than one component by parameterizing the function which generates such changes (commonly called callbacks) between the different elements of the view.
Although the binding keeps in an easier way the consistency between the view and its state, we must take into consideration that this is bound to a complex object model holding it (usually through listeners or observers), and therefore requires a mayor computation capability.

Defining a simple state and some internal functions to handle this state in a component. AngularJS directive (left) and a React component (right)

Let's surf

Once we understand the basics which allow us to make simple views, the next step is to know how we can surf between them.
Nowadays the navigability through urls has been settled, so every framework should keep up with that.
Whether in an embedded way, or using libraries, all of them give us the possibility to surf inside an app.

Definition of a link to surf between 2 screens of the same app: using the ember helper "link-to" (left), using "react-router-dom", a library standing on React created to handle routes (right)

Request, request everywhere

Most of web apps need to consume external services and there is always a way this can be achieved. Some frameworks feature embedded tools, other, following a minimalistic approach, decide to delegate the responsibility to external libraries. Fortunately, there’s a wide selection of JS libraries exclusively built for that purpose (like axios or fetch).

Example of how to make a simple GET request: Using the request interface featured on ember-cli (ember-ajax)(left). Using raw axios (on this case, in a React app, since React doesn't feature in its core a model to handle the request)(right)

Integrating

Another important aspect to analyze, once we had our first clashes with the tool itself, is how easy it is to adapt it for using it with other external tools (like some JS library). Some frameworks are somewhat reluctant to integrate with external libraries that can make our work easier. When considering an integration, it’s a good idea to evaluate an environment which makes it so. Keep in mind that there’s always a way, just have to dig deep, even more when we’re talking about JS libraries.

And it doesn’t end here...

It’s my belief that finding out how the framework handles these points we’ve evaluated gives us the tools to feel comfortable and develop our first apps in the technology. After that, it's up to us to investigate the endless variety of plugins and/or extensions that each tool provides in order to analyze the more tangible differences that raise from then on.