Coaching Session 004

Almost two months out of the blog and the coaching project because a lot of good things happened but finally we go back on track (about time).

I wanted to share some thoughts about HTML5 boilerplate: how I see it, what I think it is and what I’ll remove for my project.

It’s not every day that you start a project from scratch. Usually you join an already working project on a mid stage or, even if it’s not so, it’s architects business to define the project structure and stack. So it is that after some years of experience I was struggling to really come up with a starting approach to my project but this gets solved if you trust what html5 boilerplate has to offer . As they say on the homesite:

HTML5 Boilerplate is a professional front-end template for building fast, robust, and adaptable web apps or sites.

Which is good so we don’t have to reinvent the wheel every time and we have a common ground to start developing.

Main structure

I’m gonna go through the documentation itself so we can take a look together. This is the folder structure we will find when we download the package.


Everything is well separated and we’ll go one by one but a doubt already arises: is it better to have another folder for production? Usually we want to upload a whole folder to our server so it could be smart to have a separated folder to include all the processed files. In my case, and I may regret this afterwards, I’ll be working on the same folder as I don’t have html processing and I’d be copying a lot of files that are exactly the same form on folder to the other. Instead I’ll have some extra subfolders inside the css and js folders.

The doc folder includes the same documentation that we can find online so it’s good to have a look the first time you start using it but it will go directly to the trash can as we don’t want this on our prod server.

For the files on root we’ll get rid of almost all of them. Probably it’s good to keep some in special circumstances and overall if we are looking for SEO ranking as we are giving tips to the crawlers to understand our site. Basically all non-image files but index.html will get dumped. 404.html may be back in the future as we implement the web app but for now we don’t want to spend too much time messing with additional stuff. An explanation of the purpose of every file can be found online here. And about the images, a psd template can be found (although it’s no longer maintained) if we want to create some images of our own to fit the size and resolution on every situation.


If we dive into the index.html we can take a detailed look on every line of code:

Since html5 declaring the doctype has become way easier than in previous versions. This is enough for the browser to understand what kind of document is trying to render.

The no-js class will be removed by modernizr if JS render engine is present so we can target correctly with css. The lang definition is another good practice for nowadays Internet.

  • First of all, charset codification to let the browser know how to interpret the characters it’s receiving.
  • For the cross user agent compatibility (only for IE): It forces the browser the render at whatever the most recent version’s standards are. Just like using the latest version of jQuery on Google’s CDN, this is the most recent, but also can potentially break your code since its not a fixed version. (source).
  • meta > description: for SEO purposes.
  • meta > viewport: to make sure that the web is rendered properly in all mobile devices independently of their pixel density.

Some scripts are loaded outside of the head tag to prevent blocking the load of the page. This is because we are using a cdn which involves an http connection that may return error in a minute and we can’t let the visitor wait for that long. This is one of the drawbacks of having a cdn instead a local file. This and the fact that we wouldn’t be able to encapsulate and concatenate all the resulting JS in one single file we will be probably skipping the cdn method and storing local version of all JS libraries in the vendor folder.

The reason why a local file is loaded after the cdn request is because it needs jQuery to load. We’ll consider that server bandwidth is not an issue as well as having the latest version so we can load up everything on the head with on single JS file.

Related to this, one good point that appears on the FAQ is why don’t you-automatically load the latest version of jQuery from the google cdn?

And the reason is basically that pointing to the last release may bring some compatibility problems that we won’t be aware. Working with state of the art version is desirable but staying out of risk of unnecessary updates is mandatory.


For the css we get normalize.css to have a coherent starting point for all browsers as it applies a reset to make all browser render the pages on the same way. After that we have a main.css file in which some utility classes have been provided. We’ll keep this for the very first steps of the project and let’s see if they are really helpful of if they collide with our own class naming and definition. These two files will be saved in a vendor folder and we’ll have another folder called sass in which we’ll store the sass files.

Vendor and sass files will be compiled to a single file called styles which will be linked in the html.


If we take a look at the JS documentation we’ll see that there’s not much there. On my final project structure there will be a vendor folder for all external libraries which are not directly developed by me but all the general JS files will be on the root. We’ll get rid of the plugins.js file as we’ll be developing on recent browsers and we don’t expect to have any console communication in production but we’ll keep jQuery and Modernizr. Not sure if we’ll be using a cdn call and a local fallback or just a local file, this may change over time.

The final purpose is having the least possible JS files (at least until http2 is released) so we’ll be trying to concatenate them into one single file whenever possible if it doesn’t come at the cost of more coding difficulty.

Final words

This is the final look of the project after cleaning a little bit the html5 boilerplate (before the Js compilation).


2 comentarios en “Coaching Session 004”

  1. she could even be mixed with Lab because of the chocolate brown color. Your dog is a cutie too!Sheila and Cheap Chick: Thank you for the sunoestigg! I only have turquoise leggings, so I will put tights on my list for my next Sock Dreams order.

  2. – I can totally relate to “The Funk”! I feel like I have been stuck in one for a month. Bleh. Thanks so much for the encouragement!! I’m glad to hear you’re out of yours!!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *