Inside htmlBurger, Web Development
Our Front-End Coding Standards
What coding standards we follow at htmlBurger and why they are so important?
Among the most common questions I get is whether the result we deliver is pixel-perfect. I prefer to answer we do perfectly balanced code. is just how the website looks in the browser, and it doesn’t fully reflect the quality of the work. What’s also very important is how the code behind looks. The quality of the code affects how one website works, how fast it loads, how flexible it is, and how easily another developer can understand and use it.
This brings us to the question: “How can you ensure the code you deliver is high quality?”.
And the short answer is: “Our coding standards.”
Why We Needed Coding Standards?
Before we created our coding standards, our company was just starting to grow and at some point, it would have been difficult to keep on track of everyone’s code. What we needed was some sort of a guideline for best practices that is still flexible and gives developers the freedom they need to experiment with new technologies.
We’ve formed a specialized team of experienced developers. After the initial phase of research, the team concluded that while the code delivered was in general well done, it was not consistent across the different developers. We needed to unify the whole process and create standards for everyone to follow. And here’s what we expected as a result:
- Make the code better-looking and well organized
- Increase the quality of the work in general
- Improve the performance of the developers
- Enhance the collaboration between developers/teams internally
- Help our clients and their teams use our code with ease
To come up with these standards, the team who was assigned the task spent quite a lot of their time investigating different methodologies, libraries, coding principles, languages, and whatever you can think of – practical, theoretical, or even very abstract.
Our Coding Standards
What we now call “Our Coding Standards” is in short – principles, methodologies, and tools combined into a manifest of what we believe are the current best practices. And we constantly update those standards to reflect the rapidly evolving world of web development.
Of course, we are aware those standards may either not work for every single project or some clients may have their preferences and ways of doing things. And we are fine with that. We always adapt our working process to meet those needs. But the best part is, this gives us valuable insights, about what we could improve and adjust in our standards to make them better with every new project.
I’ve listed everything separated into different groups with a short simplified explanation for each.
BEM Methodology
Across other alternative methodologies like OOCSS, SMACSS, SUITCSS, Atomic, we selected BEM, because we’ve found it close to what we were trying to achieve. It was well accepted by developers and clients. And it was also suitable for projects of all kinds – no matter their size or complexity.
After the adoption process began, the team responsible for the coding standards made some small modifications to what the methodology suggested, just to adapt it to our needs. And later, we created a set of snippets based on BEM for HTML, CSS, and JS. This helped the developers inherit the methodology and its principles, but also enhanced their productivity.
CSS Frameworks Usage
This was another important part of our internal discussion. Should we use a CSS framework by default or not? We knew most of our clients prefer to use Bootstrap, because of its popularity and flexibility.
Even so, we decided, using a CSS framework by default was not a good idea. One of the reasons is, it’s not suitable for all kinds of projects. For example, if we add a CSS framework on a simple landing page, this will add a lot of unnecessary code. Respectively, the loading time increases too.
So today, we still use frameworks like Bootstrap, Foundation, Bulma, [add the framework of your choice :)], on a daily basis. However, we only use them, when the project is suitable or when you, our clients, need it.
CSS Writing
How should we write CSS? That was another topic we needed to cover. At that time, writing plain CSS was still very common. However, we already tried SASS, LESS, and some others, and we knew the advantages and disadvantages they come with.
Bootstrap was available with both SASS and LESS, but at the end of the day, we decided SASS is what we needed. The main reason for selecting it was, most of our devs already had experience with it, and many of our clients preferred SASS over LESS. So it was a no-brainer here.
Why selecting a preprocessor like SASS? Because it gives lots of power to the developers by extending the CSS capabilities to another level, with options like variables, nesting, mixins, operators, and more.
But with the great power, comes great responsibility. Taking advantage of all SASS can give, may result in a code that is barely readable and overcomplicated. That’s why we set strict rules on how we write CSS and how everything is organized. According to our vision for optimized code, we built a starter template where everything is structured and organized in the most meaningful way.
HTML Markup
In terms of HTML markup, we had to first make sure our code reflects BEM and modularity. So we’ve added rules for how the HTML needs to be formatted, what elements to be used, and which to be avoided, when and how to leave comments, and most importantly how to name the most common elements.
We created a gallery with HTML snippets, our developers can use, but also contribute and suggest new things, so it can grow and become a rich and useful tool. The same was also applied to the CSS and JavaScript.
Of course, there are many more small details, like the fact that we separate commonly used parts of the pages, like the header and footer, into different HTML files. I won’t be able to cover everything in such details, but if you are interested in learning a bit more, feel free to get in touch with us. I will be happy to share it with you.
JavaScript
When it comes to JavaScript at the time of building our standards, jQuery was the king. So without questions, we added it as a default library for all our projects. It was a preference for most of our clients. We were very happy with everything it gives us. And most of the plugins on the internet were jQuery dependent. So it was a perfect choice.
Currently, losing some of its glory, jQuery is still widely popular. Many of our clients still need it, because of various reasons, and therefore is still part of our standards. On the other side, if you want us to use vanilla JS, Vue, React, or another framework, on your project/s, we would be more than happy to switch.
Before you ask, YES, we plan to gradually drop jQuery from our standards and I hope this will be soon.
Task Runners
Finally, we needed a tool that would help us combine everything and automate some of the repeating processes. We started using task runners back in 2012. After a while, we built our task runner using Node.js, Gulp, and Webpack. Thanks to their speed, simplicity, and an extremely large ecosystem of plugins and add-ons, these tools helped us build Jarvis, the highly effective task runner we were looking for.
In short – it bundles CSS, JS, HTML, minimizes CSS, injects HTML parts, copies assets, optimizes images, generates sprites, and much more. You can read
Conclusion
What began as a quick debate between a few colleagues about the best coding practices, ended up as a full set of web development standards and various tools anyone who writes code at htmlBurger, now follows. We continue to improve them to reflect the up-to-date web industry best practices.
And if your company has a specific workflow or requirements, we will happily follow them. We were given the chance to work with thousands of agencies and businesses from all around the world and we use all the insights you give us to improve our processes and better serve you.
P.S. I know the article is about coding standards, and still, there are no examples with code. Sorry about that. The article would have become quite long. If you want to see some, leave a comment in the form below, and I would be more than happy to share some with you.