The Frontend Developer's Dilemma
Lately, many people around me, developers, CTOs and even some PMs have used the term "modern frontend" to make me understand that he meant something much more complex than it was a few years ago.

All this made me reflect on the substantial change that the world of frontend development has undergone in recent years and to realize how even the professional figure of the frontend developer is completely different from a few years ago.

Let's start with some historical context

#My first approach to programming: 2009

when I created and put my first website online I had just entered high school and the frontend world was basically "a bit of html, css and javascript" mounted on a php page and for the more enterprising a magick wand called "jQuery"

My own IT professor called developing web pages "a game to play when you didn't want to program with C"

The Frontend Developer's Dilemma

#The current situation: 2020

The three main actors of web programming always remain html, javascript and css, it seems that nothing has changed.

The Frontend Developer's Dilemma

but with the growth of the power of computers and browsers we started looking for new javascript libraries to structure and optimize the code at its best, like React, Svelte, Vue and Angular,

we tried to find more developer-friendly ways to write the css, in order to make it more manageable for large projects where maybe many developers put their hand, like Less, Sass, Css-modules and Styled-components

we have created tools to support the development with these new libraries so that in any case the code readable by the vast majority of browsers was automatically created like Webpack, parcel and Rollup

we started creating reusable modules and managing them with package managers such as npm and yarn, we realized that we could divide the frontend from the backend by making them communicate viarest api or Graphql query, we realized that our applications could manage really a lot of data and therefore that state management libraries such as redux, vuex or mobx could help, we understood that a typed language could be more comfortable for working in teams or single tasks without having to go crazy with integrations and Typescript was born, we understood that our code must be tested with the same importance with which the backend must be tested, therefore finding solutions for unit, integration and behavioral test.

but above all we understood that the task of a frontend is no longer limited to writing simple support code to embellish a php page, nor to having to run necessarily on a browser and, more importantly, that the frontend developer is not the "artist" brother of a developer.

The Frontend Developer's Dilemma

The figure of the frontend developer has turned into a frontend engineer

A frontend engineer must deal with:

  • optimize the code
  • write tasks to compile or transpile it
  • manage the rendering part
  • write calls to APIs or to any other data source
  • know how to configure a CI to bring the application into production
  • configure a webserver to serve the application
  • a very long series of other skills that are useful regardless of whether you work on the frontend or the backend

All this has led, in addition to a greater interest in this world and an increase in libraries, open-source projects, frameworks, etc., also to two great problems that are old in the world of programming:

  • Over-engineering
  • Legacy Code


Over-engineering is the act of designing a product to be more robust or have more features than often necessary for its intended use, or for a process to be unnecessarily complex or inefficient.

Over-engineering can be dealt with from many points of view, the structure of the code, code itself or, the one I want to talk about, using tools, libraries or tools not necessary for our project.

How many times have we found ourselves in projects that used redux even if it didn't help but only because "everyone uses it". A healthy and even long planning phase is the basis for being able to start with a project and also ask "do I really need to use this tool?" allows us not to over-structure our project, save time in development and kb to have to download to our users!

we often find ourselves in the heat of wanting to use a new framework discovered in an article at a conference or because everyone uses it. Stopping to ask if it is necessary for our project at that moment will prevent us from falling into a mechanism called "hype drive development" (called HDD) which we could talk about for days but which I will summarize with this provocation:

Let's stop creating portfolio pages using React.

(ok I'm the wrong person to be able to say this since because my personal site is made in React, but while HDD is extremely dangerous for a company I think it's fundamental in personal projects to learn new things and have the ability to decide, in future, if a tool can really help you or not)

#Legacy Code

One of the biggest problems, especially if we use a lot of libraries is the ease with which we generate legacy code that I won't want to work on next year anymore. The biggest problem with the HDD is that the libraries we have imported will obviously undergo constant updates, hopefully, but our ability to update the libraries, especially in the case of major releases, may not go hand in hand.

We have a fundamental tool that seems every so often we forget that it exists, javascript. Having chosen a framework or a library, eg Angular, does not mean that 100% of our codebase should be written with the paradigm submitted by Angular but that for its strengths we can take advantage of Angular and take advantage of pure js, perhaps going to create modules external to be able to import on multiple projects and/or parts of the project, to have code that:

  • can be maintained even by those unfamiliar with the framework used
  • can be exploited even if we want to change the framework one day
  • is as molecular as possible so that you can refactorize a single part without having to go through the whole project

#What's next: 2021 and beyond

In accordance with the above I would like to quickly introduce two concepts that are catching on and, in my opinion, will bring forward the change and growth of the frontend world in the coming years.

#Micro frontend


The idea behind Micro Frontends is to think about a website or web app as a composition of features that are owned by independent teams. Each team has a distinct area of business or mission it cares about and specializes in. A team is cross-functional and develops its features end-to-end, from the database to user interface.

The Frontend Developer's Dilemma

#Atomic Design


According to the author of Atomic Design, Brad Frost, atomic design is defined as a methodology for creating design systems.

There are five distinct levels in atomic design:

  • Atoms
  • Molecules
  • Organisms
  • Templates
  • Pages
The Frontend Developer's Dilemma

#Special Mention: WASM


At the beginning of the article we said that the three main players in the frontend world are html, js and css. A few years ago a new actor has entered the scene, called wasm, whose strengths are efficiency, modularity and safety. Surely we must pay attention to this new frontier because it will change many aspects of frontend development.

WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable target for compilation of high-level languages like C/C++/Rust, enabling deployment on the web for client and server applications.

The Frontend Developer's Dilemma


The world of programming has changed and will continue, fortunately, to change often, this means that making the right choices at the beginning of a project will always be difficult and dictated, for the overwhelming majority of the times, by experience. So just try to find the best way for you not to suffer too much when you realize that you have made a wrong choice at a technical level and already prepare a list of runaround for the PM to ask for more time to allocate on the tasks ๐Ÿ˜‡