This is an article I've wanted to write for a long time but kept putting off... Today I woke up at 5am and, by some hidden force of nature, sat down in front of the PC to write something mysterious that came out of my head.

Without further ado, the goal here is to describe some Front-end architectures — a complex and strangely underaddressed topic.

In this article I'll cover an example of architecture and the traps of not following a well-defined pattern. What I bring is the software developer's perspective and things they should care about to mitigate future problems, for themselves and for the company.

Software architecture is about what matters to the business.

Career growth is a very important topic — and it can often be challenging to chart the right path or choose the ideal topics to study.

With that in mind, I'm sharing here some essential topics for those who want to enter or deepen their knowledge in Front-end development.

Application design is an extremely important topic in software development. I see many people with no idea how to create a good architecture, which can create major complications as the system evolves — new features, new demands, problems, delivery pressure, and many other factors that contribute to increasing application complexity.

Entire systems can be rebuilt simply because the team failed to create a good architecture, or at least an ideal starting point that allows the project to evolve and adapt. This can happen for various reasons: lack of knowledge and pressure to deliver (very common). The latter creates a trap by assuming that skipping precious software development steps in the name of speed and delivery won't affect quality and scale.

In this article I'll cover some problems that can arise from not following a well-defined standard. My goal is to bring the software developer's perspective and things they should care about to mitigate future problems — for themselves and for the company.

A simple thing that can turn into a big problem for web projects is icon organization.

It is extremely common to use libraries like HugeIcons, Lucide, Material Icons, Font Awesome, React Icons, and many others. It is also quite natural for the team or designer responsible for the project to create their own icons according to the project's and team's needs.

This scale and mix of icons can lead to a lack of standardization in the project — many libraries export similar icons with a wide range of characteristics.

One approach I like to use to avoid this problem is to standardize icons in a single file, exporting only those that are allowed in the project.

One of the hardest things in a Node project is keeping libraries up to date. Anyone who works with package management using Node knows exactly what I am talking about. In production, a project can easily scale its libraries — and consequently the sub-dependencies that come along — making the task of keeping everything updated quite challenging.

Keeping a codebase up to date can become difficult as the project grows and new features and libraries are added.

Throughout a project's lifetime, minor and patch updates are very common in libraries and, in most cases, do not cause any trouble — they are even transparent to the development team.