Closing The Loop of the Bootcamp

In this article, we will take a look back at my experience at DecodeMTL’s coding bootcamp. I have already talked about the first four weeks of this eight weeks intensive coding program in previous articles.

Those four weeks were like a mountain hiking trail, but with a cloudy cover that is hiding the top. Following the track, we went from one point to another, week after week. And we made it. We reached that halfway overnight spot where we can rest and start again the day after. I was exhausted and this midway weekend was not long enough.

There was something different coming back to class on this Monday of Week 5. It felt like a new semester at school. And that was nice. Getting into front-end development was like getting some fresh air.

Instead of covering every steps of this course, let’s just have a quick look at some of the cool stuffs we learned.


Taking Chrome as our favorite developer tool, we came to understand our dependency to browsers, those who are able to convert HTML and CSS into an actual user interface.

First step of the Cascade (Style Sheet), all browsers come with a default set of CSS rules that make a h1 tag look bigger or a ul+li tag look like a dotted indented list. This default set is called the “user agent stylesheet”, which can be slightly different across browsers.

To avoid this concern, some developers tried to reset these default styling in order to start over from scratch. This takes all styling away and your h1 now look as big as a paragraph.

Nicolas Gallagher took a different approach trying to get a consistent behaviour among browsers and built a css file called normalize.css. This approach goes for better stability by targeting only what needs consistency.

CSS3 Flexbox Layout

Worth mentioning it, CSS3 introduced a very powerful feature called Flexbox. This brought a few new CSS properties that address a common layout problem called the Holy Grail Layout.

Setting the layout of your page has never been so easy. As Flexbox allows blocks to automatically expand, it also lets you specify how much, along with alignment properties (including vertically! yay!).

Foundation framework

When came the question of responsiveness, we also got introduced to Foundation, a very popular front-end framework (such as Bootstrap).

Such frameworks pack all together a lot of components that are available right out of the box. Indeed, the goal of Foundation is to bring ease to developers when building a user interface. And this works incredibly well. It took me 15 minutes to learn the basics of Foundation and get a nice a responsive grid layout using the grid feature. And now, Foundation 6 just introduced the Flexbox version of it.

Foundation includes a lot of “prebuilt” styling for buttons, navigation bar, forms, media lightbox, flex videos, and many more.


CSS is huge and very powerful, but chances are you might get into a bit of mess in your code.

SASS is an extension of CSS that brings new functionalities in terms of coding. Its goal is to make stylesheets even more powerful by adding a programming feel when writing your code, making it clearer and easier to read. With SASS, you can:

  • create variables to store property values.
  • nest a selector into another.
  • import external stylesheets so we make our code modular.
  • create functions that can take parameters as input and return a set of CSS rules.

When coding, you are not writing strict CSS anymore but writing SASS-like code. Hence it comes with a command line compiler that will generate a standard CSS file based on your SASS code.

There is more to discover about SASS but one of the biggest pro about it is readability, meaning better maintainability. Less mess, less headache. To go a little further on this matter, Ziad introduced us to a methodology called BEM.


BEM stands for “Block, Element, Modifier”. This methodology consists in giving a specific class name for a block and each of its child elements, with a declarative syntax.

With BEM, a navigation bar would look something like this:

<nav class="nav">
<ul class="nav__row">
<li class="nav__item">Home</li>
<li class="nav__item">About</li>
<li class="nav__item">Blog</li>
<li class="nav__item nav__item--highlight">Contact</li>

This seems to be a little tedious but the purpose of BEM is to make our code more descriptive, increasing readability, by imposing a set of rules and finally ending up with a normalized html and css. This allows everyone in a team to share a more even language.

As a result, because each element has a class, CSS gets flatten, which kicks any question of specificity. And it’s also more performant!

Any doubts about the style of an HTML element? Just check the specificity hierarchy: four categories that address all CSS rules conflicts and govern what property applies in the end.

Plus, BEM blends in very well with SASS :

.nav {
width: 100%;
   &__row {
margin: 0;
padding: 0;

&__item {
display: inline-block;
padding: 0.5em;
margin-left: 0.5em;
background-color: black;


Watch this video to see how a BEM/SASS combo can be even better.


jQuery is almost ten years old now, and has become the most popular javascript library. Its core focuses on manipulating the DOM (Document Object Model) elements.

With event handling on top of it, jQuery makes everything much easier to interact with the user by acting asynchronously. Coupled with CSS, displaying a modal form can just come down to adding/removing a class when a certain button is clicked, literally coded, ‘on’, ‘click’, ‘removeClass’.

$('button').on('click', function (){

Basically, jQuery attaches tones of functions to DOM objects that you can access using a jQuery selector. And you can even add some of your own.

For example, have a look at this simple snippet that checks if an element is currently displayed on the screen, equivalent to, is present in the viewport:

$.fn.isOnScreen = function(){

var viewport = {}; = $(window).scrollTop();
viewport.bottom = + $(window).height();
var bounds = {}; = this.offset().top;
bounds.bottom = + this.outerHeight();

return (( <= viewport.bottom) && (bounds.bottom >=;

NB: you also have access to the window object!

Now put Ajax in and you’re set to build a client-side web application. You can send HTTP requests asynchronously, retrieve data from a server and update the interface depending on a specific action from a specific user.

Unfortunately, with the raise of web applications in the past decade, jQuery found its limit in the case of a complex web application, where other frameworks and librairies like Backbone.js, Angular.js, Ember.js or React.js have widely taken over.

Underscore.js templates

Underscore.js is a Javascript library that add a lot of helpers functions for manipulating arrays, functions and objects. The library also includes utility functions like template.

Underscore template gives us the ability to create an HTML template in which you can inject data, by using ERB-style delimiters:

var myTemplate = _.template('<p>Hello <%=name%></p>');

This will simply add the paragraph “Hello Nora” to the body of the page.

And this all comes right into place in the case of a web application, where you want to render a whole view with some data fetched by an HTTP request.


Backbone.js is a framework which purpose is to impose a code structure when building a web application.

Its essence is to provide the ‘M’ and the ‘V’ of a MVC (Model-View-Controller) architecture: the data will be held into models, and then be rendered with different views to the user.

Here’s what it would look like with a basic example of displaying a user profile:

Defining the model:

var userModel = Backbone.Model.extend({
urlRoot: 'http://myapp/api/users'

Defining the view using a template with underscore.js:

// importing the template from an external file
var profileTemplate = require('raw!./profile.ejs');
var profileView = Backbone.View.extend({
template: _.template( profileTemplate ),
model: null,
tagName: ‘div’,
render: function() {
this.$el.html( this.template({user: this.model}) );
return this;

And then both together in action:

var myUser = new userModel({id: userId});
//retrieving the user info
   //rendering the user info to the UI 
var userProfileView = new profileView({model: myUser})

Such a structure forces separating the business logic within our code, which helps to reason about your application evolving along the way.

Another thing Backbone packs in is a router, a common need that comes in when building a single page web application. It basically associates an ‘#’-based URL with a action, being a function that will be called on load. This allows to use the browser history of navigation.


Within Node.js, dependencies between modules/packages can be handled using CommonJS, allowing to ‘import’ a library installed with npm:

var _ = require('underscore');

or one of your own modules:

var helpers = require('./lib/helpers');

CommonJS is not available in the browser and dependencies can not then be handled that way when working on front-end development.

Because we want to keep that organization of code in our workflow, a module bundler like Webpack is required to pack our dependencies all together in one file, with a simple command line:

webpack main.js bundle.js

Your HTML file will now request a single script. And of course, there’s a watch mode to recompile your bundle while you are coding.


Even with just SASS and Webpack, we need two commands to compile our CSS and our script bundle. Grunt is an automation tool that will let us run multiple commands with only one. All it takes is a Gruntfile.js file, and a single command line grunt.

Grunt allows you to create tasks like sass, or webpack. And then lets you create different sets of tasks to run in order. This comes very handy for managing different environments. You can set a build task, a dev task, and a deploy or production task.

Indeed, when developing, you want to watch your changes and recompile your css and script on the fly, and probably run a local server to preview your work. While deploying your final work could be in a different directory or a specific branch.

It will take a bit of work to set it right at the beginning of your project. But it’s likely you will rather use a ‘starter kit’ version of it, that includes your usual tasks.

With all those tools in hand, getting started with a existing project has never been so easy:

git clone
npm install
bower install

good to go!

Depending on the final projects proposed by the students and their willing to learn certain technologies, Ziad will adapt the curriculum of week 6 for the students to get the most of it. In the last cohort, where I had the pleasure to be their teaching assistant, we learnt React.js to build the final projects’ user interfaces.

Week 7 and week 8 of the course are fully dedicated to the final projects.

I have to admit, to me, learning front-end development was more disorienting compared to back-end. I felt learning back-end was more linear while front-end seems to have different tracks, ending with multiple parallel learning curves.

This feeling should probably be taken with a grain of salt. Because of the intensive nature of the program, five or six weeks of knowledge might have started to be a lot for my brain to process.

Don’t get me wrong. I have had an awesome experience all along at DecodeMTL. We didn’t realize it was the end until the very last moments. My classmates and I had a great feeling learning together. And I think it will be useful to take a step back at it in a future article.

Yet, I was also very exciting by my new acquired knowledge, a great feeling of being capable of building crazy projects. This was just the beginning of the real adventure.

My final project was a music-oriented application called Weather Sequencer, built with François Leclerc and Karl Soulière-Crépeau.