Reflecting back on the Pixel2HTML Boilerplate Generator
Chaos: a little bit of history
As you may know Pixel2HTML is a 100% remote company, with more than 20 developers around the planet, handling an average of more than 50 projects at different scales (from simply email marketing templates to full responsive react web applications) on a monthly basis.
In the beginnings we delegated the kick off of each project to the assigned developer, thus letting her/him to take a lot of decisions about technology, file structure, code compilation and code climate.
Boilerplate Generator: our initial solution
We knew we needed a tool to solve most of the architectural and technological decisions out of the way and let us focus our brain power in other tasks and problems of the project.
Without a set methodology, no much guidelines, no standardised file structure, no naming conventions and delegating these decisions on each new developer we hired look like the start of a never ending problem. We needed to have a securely way to scale operations and code reviews while hiring more developer to handle more and more complex projects with confidence.
So we decided to start the Pixel2HTML Boilerplate Generator to sort that out.
What I mean by Boilerplate Generator is essentially a set of tools and conventions that standardise certain elements of the web development process.
The internal motto was:
We need a simple and easy to use tool that generates a compendium of cascading and connected SCSS files, with some naming conventions, file structure suggestions, some popular frameworks integrations, plug-ins and library scripts that ensure any project worked on by any member of the team will stay on convention, and be simple enough for anyone else to step into and work with at any time.
Solving problem #1: Foster code consistency across our projects.
As you may already know of the most common, all time and hardest problems of code development is naming conventions. This can make the most zen-like developers spit fire whilst enganging in never ending discussions in the meet-up of your choice. In the Front-end development world we usually see people who places their images on an
img folder, and other one that save images into an
images folder inside a global
assets folder. Other projects store files on the root folder and then that builds onto a
build folder, and other peeps use a cleaner structure using the
See what I just did there in the last sentence? 😉
We know that there isn’t a standard to solve this problem, so we analyzed hundreds of previously built projects in order to come up with a file structure standard that we could also fit well into our work-flow.
Having a standarised name and file structure convention is one of the benefits from using a boilerplate generator. If when a developer starts a new project, he/she might do things slightly different (this can be something small, like changing the way you layout your HTML, or something huge, like deciding on a overall new naming convention). This can make it extremely difficult for others in the team to follow your work or even for him/her to go back later and remember how things were written at that time. We wanted to use this as an approach to sort out a bit of the technical debt of new hires and also making life easier to QA and other people in the team.
You can obviously say: Yeah but it’s not too bad right? Now try to multiply this problem of having different standards in one project across 20 developers around the world and in 50 projects per month. Think again perhaps?
Solving problem #2: Eliminating Repetition
This is the most basic and understandable reason for developing a front-end boilerplate generator.
Just run a command in your preferred CLI:
$ yo pixel2html
Solved problem #3: Ensure the automatization on code building and delivery.
In case you did not know, we work with a Continuous Integration system that rebuilds on each commit our demo servers so that the client can see the changes day by day in order to generate feedback and arrive at a better product.
Standardizing the build and deploy process was also a task in which the necessary process standards had to be reached in order for the task to be 100% automatic and specially, fault-tolerant.
Solved problem #4: Reduce the time to onboarding new developers to our way to build sites for our clients.
Growing up hurts, and hiring developers around the world can be a problem. From the moment a developer becomes a candidate, we do a code test that allows us to see how much they know and how they would adapt to our workflow.
One of the requirements of the test is to use Pixel2HTML Generator, which enables us to test if you have the ability to use a tool that you do not know and also to introduce the tool in the daily work for later, if you are hired and start using it.
Besides problem, we found some nice features doing this tool:
We made an Open Source project for the first time.
The idea was initially to make an internal tool based on Yeoman, a great project that makes this task a bliss.
Rapidly the question arose: Why not do this project an Open Source Project? We are big fans of OSS, we use and we collaborate daily with multiple open source projects, but we did not have our own, to improve it, make it 100% usable for any outside of Pixel2HTML and receive feedback / issues that help us to the process.
After some changes that helped to eliminate our footprint, the repository was born in Github and the package was published in
Today the project is available to be used by anyone who wishes to use it, just by typing
npm install -g yo generator-pixel2html
We get a lot of Internal and External collaboration
Part of the decision process on standards and naming conventions was initially de facto and then we took feedback from the daily work of our developers to generate a better tool.
Also, this generated that several of them get some interest in improving it, adding features that they felt necessary or generating personal tools that adapt to their workflow.
About 2.0 version
The next stage of the process is to add to the compilation routines some linting systems to do a static analysis of the code to unify criteria of syntax and code standards that, although we have, we are not measuring exhaustively.
Part of the idea of this process is not only to raise the quality of the code in general, but also to improve the collaborative process between developers working on the same project, something that has been happening more frequently in large and long projects over time.