A Story of Frontend Development Devops
A Story of Frontend Development Devops
How an imagined team started with the basics and ended up with the current complexity of frontend projects.
Frontend development has gotten complex. Most people get into a project and don’t dare touch the setup. The configuration is so complicated, and there are so many dependencies on other tools that making a change is scary. How did we get here?
I want to explain how an imagined team started with the basics and ended up with high complexity. By looking at how things evolved, I hope we will understand the concepts (not just the tools) and the reasons for each new feature added.
The Basics
The team starts with a basic frontend setup: the developers work on the same files that the website uses. The project consists of only one folder, “public.”
The deployment process is straightforward: they upload the “public” folder to the web server.
Development Server
Someone in the team decides to develop a simple server that will imitate the web server where they deploy the files. This way, the development environment will be more similar to the production one.
This dev server is a static file server listening on port 8000 and serving the files in the “public” folder. Therefore, they now have one more file for their project, “server.js.”
This is the first time that the team has a file that’s not required by the final users. Instead, it’s a file that improves the developer experience.
Put Files Together
The developer experience is still not the best. They have a huge file, “app.js,” that they all work on. Then, they start splitting it into different files, but the HTML has to require and load many files instead of just one. Therefore, the performance of the website decreases.
How do they keep the user performance and increase the developer experience?
Someone in the team has a great idea: he creates another folder, “src,” where the developers work, and adds a script that concatenates all the files together and copies the result to the “public” folder.
They now have one extra step before deploying the project: the “build” step.
At this point, the “build” step is elementary and can be done with any technology. Yet, the team will remember it as the starting point of the complexity. After this, the project will never be the same.
Possibilities of a Simple Build Step
The ideas to improve the developer experience start to flow:
One proposes to do the same with CSS files.
Another proposes to use NodeJS for the “build” step; this way, they take advantage of installing modules through “npm” instead of adding a “script” tag with the “src” link.
Once they have NodeJS, the team is unstoppable:
A team member adds unit tests for some utils they have.
Another developer comes up with different environments for the various teams to test new features. They deploy to other domains from the same code and the same branch, avoiding conflicts when features are enabled for production.
Parse the Code
Here is a big “aha moment” of the team: adding a parser to the build step. Now, the build step does not just concatenate files: it reads them, builds the Abstract Syntax Tree (AST), and then writes the production file.
The team spends a few months developing and improving their own experience rather than the users’.
Two developers come up with the idea of linters, they want to force some consistency in the way they write code.
Another member decides to write the final file in a Javascript version that all browsers can execute. No more alerting users to upgrade the browser. Now the team uses the latest language features while keeping compatibility with old browsers.
The Performance Lead reduces the size of the output file by 50%: changing the name of the variables, removing unused white spaces, and, in general, minifying and uglifying.
A freelancer even comes up with a new programming language with types that compiles to Javascript. She calls it “Type script.”
The CEO Is Not Happy
The team has spent almost a whole year improving their own experience without adding any new features to the users. So naturally, this brings the CEO's attention, which goes down to the dungeon of the engineering team to ask them what’s going on.
They promise that all this complexity is for the best of the company, that from now on, they will be much more productive, and will deliver features faster and with more quality.
That was one year ago. The CEO is still waiting for the promised features.
If you like this post, consider sharing it with your friends on twitter or forwarding this email to them 🙈
Don't hesitate to reach out to me if you have any questions or see an error. I highly appreciate it.
And thanks to Michal, Miquel and Sebastià for reviewing this article 🙏