Today I’m proud to announce that a “Responsive template” is now available on Initializr! It will help you dealing with all the various devices used to display your site. Mobiles, tablets, netbooks, laptops, desktop monitors, HUGE desktop monitors… Making your site work correctly on all these devices is a real nightmare. Well guess what? This nightmare is… absolutely not over! But as least, the boilerplate code of a responsive layout is now here to make your life easier.

Let’s see how it works and what best practices are introduced with this new template.

Little reminder about responsive web design

For those who have been living in a cave for the last few months (understand: for those who have a life and don’t spend days reading tweets and blogs) you probably need a short update about what a “responsive” design is.

The concept, introduced by Ethan Marcotte, is pretty simple: the page layout should adapt depending on the screen size so it’s always convenient and easily readable for the user. On mobile for instance, it’s more comfortable to get a minimalistic one-column vertical view than getting a 2 or 3 columns view – which is perfect for desktops. What about tablets? Maybe we can also adapt the layout to fit their medium size screen too? Since we can’t know the screen size of our users’ devices, well it should just work everywhere.

To design a responsive layout, we have to forget about the usual static 960px width layouts and go fluid with percentage widths and media queries.

A fluid layout with percentage widths

The first thing our page needs is a “fluid” layout. A layout is called fluid when the text adapts its container size and when proportions are preserved when the window is resized. To get this working we can’t have any hard coded static value for widths, horizontal padding nor horizontal margins. We can basically only use percentages:

 
#this-is-a-fluid-container{
	width:50%;
	padding: 20px 10%;
	margin:0 10%;
}

If you strictly follow this approach, your layout will scale perfectly from a small mobile screen to a huge desktop monitor. It’s already pretty cool, but you still have the same layout on every device, which is far from ideal! Don’t worry, now comes the fun part with media-queries to solve this problem.

Mobile-first approach media queries

Media queries are a cool way to specify different styles depending on the device used (by aiming particular screen resolutions or orientations for example). The mobile-first approach is the equivalent of progressive enhancement for media-queries. The principle is to start with the lowest resolution devices and then enhance the experience for bigger screens.

The “mobile” view

Here is the very simple mobile display of the responsive template. It doesn’t take into account any media query yet:

You can see that an aside orange block is located at the bottom of the page:

Note: Remember that an aside element is absolutely not meant to just be on the right or the left of an other element. Its semantic definition is that its content should be related to the main content, so its perfectly fine to have it under the article.

The “intermediate” view

If we display this page on a larger device (like a tablet or a wide smartphone), the vertical menu gets a little bit annoying and ugly because its buttons are stretched too much. We can use a media query to display them horizontally for screens larger than 480px like this:

@media only screen and (min-width: 480px) {
   	
	nav a{
		float:left;
		width:27%;
		margin:0 1.7%;
		padding:25px 2%;
		margin-bottom:0;
	}
}

Which has the following result:

The “wide” view

We now have a more convenient menu for tablets. Awesome! But what if we open this page on a laptop now? They have bigger screens so the vertical one column layout might not be the best fit for these devices. We would rather prefer a 2 columns layout, so we can move the “aside” block and the menu to the right of the page, and keep the content on the left. Let’s use a second media query to do that for resolutions higher than 768px:

@media only screen and (min-width: 768px) {
	
	#title{
		float:left;
	}

	nav{
		float:right;
		width:38%;
	}
 
	#main article{
		float:left;
		width:57%;
	}

	#main aside{
		float:right;
		width:38%;
	}
}

This is what we get on a screen of approximately 900 pixels wide:

We now have a nice 2-columns “desktop view”. You see, it wasn’t that hard to start from the mobile version first! I admit it might not be intuitive at first, but you get used to it pretty fast, and it’s definitely cleaner.

Note: You may have noticed some new shadows on this one. Fancy CSS3 effects, like shadows, are CPU consuming so they’re not very suitable for mobiles and low-CPU devices in general. This layout will probably be displayed on a more powerful device like a laptop or a desktop, so we can suppose they’re good enough to handle these effects.

The “maximal width” view

Last but not least, we want a decent display on wide screens. If we leave it as it is now and open the page on a wide screen, a 5 line paragraph would be turned into an awful huge single line, which is terrible for readability. We need a maximal width limit to avoid this on wide screens. This limit can be anything: 960px, 1140px, 2000px, whatever, just choose one that make sense for your site.

In our case I picked 1140px, which suits well 1280 pixels wide screens, the most common resolution. An old school wrapper with fixed width and auto margins does the job perfectly:

 
@media only screen and (min-width: 1140px) {
 
	.wrapper{
		width:1026px; /* 1140px - 10% for margins */
		margin:0 auto;
	}
}

I’ve set the wrapper’s width to 1026px (1140px – 10%) because on the previous layouts the margins were set to 10%. Therefore if we resize the browser it will move from one layout to another seamlessly. Here is the widest layout we can get:

All right! We’re done with media queries!

Christmas presents for nice web developers

Since you’ve been very nice this year, here are some other presents for you!

1st gift: A Live Demo!

There is now a live demo of the responsive template to see if it works as expected before downloading anything. This is also particularly convenient to see how it runs on your mobile or tablet.

You can find it on initializr.com/try.

2nd gift: The Golden Ratio

This responsive template comes with some golden ratio black magic. You may have heard of it, it’s a weird mathematical proportion that our stupid brains are supposed to like. Even if its effects are pretty uncertain, many designers and artists like to use it, hoping people will subconsciously like their work more. I’ve set the proportions of the left and right sections of the desktop view to 62% and 38% (take margins into account) so it always matches the golden ratio as you resize the browser.

Here is also a golden ratio calculator for you to play with, and an interesting tutorial about how to apply it to your layout. Feel free to use this black magic or not, but don’t go crazy with it, this is more myth than science :)

3rd gift: Readability For The Win

This new template comes with pretty decent styles for a good readability. Remember that readability is absolutely crucial for your users. It will make them actually read what you have to say instead of just looking at pictures, and if this reading is pleasant they will be more eager to subscribe, retweet, buy your stuff or whatever you want them to do. This is a pretty big deal!

Here is some advice to improve readability:

• Use a big font size and an adapted line height (this template uses 16px / 24px).
• A line should have approximately 80 characters (you’re all set with the template).
• Avoid paragraphs of more than 5 lines.
• Avoid sections of more than 5 paragraphs in a row.
• Put stuff between paragraphs when you can and when it makes sense so the reader can breath before he starts a new one (charts, pictures, code, decorations…).

4th gift: A Github repository for this responsive template

Some of you might have noticed that Initializr’s Github repository is the website’s repository, not the template’s. So it’s pretty useless for you except if you want to know how to generate archives in Java! I’ve created a new Github repo for this responsive template, so you can fork it and suggest modifications and improvements to it. Way more useful, yay!

Here is the new repository: github.com/verekia/initializr-template

Enjoy!

I hope this new responsive template will make your web developer life easier, so you can focus on your actual business instead of setting up again and again the same boilerplate code. I would love to hear your feedback about this, so feel free to open issues on Github or mention @initializr or @verekia on Twitter, I usually reply fast :)

Merry Christmas and Happy New Year!

As a web developer, you certainly often started coding your JavaScript in a single file, and, as the code base gets larger and larger, it became really difficult to maintain. To solve this problem you can split your code in several files, add more script tags and use global variables to reach functions declared in other files. But this pollutes the global namespace and for each file an additional HTTP request consumes bandwidth, which slows down the loading time of the page.

If this happened to you, you certainly understand that there is a strong need to organize our front-end code differently, particularly if we have to build large-scale web apps with thousands of lines of JavaScript. We need a new way to organize all this mess to make it easier to maintain. This new technique consists in using script loaders. Plenty of them are available on the web, but we’ll focus on a very good one called RequireJS.

In this step by step tutorial you will learn how to build a simple MVC (Model – View – Controller) app using RequireJS. You don’t need any particular previous knowledge of script loading – we’ll see the basics together.

Introduction

What is RequireJS and why it’s awesome

RequireJS is an implementation of AMD (Asynchronous Module Definition), an API for declaring modules and loading them asynchronously on the fly when they’re needed. It’s developed by James Burke, and it just reach the symbolic 1.0 version after 2 years of development. RequireJS can help you organize your code with modules and will manage for you the asynchronous and parallel downloads of your files. Since scripts are loaded only when needed and in parallel, it reduces the loading time of your page, which is great!

MVC for front-end?

MVC is a well known design pattern to organize server-side code and make it modular and sustainable. What about using it for front-end? Can we apply this design pattern to JavaScript? If you’re just using JavaScript for animating, validating few forms or any simple treatment that doesn’t require many lines of code (let’s say less than 100 lines), there is no need to structure your files using MVC, and probably no need to use RequireJS either. However if you’re building a rich web app with many different views, definitely yes!

The app we’ll create

To illustrate how to organize your MVC code using RequireJS, we’ll create a very simple app with 2 views:

• The first view will display a list of users (represented by a name attribute),
• The second view will allow you to add a user.

This is how it will look like at the end:

The business logic is obviously super simple so you can focus on understanding what’s really important here: structuring your code. And since it’s that simple, I strongly recommend that you really try to do it in parallel of reading this tutorial. It won’t take long, and if you have never done modular programming or used RequireJS before, coding this example will really help you become a better programmer. Seriously, it’s worth it, you should do it.

HTML and CSS files

Here is the HTML markup we’ll use for this example:

<!doctype html>
<html>
<head>
	<meta charset="utf-8">
	<title>A simple MVC structure</title>
	<link rel="stylesheet" href="css/style.css">
</head>
<body>
	<div id="container">
		<h1>My users</h1>
		<nav><a href="#list">List</a> - <a href="#add">Add</a></nav>
		<div id="app"></div>
	</div>
	<script data-main="js/main" src="js/require.js"></script>
</body>
</html>

The navigation in our app will be the links of the nav menu which will remain present on each page of the app, and all the magic of the MVC application will happen in the #app div. We also included RequireJS (which you can grab here) at the bottom of the body, and you can notice a special attribute on the script tag: data-main="js/main". The value passed to this attribute is used by RequireJS as the entry point of the entire application.

Let’s also add just a little bit of basic styling:

#container{
	font-family:Calibri, Helvetica, serif;
	color:#444;
	width:200px;
	margin:100px auto 0;
	padding:30px;
	border:1px solid #ddd;
	background:#f6f6f6;
	-webkit-border-radius:4px;
	   -moz-border-radius:4px;
	        border-radius:4px;
}

h1, nav{
	text-align:center;
	margin:0 0 20px;
}

OOP reminder: What is a module?

In JavaScript Object-Oriented Programming, there is a very common design pattern called Module Pattern. It is used to encapsulate methods and attributes in objects (which are the “modules”) to avoid polluting the global namespace. It is also used to kind of simulate classes from other OOP languages like Java or PHP. This is how you would define a simple MyMath module in our main.js file:

var MyMath = (function(){

	// Put your private variables and functions here
	
	return { // Here are the public methods
		add:function(a, b){
			return a + b;
		}
	};
})();

console.log(MyMath.add(1, 2));

Public methods are declared using the object literal notation, which is not very convenient. You can alternatively use the Revealing Module Pattern, which returns private attributes and methods:

var MyMath = (function(){

	// With this pattern you can use the usual function notation:
	
	function add(a, b){
		return a + b;
	}
	
	return {
		add:add // But don't forget to declare it in the returned object!
	};
})();

console.log(MyMath.add(1, 2));

I will be using the Revealing Module Pattern in the rest of this article.

RequireJS

Defining a module with RequireJS

In the last section we declared a module in a variable to call it later. This is just one way to declare modules. We’re now going to see a (barely!) different method used by RequireJS. The purpose of RequireJS is to split our JavaScript files for a better maintainability, so let’s create a MyMath.js file to define our MyMath module in the same folder as main.js:

define(function(){

	function add(a, b){
		return a + b;
	}
	
	return {
		add:add
	};
});

Instead of declaring a variable, we just put the module as a parameter of the define function. This function is provided by RequireJS and will make our module accessible from the outside.

Requiring a module from the main file

Let’s go back to our main.js file. RequireJS provides a second function called require that we’re going to use to call our MyMath module. Here is what our main.js now looks like:

require(['MyMath'], function(MyMath){
	
	console.log(MyMath.add(1, 2));	

});

The call to MyMath is now wrapped in the require function, which takes 2 parameters:

• An array of modules we want to load, declared with their path relative to the entry point (remember the data-main attribute in the HTML) and without the .js extension,
• A function to call once these dependencies are loaded. The modules will be passed as parameters of this function so you can simply name those parameters with the same modules names.

You can now reload the page and… congratulations! You just called a method from an other file! Yes, that was super easy and you’re now ready for the big scary MVC architecture (which works exactly like the module definition you just did, so be sure you’ll be doing great!).

The MVC structure

Important note: In this tutorial, we’ll mimic the server-side MVC in which 1 controller = 1 view. In front-end development, it is very common to have multiple views per controller. In this case views become visual components like buttons or fields. MVC JavaScript frameworks like Backbone use this different approach which is not the purpose of this article. My goal here is not to create a real life entire MVC framework, but simply illustrate how RequireJS works through a structure that many of you already know well.

Let’s start with the part I’m sure you love: creating all the folders and files of our project. We want to use Models to represent data, the business logic will be handled by Controllers, and those controllers will call specific Views to render pages. So guess what? We need 3 folders: Models, Controllers and Views. Considering our simple app case, we’ll have 2 controllers, 2 views and 1 model.

Our JavaScript folder now looks like this:

• Controllers
• AddController.js
• ListController.js
• Models
• User.js
• Views
• AddView.js
• ListView.js
• main.js
• require.js

Got the structure ready? Great! Let’s start implementing the simplest part: the Model.

The Model: User.js

In this example, a User will be a simple class with a name attribute:

define(function(){
	
	function User(name){
		this.name = name || 'Default name';
	}
	
	return User;
});

If we now come back to our main.js file, we can declare the dependency to User in the require method, and manually create a set of users for the purpose of this example:

require(['Models/User'], function(User){
	
	var users = [new User('Barney'),
	             new User('Cartman'),
	             new User('Sheldon')];
	
	for (var i = 0, len = users.length; i < len; i++){
		console.log(users[i].name);
	}
	
	localStorage.users = JSON.stringify(users);
});

We then serialize in JSON the users array and store it in the HTML5 local storage to make it accessible just like a database:

Note: JSON serialization with stringify and deserialization with parse need a polyfill to work in IE7 and inferiors. You should use Douglas Crockford’s json2.js from his Github repository for this.

Displaying the users list

It’s time to display those users in the app interface! We’ll have to work with ListController.js and ListView.js to do that. Those 2 components are obviously related, and they’ll be linked someway. There are many ways we can do that, and to keep this example simple, here is what I suggest: The ListView will have a render method and our ListController will simply get the users from the local storage and call ListView’s render method by passing the users as a parameter. So obviously, ListController needs ListView as a dependency.

Just like with require, you can pass an array of dependencies to define if the module relies on other modules. Let’s also create a start method (or any other name that makes sense to you – like run or main), to put the main behavior of the controller in it:

define(['Views/ListView'], function(ListView){
	
	function start(){
		var users = JSON.parse(localStorage.users);
		ListView.render({users:users});
	}
	
	return {
		start:start
	};
});

Here we deserialize the users from the local storage and pass it to render as an object. Now, all we have to do is implementing a render method in ListView.js:

define(function(){
	
	function render(parameters){
		var appDiv = document.getElementById('app');

		var users = parameters.users;
		
		var html = '<ul>';
		for (var i = 0, len = users.length; i < len; i++){
			html += '<li>' + users[i].name + '</li>';
		}
		html += '</ul>';
		
		appDiv.innerHTML = html;
	}

	return {
		render:render
	};
});

This method simply loops on our users to concatenate them in an HTML string we inject in the #app element.

Important: Using plain HTML in a JavaScript file like this is not an ideal solution, because it’s very hard to maintain. You should instead consider templating. Templates are an elegant way to insert data in HTML markup. Many very good templating systems are available on the web. You can for instance use jQuery-tmpl or Mustache.js. But this is beyond the scope of this article and it would add complexity to the current architecture, so I prefer keeping it simple.

Now, all we need to do is to “run” our ListController module. To do that let’s declare it as a dependency of require in our main.js file, and call ListController.start():

require(['Models/User', 'Controllers/ListController'], function(User, ListController){
	
	var users = [new User('Barney'),
	             new User('Cartman'),
	             new User('Sheldon')];
	
	localStorage.users = JSON.stringify(users);
	
	ListController.start();	
});

You can now refresh your page to get this wonderful list of users:

Woooaaaah, it works! Congratulations if you coded this too!

Note: For the moment, we can only manually declare the controller we want to run since we don’t have any routing system yet. But we’ll create a very simple one pretty soon, be patient!

Adding a user

We now want to be able to add users to our list. We’ll display a simple text input and a button, with an event handler when the button is clicked to add the user to the local storage. Let’s start with AddController, just like we did in the previous section. This file will be pretty simple since we don’t have any parameter to give to the view. Here is AddController.js:

define(['Views/AddView'], function(AddView){

	function start(){
		AddView.render();
	}

	return {
		start:start
	};
});

And its corresponding view:

define(function(){
	
	function render(parameters){
		var appDiv = document.getElementById('app');
		appDiv.innerHTML = '<input id="user-name" /><button id="add">Add this user</button>';
	}
	
	return {
		render:render
	};
});

You can now declare AddController as a dependency in your main file and call its start method to successfully get the expected view:

But since we don’t have any event bind on the button yet, this view is not very useful… Let’s work on that. I have a question for you: Where should we put the event logic for this event? In the view? In the controller? If we put it in the view it would be the right place to add the events listeners, but putting the business logic in a view would be a very bad practice. Putting the event logic in the controller seems to be a better idea, even if it’s not perfect because we don’t want to see any div’s ID in there, which belong to the view.

Note: The best way to go would be having event listeners in the view, which would call business logic methods located in the controller or in a new dedicated events module. This is really easy to do but it would make this example more complex and I don’t want you to be lost. Feel free to try doing it for practicing!

As I said, let’s put all the event logic in the controller. We can create a bindEvents function in AddController and call it after the view has finished rendering the HTML:

define(['Views/AddView', 'Models/User'], function(AddView, User){

	function start(){
		AddView.render();
		bindEvents();		
	}
	
	function bindEvents(){
		document.getElementById('add').addEventListener('click', function(){
			var users = JSON.parse(localStorage.users);
			var userName = document.getElementById('user-name').value;
			users.push(new User(userName));
			localStorage.users = JSON.stringify(users);
			require(['Controllers/ListController'], function(ListController){
				ListController.start();
			});
		}, false);
	}

	return {
		start:start
	};
});

In bindEvents, we simply add an event listener for clicks on the #add button (feel free to use your own function to deal with IE’s attachEvent – or just use jQuery). When the button is clicked, we get the users string from the local storage, deserialize it to get the array, push a new user with the name contained in the #user-name input field, and put the updated users array back to the local storage. After that we finally require the ListController to execute its start method so we can see the result:

Brilliant! It’s time for you to take a break, you’ve done a very good job if you’re still doing this example with me. You deserve a cup of coffee before we continue!

Navigation between views with routes

Okay back to work. Our little app is pretty cool but it really sucks that we still cannot navigate between views to add more users. What is missing is a routing system. If you’ve worked with server-side MVC frameworks before, you’re probably familiar with this. Each URL leads to a different view. However here we’re client-side and it’s slightly different. JavaScript single page interfaces like this one use the hash of the URL to navigate between different parts of the app. In our case, we want to be able to reach the 2 different views when hitting those URLs:

• http://yourlocalhostpath/#list
• http://yourlocalhostpath/#add

This will make each page of our app bookmarkable and easily reachable.

Note: Firefox, Chrome and Opera also have a pretty good support of HTML5 history management (pushState, popState, replaceState), which saves you from dealing with hashes.

Browsers compatibility and functioning

Managing history and hash navigation can be very painful if you need a good compatibility with old browsers. Depending on the browsers you aim to support here are different solution you can consider:

• Only the most advanced browsers: HTML5 history management,
• Most of the current browsers: HTML5 hashchange event,
• Old browsers: Simple manual monitoring of hash changes,
• Very old browsers: Manual monitoring + iframe hack.

In our case we will do the simple manual monitoring, which is pretty easy to implement. All we need to do is checking if the hash changed every n milliseconds, and fire some function if a change is detected.

Note: A jQuery plugin is also available to manage this for you.

The routes and the main routing loop

Let’s create a Router.js file next to main.js to manage the routing logic. In this file we need a way to declare our routes and the default one if none is specified in the URL. We can for instance use a simple array of route objects that contain a hash and the corresponding controller we want to load. We also need a defaultRoute if no hash is present in the URL:

define(function(){

	var routes = [{hash:'#list', controller:'ListController'},
	              {hash:'#add',  controller:'AddController'}];
	var defaultRoute = '#list';
	var currentHash = '';
	
	function startRouting(){
		window.location.hash = window.location.hash || defaultRoute;
		setInterval(hashCheck, 100);
	}
	
	return {
		startRouting:startRouting
	};
});

When startRouting will be called, it will set the default hash value in the URL, and will start a repetition of calls to hashCheck that we haven’t implemented yet. The currentHash variable will be used to store the current value of the hash if a change is detected.

Check for hash changes

And here is hashCheck, the function called every 100 milliseconds:

function hashCheck(){
	if (window.location.hash != currentHash){
		for (var i = 0, currentRoute; currentRoute = routes[i++];){
			if (window.location.hash == currentRoute.hash)
				loadController(currentRoute.controller);
		}
		currentHash = window.location.hash;
	}
}

hashCheck simply checks if the hash has changed compared to the currentHash, and if it matches one of the routes, calls loadController with the corresponding controller name.

Loading the right controller

Finally, loadController just performs a call to require to load the controller’s module and execute its start function:

function loadController(controllerName){
	require(['Controllers/' + controllerName], function(controller){
		controller.start();
	});
}

So the final Router.js file looks like this:

define(function(){
	
	var routes = [{hash:'#list', controller:'ListController'},
	              {hash:'#add',  controller:'AddController'}];
	var defaultRoute = '#list';
	var currentHash = '';
	
	function startRouting(){
		window.location.hash = window.location.hash || defaultRoute;
		setInterval(hashCheck, 100);
	}
	
	function hashCheck(){
		if (window.location.hash != currentHash){
			for (var i = 0, currentRoute; currentRoute = routes[i++];){
				if (window.location.hash == currentRoute.hash)
					loadController(currentRoute.controller);
			}
			currentHash = window.location.hash;
		}
	}
	
	function loadController(controllerName){
		require(['Controllers/' + controllerName], function(controller){
			controller.start();
		});
	}
	
	return {
		startRouting:startRouting
	};
});

Using the new routing system

Now all we have to do is to require this module from our main file and call startRouting:

require(['Models/User', 'Router'], function(User, Router){
	
	var users = [new User('Barney'),
	             new User('Cartman'),
	             new User('Sheldon')];
	
	localStorage.users = JSON.stringify(users);

	Router.startRouting();	
});

If we want to navigate in our app from a controller to another, we can just replace the current window.hash with the new controller’s hash route. In our case we still manually load the ListController in AddController instead of using our new routing system:

require(['Controllers/ListController'], function(ListController){
	ListController.start();
});

Let’s replace those 3 lines with a simple hash update:

window.location.hash = '#list';

And this is it! Our app has now a functional routing system! You can navigate from a view to another, come back, do whatever you want with the hash in the URL, it will keep loading the right controller if it matches the routes declared in the router. Sweet!

Here is an online demo of the app.

Conclusion

You can be proud of yourself, you built an entire MVC app without any framework! We just used RequireJS to link our files together, which is really the only mandatory tool to build something modular. So now what are the next steps? Well if you liked the minimalist Do It Yourself approach I had in this tutorial, you can enrich our little framework with new features as your app grows and has new technical needs. Here are some ideas of potential interesting next steps:

• Integrate a templating system,
• Create a small external library to put all what is not purely related to your app (like the routing system) to be able to reuse it on other projects,
• Define what a Model, a View and a Controller are with objects in this library,
• Create a new abstraction layer to deal with getting the data from various sources (RESTful APIs, localStorage, IndexedDB…).

This DIY approach is excellent to learn, but the current state of our framework is really not sufficient for real life projects at this point. If you’re too lazy to implement the features listed above (and this list is absolutely not exhaustive!), you can also start learning how to use an existing MVC framework. The most popular are:

• Backbone
• JavaScriptMVC
• Sproutcore
• ExtJS
• Knockout

I personally like Backbone because it’s lightweight (less than 5kb minified), so my next tutorial will be about mixing RequireJS and Backbone, which works pretty well! Follow @verekia for updates about this. You should also follow Addy Osmani and read his tutorials about large scale JavaScript applications and modular JavaScript, and James Burke the creator of RequireJS. Both are very good sources of information for building modular JavaScript apps. Addy Osmani also started a project called TodoMVC to compare how different MVC frameworks can be used to build the same simple web app, which is really helpful to choose the right framework for your needs.

That’s all for today folks, thanks for reading!

WARNING: If you like copy-pasting, find-replacing, scrolling in giant messy CSS files, not reusing your code, writing hundreds of times the same thing, you should definitely LEAVE THIS PAGE RIGHT NOW. I’m serious, if you start reading this tutorial, you might like it and could dangerously become way more productive. At the end of this read, you might even think crazy things like “pure CSS sucks” ! You’ve been warned…

EDIT: I strongly recommend reading or watching my talk about CSS Preprocessors and consider using Sass instead of Less.

If you’re a web developer or designer you probably faced this kind of situation before:
“I wonder if we should use a different theme on our website, can we try a blue one instead of the current green?”

2 possible answers:

• A pure CSS developer: “Damn… Can you come back in 15 minutes?”
• A Less CSS developer: “Sure! Wait just a second… Done, look!”

If you’re using pure CSS, even when respecting best practices, chances are that your answer will be the first one. Indeed, CSS is really far from being perfect. Hasn’t it come to your mind that some essential features are missing from a such widely used language? For instance, very basic things like variables.

Declaring a simple variable to store a color at the top of your stylesheet and being able to change the entire theme of your site by only changing this single variable would be pretty neat right? And what about all these repetitions each time you use CSS3 properties with vendor prefixes? Wouldn’t it be useful to have to declare that just once?

Well guess what, we’re gonna fix that! This article will demonstrate the power of Less, an enrichment of CSS using JavaScript. It adds tons of awesome features missing from CSS to make your web developer life so much easier. Trust me, once you’ve tried it, it changes the way you code your stylesheets forever and you’ll never come back to pure CSS!

What is Less?

A “dynamic” CSS

According to the official website, Less is a “dynamic stylesheet language”. I have a question for you now: How many stylesheet languages do you know?

Well except if you developed your own language and a dedicated browser to interpret it, chances are that you only know CSS. You might even have never thought about “What if there were another stylesheet language?”. Well Less is kind of one. “Kind of” because you develop using the Less language, but in the end, it’s compiled to pure CSS so that browsers can read it.

It’s also called “dynamic” because it enriches CSS with many common features available in most modern dynamic programming languages (like variables for instance). During the development phase, you’ll be able to use all those new cool features we’ll see in this tutorial and it will help you code way more efficiently.

Less compiler, which is written in JavaScript, will convert all your Less code into CSS to be interpretable by the client. When does this conversion happen? Well you have 3 options:

• On the fly in the browser with less.js,
• By using the lessc compiler via the command-line,
• With some fancy app like CodeKit or LiveReload.

Compiling in the browser with less.js

LessCSS.org has a big tempting button to download less.js. It is not a good idea. At least not for production.

Less.js will perform AJAX requests to grab your Less files, will then process those files to convert them into CSS, and finally inject the resulting CSS in the head of your document. It is extremely inefficient in terms of performance and you should never use it in production. Plus, if the user’s JavaScript is deactivated, well… it will just not work at all.

But if you just want to do a quick Less prototype or if you don’t have access to your usual development environment, less.js is perfectly fine!

Lessc and the command-line

You can also execute Less in your terminal. In order to do this, you will need to install Node.js on your development machine, and then install the Less module by running:

npm install less -g

You can then simply run the following command to compile a style.less file to style.css:

lessc style.less > style.css

Simple and efficient, I highly recommend this method. But if you’re really scared of the command-line, you can also use an application to do it for you.

Using an application to compile for you

Here is a list of applications that you can run when you are working that will manage the compilation for you. It is taken from my slides about CSS Preprocessors:

Some of these apps are free, others are paid. I’ve personally tried Codekit on Mac, which costs $25 and works really well.

Okay sounds cool, let’s start!

In this entire scenario, my goal will be to draw CSS shapes with different colors and decorations (cause it’s visual and I know you like it). Of course you can, and should, imagine how you can apply this to a real project. I highly recommend that you implement this example for real, because it’s the best way to learn. Honestly, you should really do it. I know you’re lazy but trust me, it’s worth it. So create an empty HTML file and here we go!

Our HTML file

First, here is the HTML we’ll be using:

<!doctype html>
<head>
	<link rel="stylesheet" href="style.css">
</head>
<body>
	<div class="shape" id="shape1"></div>
	<div class="shape" id="shape2"></div>
	<div class="shape" id="shape3"></div>
</body>
</html>

A little bit of basic CSS styling

Okay, we can finally start! First, create and open a style.less file. Then we add some CSS styles to our shapes in order to see them. We’ll set the default shape to a simple light blue square:

.shape{
	display:inline-block;
	width:200px;
	height:200px;
	background:#ddf;
	margin:20px;
}

Run lessc style.less > style.css to compile it and this is what your browser should display:

Nothing surprising here, just pure and simple CSS for the moment. But what if our example gets mucher bigger and we declared the #ddf light blue color in several different places in the file? Even with very good CSS best practices, we would still have to replace every single declaration of this color in order to try a new theme for example. That’s not convenient at all. Let’s use a Less variable to handle this.

Variables

Less variables can be declared and used with the @ symbol. You give them a name and a value, and then you can refer to the name of the variable anywhere in your Less file:

@lightBlue:#ddf;

.shape{
	display:inline-block;
	width:200px;
	height:200px;
	background:@lightBlue;
	margin:20px;
}

Pretty cool right? But it won’t be very helpful if we have to change the references to @lightBlue everywhere in the code. So we can for instance declare an other variable for our “default theme”:

@lightRed:   #fdd;
@lightGreen: #dfd;
@lightBlue:  #ddf;

@defaultThemeColor:@lightGreen;

.shape{
	display:inline-block;
	width:200px;
	height:200px;
	background:@defaultThemeColor;
	margin:20px;
}

With this example you can see our code becoming more modular and reusable. We just have to change the @defaultThemeColor to @lightGreen to apply the new green theme:

You can see a Less best practice here as well: declaring all the dumb constants at the top of the file, and then adding some logic.Talking about constants, be aware that Less “variables” are actually just constants, and their value cannot be changed once they’re set. So like Indiana Jones, “choose wisely”!

Mixins

Do you know how to draw rounds in CSS? You just have to set a very high CSS3 border-radius value. Let’s apply that to the first shape:

#shape1{
	border-radius:9999px;
}

Since we used CSS3, if we want it to work for as many browsers as possible, we must provide the alternative -webkit- and -moz- vendor prefixes versions as well. So you would do something like this is regular CSS:

#shape1{
	-webkit-border-radius:9999px;
	   -moz-border-radius:9999px;
	        border-radius:9999px;
}

We see something interesting here: three properties with the same value. Pretty boring to write right? No problem, Less to the rescue!

With Less we can define “mixins”, which are something comparable to functions in other programming languages. In Less they’re used to group CSS instructions. We’ll use a mixin to handle the boring repetition of border-radius declarations. Just like variables, you have to declare a mixin before calling it, with the . symbol this time:

.Round{
	-webkit-border-radius:9999px;
	   -moz-border-radius:9999px;
	        border-radius:9999px;	
}

#shape1{
	.Round;
}

You can then apply this .Round mixin wherever you want to make something round without having to declare the border-radius instructions again. That’s already cool, but it gets even cooler with parameters.

Parametric mixins

I now want to be able to create rounded squares, not just rounds. Let’s modify our .Round mixin to something more generic: .RoundedShape. Our RoundedShape mixin should be able to handle rounds and rounded squares, depending on the parameters used to call it. To declare parameters, use parentheses after the mixin name:

@defaultRadius:30px;

.RoundedShape(@radius:@defaultRadius){
	-webkit-border-radius:@radius;
	   -moz-border-radius:@radius;
	        border-radius:@radius;	
}

A parameter can be used similarly to a variable inside the mixin, and you can specify a default value for the parameter if none is given when the mixin is called. I also used a variable for this default value to keep the code reusable and generic.

So now that we have our cool RoundedShape mixin, let’s create 2 other mixins which will call it to create rounds and rounded squares:

.Round{
	.RoundedShape(9999px);
}

.RoundedSquare(@radius:@defaultRadius){
	.RoundedShape(@radius);
}

And then, all we have to do to is applying those Round and RoundedSquare to our shapes:

#shape1{
	.Round;
}

#shape2{
	.RoundedSquare;
}

Now refresh your page and… BOOM!

Since we haven’t passed any parameter to RoundedSquare, the 30px @defaultRadius variable is used, but we could also call it with parameters, on #shape3 for instance:

#shape3{
	.RoundedSquare(60px)
}

With just 3 lines to call our mixins, we have a whole logic handling behind the scene that makes our code super reusable and easily maintainable. How cool is that? We can go way further with mixins. In my opinion, variables and mixins are so powerful that it’s a sufficient reason to move to Less! But since Less offers tons of other amazing features, let’s take a look at it.

Operations

One other powerful feature of Less is the ability to use mathematical operations in your stylesheets (I agree it sounds boring, but it’s actually very cool). Let’s declare a @defaultShapesWidth variable to set the default shapes widths to 200px instead of hard-coding it like we used to:

@defaultShapesWidth:200px;

Now I want to add some borders to our shapes. Borders, whose size will always be 10% of the shape width. How would you do that in pure CSS? Yeah, exactly, you can’t at all! So thanks to Less, we can now do this kind of operation:

@borderSize:@defaultShapesWidth * 0.1;

You can add, subtract, multiply and divide values. So you might think “Yeah, but it only works for pixels right?”. Nope sir, it also works for colors!

@defaultThemeColor:@lightBlue;
@borderColor:@defaultThemeColor - #222;

We darkened the light blue color by subtracting 2 hexadecimal units to each RGB value. It can be confusing the first time. Just keep in mind that adding or subtracting #000 has no effect and #fff has a maximal effect.

And this is what we get when applying these new variables to a border rule:

border:@borderSize solid @borderColor;

The result is exactly as expected. That’s awesome. But the color operation we used was pretty simple. Adding a little bit of dark is easy, performing saturation operations is way more complicated and unintuitive. Fortunately, we can use some handy color functions to do that!

Color functions

Less provides the following color functions:

• darken() and lighten(), which add some black or white,
• saturate() and desaturate(), to make a color more “colorful” or more “grayscale”,
• fadein() and fadeout(), to increase or reduce transparency,
• and spin(), which modifies the hue of the color.

If, for instance, we want to make the border completely desaturated to get it’s equivalent on the grayscale, we would use the desaturate function like this:

@borderColor:desaturate(@defaultThemeColor, 100%);

And we can even use the output of a color function as the input of another:

@borderColor:darken(desaturate(@defaultThemeColor, 100%), 20%);

Which has the following result:

All color operations take a color and a percentage as parameters, except spin, which uses integers between 0 and 255 instead of percentages to modify the hue:

@defaultThemeColor:spin(@lightBlue, 100);

Nested rules

When designing a complex page using CSS, you often have to chain selectors to aim a particular element in the DOM, like this:

#header h1{
}

#main h1{
}

Depending on the container of the h1 elements, their style will be different if they’re in the #header or the #main section. This syntax is fine when you have a very simple DOM, but if you have to chain 4 or 5 selectors it gets messy and visually hard to represent the hierarchy of your styles. With Less you can nest rules inside parent rules to mimic the DOM structure:

#header{
	/* #header styles */
	h1{
		/* #header h1 styles */
	}
}

This can be a little bit confusing at the beginning but when you get used to it, this syntax helps a lot to visualise where is located the element you’re working on.

There is also a super handy way to use pseudo-classes (you know, those special selectors like :hover). Let’s say we want to change our shapes’ color when hovering them with the mouse, we can use nested rules combined with the & selector:

.shape{
	&:hover{
		background:@lightRed;
	}
}

This & symbol represents the current selected elements. It’s the equivalent of “this” in most programming languages. Very convenient! And here is the result:

Nested rules are pretty awesome, but there is a little drawback: since we use CSS syntax highlighting for our *.less files, many editors (including Eclipse) will go crazy and do some very bad syntax coloration with nested rules. If you can deal with broken syntax highlighting it will be fine, but for most of us, it’s really awful. The only thing we can do is wait for a proper plugin to bring a real Less support to our editors.

Personally, I only use nested rules for very simple one level nesting with few properties or for the &:hover thing. But it really depends on you.

Importing

Finally, the last thing I wanted to show you is how to import Less files. It’s a very good practice to separate your rules into different files instead of having a 1000 lines giant file.

Importing a file into another in Less is as simple as that:

@import “colors.less”;

You can even omit the .less extension and just declare:

@import “colors”;

So depending on your project, you can split your files in a relevant way. Personally, I like having separate files for:

• CSS Reset or normalization,
• Colors,
• Fonts and typography,
• UI Elements,
• The main styles of the page,
• …and any other relevant group of rules depending on your project.

You can take a look at the very good Twitter Bootstrap Github repository to see how those guys splitted up their files for a professional usage.

You may think that imports result in many unnecessary HTTP requests that will slow down the loading time of your page, and that’s true! But remember we’ll use the Less output as a new CSS. If we do so, we really don’t care about using multiple files, since at the end, everything will be concatenated into just one! So don’t be afraid of imports. They will really help you to structure your code.

Final Less code

Here is what the final code looks like (no import for such a little example):

/**********************
       CONSTANTS
***********************/

@lightRed:   #fdd;
@lightGreen: #dfd;
@lightBlue:  #ddf;
@defaultShapesWidth:200px;
@defaultRadius:30px;

/*********************************
   OPERATIONS & COLOR FUNCTIONS
**********************************/

@darkBlue: @lightBlue - #555;

@defaultThemeColor:@lightBlue;
//@defaultThemeColor:spin(@lightBlue, 100);

@borderSize:@defaultShapesWidth * 0.1;
@borderColor:@defaultThemeColor - #222; 
//@borderColor:darken(desaturate(@defaultThemeColor, 100%), 20%); 


/**********************
        MIXINS
***********************/

.RoundedShape(@radius:@defaultRadius){
	-webkit-border-radius:@radius;
	   -moz-border-radius:@radius;
	        border-radius:@radius;	
}

.Round{
	.RoundedShape(9999px);
}

.RoundedSquare(@radius:@defaultRadius){
	.RoundedShape(@radius);
}

/**********************
         STYLES
***********************/

.shape{
	display:inline-block;
	width:@defaultShapesWidth;
	height:200px;
	background:@defaultThemeColor;
	margin:20px;
	border:@borderSize solid @borderColor;
}

.shape{
	&:hover{ background:@lightRed	}
}

#shape1{ .Round }
#shape2{ .RoundedSquare }
#shape3{ .RoundedSquare(60px) }

You will also notice that you can use single line comments, which is a very simple but clever addition to CSS!

And here is the demonstration of this Less CSS example.

Conclusion

We’ve seen a lot of amazing features in this tutorial, and I hope it made you want to start using Less. I personally think Less is a real game changer for web development, and I cannot even consider going back to pure CSS. Less is like CSS5 in 2011!

There are still very interesting things I haven’t covered in this tutorial so if you’re interested in learning more about Less, you should definitely check the official documentation. Oh and by the way, since Less is also open source and hosted on Github you can easily get involved, report issues, or fork it. This great comment also gives some very interesting tips you should be aware of.

That’s all folks! Thanks for reading and feel free to share your thoughts and previous experience about Less in the comments section. I’d love to know if you enjoy it as much as I do!

After almost one week spent at BUILD Windows 8 conference in Anaheim, it’s time to let you know what’s important for you as Web Developers!

Windows 8 is the new major release of Windows announced earlier this year, with some big surprising news: Windows 8 apps use HTML5. It wasn’t easy to imagine how this was made possible since the whole interface looks really native. Now the conference is over, it’s way clearer and I will try to summarize what have been announced and what will interest you as Web Developers.

Before I start, just a little disclaimer: I’m not a Microsoft fanboy. I’m a Web Developer, I love standards and Open Source, I’m not paid to write what follows and Steve Ballmer is not pointing any gun against my head! That being said, my opinion about Microsoft changed a lot during this conference, and you should really turn your “MS sucks” mode off as well while reading this article. Done? Alright let’s start!

Let’s take the Metro

So, few words about those Windows 8 apps: They are called “Metro-style” apps, and are actually really pleasant to use. They’re responsive, fluid, beautiful, they’re almost always using squares and rectangles, because it’s Windows 8 theme, which is great for having a nice alignment on the grid. They can access Windows APIs like the file picker, the camera, the accelerometer, etc., have their own native contextual menu and settings (Android style), and they will be available on a Windows 8 app store.

To summarize: they’re pretty cool, fluid and functional from the end user point of view.

From a Web Developer point of view

The language is up to you

Windows 8 is built in a way you can choose to develop apps using 3 possible languages: C#, C++ and JavaScript. So MS fanboys and corporate developers will be able to continue using their stuff and will recycle their Silverlight skills, hardcore game coders can still use C, and us, Web 2.0 hippies can now write software with web standards. The 3 languages rely on the same WinRT (RunTime) layer, and have similar performances, so it’s really up to you to choose your favorite language. I will only talk about JavaScript on this blog however.

The IDE is *not* up to you

At this time, Microsoft’s Visual Studio is the only IDE to develop Windows 8 apps. Coming from the Open Source world and using mostly Eclipse, Intellij, Cloud9, and even Notepad++, I must admit that I had already enough different IDEs to deal with. But after I saw few folks at MS using it to code and run their Windows 8 apps super quickly I have to say that Visual Studio seems pretty powerful when you know it and I guess starting learning to use it is probably worth it. You (and I) should give it a chance.

Visual Studio 11 Developers Preview has some Windows 8 sample apps to do not start from scratch. Let’s see what we get when we create one of these sample apps:

A closer look at the sample app

Okay, so this is what we get when we run the generated new sample app:

This app has navigation, a contextual menu, 2 sliding regions and behaves like a regular cool and touchy Metro-style app, so that’s a pretty good and representative starting point.

HTML

So we chose JavaScript. But JavaScript’s role is about behavior right? What about HTML and CSS? Well you will be nicely surprised to see that a Windows 8 JavaScript app is actually really 100% made of HTML/CSS/JavaScript. So, what’s under the hood of this sample app? Well, probably not what you expect. Here is the corresponding HTML page:

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8" />
    <title>splitPage</title>

    <!-- WinJS references -->
    <link rel="stylesheet" href="/winjs/css/ui-dark.css" />
    <script type="ms-deferred/javascript" src="/winjs/js/base.js"></script>
    <script type="ms-deferred/javascript" src="/winjs/js/ui.js"></script>
    <script type="ms-deferred/javascript" src="/winjs/js/binding.js"></script>
    <script type="ms-deferred/javascript" src="/winjs/js/controls.js"></script>
    <script type="ms-deferred/javascript" src="/winjs/js/animations.js"></script>
    <script type="ms-deferred/javascript" src="/winjs/js/uicollections.js"></script>
    <script type="ms-deferred/javascript" src="/winjs/js/wwaapp.js"></script>
    
    <link rel="stylesheet" href="/css/default.css" />
    <link rel="stylesheet" href="/css/splitPage.css" />
    <script type="ms-deferred/javascript" src="/js/splitPage.js"></script>
</head>
<body>
    <!-- This template is used to display each item in the ListView declared below. -->
    <div class="itemTemplate" data-win-control="WinJS.Binding.Template">
        <div class="largeIconTextTemplate">
            <div class="largeIconTextTemplateImage" data-win-bind="style.backgroundColor: backgroundColor"></div>
            <div class="largeIconTextTemplateBackground">
                <div class="largeIconTextTemplateLargeText win-itemTextStrong" data-win-bind="textContent: title"></div>
                <div class="largeIconTextTemplateSmallText win-itemTextTertiary" data-win-bind="textContent: subtitle"></div>
                <div class="largeIconTextTemplateMediumText win-itemText" data-win-bind="textContent: description"></div>
            </div>
        </div>
    </div>

    <!-- The content that will be loaded and displayed. -->
    <div class="splitPage fragment">
        <header role="banner" aria-label="Header content">
            <button disabled class="win-backbutton" aria-label="Back"></button>
            <h1 class="pageTitle win-title"></h1>
        </header>
        <section class="itemListSection">
            <div class="itemList"
                    data-win-control="WinJS.UI.ListView" 
                    data-win-options="{dataSource: splitPage.items, oniteminvoked: splitPage.itemInvoked,  layout: {type: WinJS.UI.ListLayout}, selectionMode: 'none' }"></div>
        </section>
        <section class="articleSection" aria-live="assertive" aria-atomic="true" aria-label="Item detail">
            <header class="header">
                <div class="image" data-win-bind="style.backgroundColor: backgroundColor; style.backgroundImage: backgroundImage; alt: title"></div>
                <div class="text">
                    <h1 class="title win-contentTitle" data-win-bind="textContent: title"></h1>
                    <h2 class="subtitle win-itemText" data-win-bind="textContent: subtitle"></h2>
                    <p class="description" data-win-bind="textContent: description"></p>
                </div>
            </header>
            <article class="content" data-win-bind="innerHTML: content"></article>
        </section>
    </div>
</body>
</html>

It uses HTML5 elements, data- attributes, ARIA roles, everything looks pretty standard, but it’s radically different from a regular website. There are tons of proprietary stuff, even if it’s still HTML.

Disappointing right? Well at a first glance yes it is, but when you think about it, there is not many ways to do native apps with web technologies. Have you ever used jQuery Mobile? It’s more or less the same. Even a pure web browser-based experience like jQuery Mobile has those data- roles to declare the behavior of the app :

<div data-role="content">
  <ul data-role="listview" data-inset="true" data-theme="c" data-dividertheme="a">
    <li data-role="list-divider">Transition Effects</li>
      <li><a href="#" data-transition="slide">Slide</a></li>

So yes, it’s not really pure HTML anymore if you have to learn all these things. But it’s still way better than Objective-C right?

CSS

This extract of the CSS file is less surprising:

.splitPage .itemList .largeIconTextTemplate {
    width: 100%;
    height: 100%;
    display: -ms-grid;
    -ms-grid-columns: 124px 12px 1fr;
    -ms-grid-rows: 1fr;
}

.splitPage .itemList .largeIconTextTemplateBackground {
    -ms-grid-column: 3;
    overflow: hidden;
}

@media screen and (-ms-view-state: snapped) {
.splitPage .win-contentTitle {
    font-size: 11pt;
    line-height: 15pt;
}

.splitPage {
    -ms-grid-columns: 320px 0px;
    -ms-grid-rows: 132px 1fr 0px;
}

.splitPage .itemListSection {
    margin-left: 4px;
}

.splitPage header[role=banner] {
    display: -ms-grid;
    -ms-grid-columns: 44px 1fr;
    -ms-grid-rows: 1fr;
}

You can see that Metro-style apps use specific media queries and Microsoft’s proposal for a CSS3 grid system. The rest is pretty common.

JavaScript

Here is the real business:

(function () {
    'use strict';

    // Custom event raised after the fragment is appended to the DOM.
    WinJS.Application.addEventListener('fragmentappended', function handler(e) {
        if (e.location === '/html/splitPage.html') { fragmentLoad(e.fragment, e.state); }
    });

    function updateForLayout(lv, layout) {
        lv.layout = new WinJS.UI.ListLayout();
        lv.refresh();
    }

    function layoutChanged(e) {
        var list = document.querySelector('.itemList');
        if (list) {
            var lv = WinJS.UI.getControl(list);
            updateForLayout(lv, e.layout);
        }
    }

    function fragmentLoad(elements, options) {
        if (!WinJS.Navigation.canGoBack) {
            WinJS.Navigation.history.backStack[0] = { location: '/html/categoryPage.html' };
            var backButton = document.querySelector('header[role=banner] .win-backbutton');
            if (backButton) {
                backButton.removeAttribute('disabled');
            }
        }

        try {
            var appLayout = Windows.UI.ViewManagement.ApplicationLayout.getForCurrentView();
            if (appLayout) {
                appLayout.addEventListener('layoutchanged', layoutChanged);
            }
        } catch (e) { }

        splitPage.groups = pageData.groups;
        var group = (options && 'group' in options) ? options.group : pageData.groups[0];
        splitPage.items = pageData.items.filter(function (item) { return item.group.key === group.key }),
        splitPage.selectedItem = splitPage.items[0];

        elements.querySelector('.pageTitle').textContent = group.title;

        WinJS.UI.processAll(elements)
            .then(function () {
                var lv = WinJS.UI.getControl(elements.querySelector('.itemList'));
                lv.itemRenderer = elements.querySelector('.itemTemplate');
                updateForLayout(lv, Windows.UI.ViewManagement.ApplicationLayout.value);

                var details = elements.querySelector('.articleSection');
                return WinJS.Binding.processAll(details, splitPage.selectedItem);
            });
    }

    function itemInvoked(e) {
        var details = document.querySelector('.articleSection');
        splitPage.selectedItem = splitPage.items[e.detail.itemIndex];
        WinJS.Binding.processAll(details, splitPage.selectedItem);
        details.scrollTop = 0;
    }

// [...]

    WinJS.Namespace.define('splitPage', {
        fragmentLoad: fragmentLoad,
        itemInvoked: itemInvoked
    });
})();

Honestly I’m too lazy to dive into this code since this article is just supposed to be an overview. However you can see that this file often refers to WinJS library and to the Windows object, which are used to access low-level WinRT calls. If you don’t want to access any Windows APIs like the device, the accelerometer and everything, you can omit using it and do pure JavaScript, or even use another lib like jQuery, it should work fine.

Copy pasting your web app is a bad idea

Some of you might think: “So if it’s all HTML, CSS and JavaScript, can I just copy and paste my whole website or web app and run it as a Windows 8 app?” Well, yes you could, but the user experience would really suck because you wouldn’t take any advantage of using the Windows RunTime environment. No native menus, no region scrolling and zooming, no access to the device APIs, no access to the filesystem, and the most important, no Metro-style look and feel.

New platform = New market

Consider Windows 8 as a whole new platform like iOS or Android, but this time using web standards (and this is a big deal!). You still have to do specific development for yet another platform, but at least you already know the language, so you won’t start from scratch, and that’s good news. The other good news is obviously that Windows 8 app market is currently absolutely empty. So guess what? You just have to be the first to develop some stupid flying explosive angry rabbits game to get freaking rich. Remember that it’s always way easier to be the first…

Conclusion

Even if developing for Windows 8 has some drawbacks for a typical standard-lover Web Developer like me, I must admit that I’m pretty impressed by Microsoft’s move with Windows 8. They’re Apple-style slogan at this conference was “Windows, reimagined”. Well that’s exactly what they did. They really invested a lot to make Windows 8 development accessible to the web developers community. Good job.

“Metro-style” apps are also actually really pleasant to use and they can honestly compete with Apple and Google in the tablets battle. If Web Developers get charmed by developing on this platform, it could even encourage competitors to embrace the same strategy and it could really be the start of a “native web” revolution. And as usual, if you’re here at the beginning of a revolution, there are tons of potentially profitable opportunities to jump on.

So, how do you feel about developing for Windows 8?

I’m a 23 years old Parisian Front-End Web Developer, completely passionate about HTML, CSS and JavaScript. And believe it or not, I have a life too! I play music, like to party, travel as much as possible (oh, and by the way, I’m currently in a plane flying to Los Angeles, California right now, but more on that later).

Few notable things about me: I have a French blog about HTML5 and CSS3, which led me to write a book about HTML5 this year (it’s also in French, so good luck with that too!).

You might know me through another of my projects called Initializr. It’s a tool to generate a new HTML5 project based on HTML5 Boilerplate super quickly, you should take a look! It became the official custom builder of Boilerplate, so you can consider me as a contributor of HTML5 Boilerplate, although I don’t work on the core content.

Anyways, because of some of these facts, Microsoft invited me to California to attend BUILD Windows 8 conference, which will deal with HTML5 in many ways. And that’s why I’m now on this plane! This major event is the perfect opportunity for me to start a new blog, in English this time, and keep you informed about what is being said at this 4 days conference.

I will also post few updates about my Californian adventures since I will move to San Francisco next week, and will stay there for 2 months and a half. So I hope you will like this blog, if so, you can follow me on Twitter as well (no French spam, promise!).

Ciao ciao!