Best practices in web development

Table of Contents

Keeping your project in a good shape and maintainable form is important task for every web designer and developer. Today, we are going to look at various ways to achieve this, so you don’t have to decipher your code every time when you look at some older projects. The main goal of this post is to rather make you think about your work process, not to dictate you how you should work. So, use whatever you want or like and eliminate the useless.

Development Vs Production

First thing to talk about is the difference between development and production version of code. If you’ve ever worked with some library (jQuery, Modernizr) or framework (Bootstrap, Foundation, Ember.js, AngularJS) you probably already noticed that when you want to download the code you are provided with two (or more) options. First is to download / use the development version of the code or production version of the code.

The difference between those two is in the way it has been processed and its size. Production version is always minified and so its size is much smaller. For those of you who have no clue of what minification is. It is a process, done by some tools or scripts, during which all white space and comments are removed from the code. The result is dense piece of code put on one line. With this process the size of your CSS and JS files can be compressed in range between 30% to 90%.

The first thing to consider is to have two versions of your code. One for production (minified) and another for development. The production will be used for uploading to servers live, while the development will be intended mostly for you. With this approach, you will be free to use comments and other ways to mark or disable pieces of code without worrying about the final size (they will not be included in production version). You will also be able to adjust the comments to your own style and language without the need to mark it PG 18+.

One last thing to minification. While it is very good practice for CSS and JS files, it is almost useless for HTML. Final size will not differ so much and website will be almost unreadable. In other words, it is almost waste of time. Now let’s look at the individual parts.


Since the HTML is the structure or foundation of every website (or XHTML), the best practice is to always use valid code and avoid depreciated tags. If you think in more holistic way, which you should, next aspects are proper accessibility  and good SEO. Your responsibility here is simple. Always stay up-to-date with your industry and be willing to learn new things. Being an early adopter and experiment with new features of HTML is good and it will give you an advantage, but I will leave this to you to decide on.

Last two things to say here is to use comments when you are not sure if the code is comprehensible and to think more about where to put JavaScript. The later will be discussed in section for JavaScript. For example, commenting individual sections of page or some more advanced snippets of code is a good idea. If you work with clients, they will appreciate it as well.


The easiest and fastest thing you can do is to use comments (for development version) to group blocks of CSS rules according to certain subject. Categories often used among developers are layout, typography, colors, base, etc. Putting similar rules into one group and on specific place inside stylesheet will make it easier for you to make additional adjustments and modifications later on. Additional thing is to also adopt some style of coding. Personally, I use code guide created by @mdo. Getting used to it can be harder in the beginning, but beneficial in the future.


I don’t suppose that all of you are using or are familiar with some of CSS or HTML preprocessors. However, it is still topic important enough to at least mention. For CSS, three most often used preprocessors are Sass, LESS and Stylus. We’ve already explored Sass earlier in a crash course. Here, you can apply all that was suggested for either HTML or CSS with one exception. Preprocessors offer you few great features for enhancing your workflow. For example, creating variables, mixins and placeholder selectors (Sass) and also importing another stylesheet. Even though CSS provide importing as well (@import rule), its support is lousy for old browser and it demands more performance.

This is not an issue with preprocessors. You can split your code according to the subject (variables, mixins, typograhy, colors, layout, reusable elements, etc.) and import them as you need into main file that will be later on converted into one big CSS file. This is, I guess, the best thing you can do to keep your projects (especially the big one) in reasonable and comprehensible form.


Let’s start with what we’ve touched in part about HTML and that is where to place JavaScript. It is also a good way to test someone’s skills. In a short, there are two places where you can put your JavaScript code (either link to file or code itself). First is inside the head and second is before the closing tag of body. Believe it or not, the difference will be huge. In first case, the JavaScript will be loaded along with the page. While in the second, page will be loaded first and only then scripts.

Imagine you have a regular website with some text and images. You also need to include a JavaScript file with code adding additional dynamics to that page. If you put it inside the head, it will have higher priority than the content of the page and so it will be loaded as first. This can be a problem in case of bigger or missing script file because it will delay loading of the page. Who likes to look at blank page? On the other hand, by placing the scripts before the end of body, you allow the page to load as first. If the JavaScript needs more time, user will at least has something to look at.

Another good aspect of having JavaScript on the bottom of body is in situation when JavaScript control some element on the page. If you put JavaScript inside head, how do you want to make JavaScript interact with element that doesn’t exist yet? Conclusion? When there is no reason to have JS in head, put it just before the body closing tag.

Most of best practices, like commenting and organizing parts of code and minification, should be used in JavaScript too. What’s also important is proper naming of your variables, functions, methods, objects, etc. Names like “fizz” and “buzz” are not funny anymore. You should always keep the names descriptive, so you don’t need to add comments in order to understand what certain snippet of code is supposed to do.


Optimize them. No matter how many images you have, always use some tool to optimize and reduce their size. For smaller images like icons merge them together into sprites. Why have twenty icons in twenty files if you can put them into one single optimized sprite? Benefit will be much lower traffic and much higher loading speed.

How many?

Last subtopic to discuss before we close this is how many files to use. This will be short. If you have no special reason, keep the amount of files as small as possible. Browser will load one file with 5000 lines of code faster than five files with 1000 in each of them. It will also require less requests sent to server – i.e. lower traffic. So, before you move to uploading your files, merge the CSS together and minify (compress) them and do the same with JavaScript files.


The one and most important goal of best practices, no matter your work, is to keep everything maintainable. That is what you should keep on your mind while thinking about implementing some advice into your process. Remember, development and production.

If you liked this article, please subscribe so you don't miss any future post.

If you'd like to support me and this blog, you can become a patron, or you can buy me a coffee 🙂

By Alex Devero

I'm Founder/CEO of DEVERO Corporation. Entrepreneur, designer, developer. My mission and MTP is to accelerate the development of humankind through technology.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.