Skip to content

Server-Side support for HTML5 History API

In traditional Single-Page Applications for the web, routing was accomplished by updating the ‘hash’ section of the URL, using the ‘hashbang’ method.

So for example, if my route was setup as '/Feature/ComponentId', the resulting URL would look something like '!/Feature/ComponentId'.

This was great, because all browsers support updating the ‘hash’ without causing a full-page refresh, and additionally it works without requiring any support from the server, as the server would never actually see the ‘hash’ section.

This last point is important.

In modern browsers that support the HTML5 History API, routing can update the URL itself, without causing a page refresh.

So for example, the above route would actually result in something like '', without any need for a ‘hash’.

However, if I were to open a new browser window and enter the last URL, this would send a GET request to the server, with the complete URL. If the server is not configured correctly, it will look for such a resource and then either not find it altogether, resulting in a 404 error or result in the wrong resource being displayed.

Server-Side support for these URLs can be accomplished using two methods, one relatively easy and one more difficult.

The first method is to use URL Rewriting on the Web Server. This means that with a simple rule-based setup, your web application never actually sees invalid URLs, as they have been rewritten to point to a different URL altogether which will return the correct response. Apache supports mod_rewrite and IIS 7 uses the Rewrite Module. There are also open source projects available, or you can manually handle the request on the server and route it to the correct location.

The second method is to actually be aware on the server if the request is for a regular request or a partial request (with Ajax, for example), and respond with content to match. If I am not mistaken, GitHub uses this method when browsing a repository’s files.

While the second method is more difficult to implement, the first method has some disadvantages. You are relying on an external web server feature or library, which in some cases are unavailable. In other words, it might be easy to have a simple Rewrite rule, but you may end up spending time getting the feature setup on the server.

Another disadvantage is performance: your page may end up making multiple requests for HTML and data just to display the requested feature.

97 Things Every Programmer Should Know

I have read 97 Things Every Programmer Should Know, a book that is part of a series from O’Reilly, all containing 97 things focused on different High-Tech occupations.

The book has contributions from many programmers on different aspects of programming, each a short article that can quickly be read in just a couple of minutes. You will probably find at least one contribution from an author you know.

The full text of the book is available, online and free, in an O’Reilly wiki, where you can read all the contributions.

Check out this InfoQ article describing the book and the series.

sRequire – Synchronous Module Definitions

In the last post, I mentioned the Structure library and how I liked it for being simple and small, while providing structure to a javascript application. However, I also mentioned a number of issues I felt were missing.

I started making some changes to how Structure works, but while doing so I realized that what I was actually looking for was a way to declare modules and their dependencies, which could then be used later in my code.

In the end I decided to use the same define and require methods, just like in AMD, but without any dynamic loading – all files need to be added manually to the HTML page. This is only really useful for small applications that have a few files. If you have more than about 10 files, you should probably be looking at a full AMD library, or better, performing optimizations at build-time, such as combining and minimizing files.

The API is kept as simple as possible:

 * Used to define a module, providing a name and optionally any required dependencies.
 * @param {String} name The name of the module
 * @param {Array} dependencies An array of dependency names
 * @param {Function} factory The factory that defines the module
function define(name, dependencies, factory) { ... }

 * Used to request a list of dependencies, before running a callback.
 * @param {Array} dependencies An array of dependency names
 * @param {Function} callback A function that is passed the required dependencies
function require(dependencies, callback) { ... }

The code, provided ‘AS-IS’ is available on GitHub. At this time there is no documentation or tests, but I will be fixing that as soon as possible.

In my next post, I will describe my usage of sRequire, and additional requirements that required extending sRequire.

Structure – A tiny JS project for structuring you JS code

From the ReadMe on the Structure page on GitHub:

Structure is a small library that encourages developers to better organize their client-side JavaScript code. It offers a single global variable under which an application’s code should be contained, the ability to create namespaces under that global variable, and the ability to register reusable modules.

I like Structure for its simplicity: it provides structure to an app in just 82 LOC. Structure lets you register modules with a name, which is then attached to the global variable. It also provides a way to change what that global variable is.

What you might find missing from Structure is everything else you know and love about AMD libraries like RequireJS:

  1. It wont load anything for you – you need to manually insert the <script> tags, in the correct order
  2. There is no dependency management – you can just access anything you need from the global variable
  3. Most importantly, it is only for declaring reusable modules

To elaborate a little on the last point:

In AMD, there are two methods: define is used to define a reusable module, optionally providing a name and dependencies. require is used to load one or more dependencies, with an optional callback that will receive the dependencies once they have completed loading.

By using require with a callback, you can write code that depends on reusable modules while not creating any new global variables or functions. In a fully AMD-based application, this can mean that (almost) no javascript is ever run in the global scope, which is a best-practice for medium to large applications.

In my next post, I introduce my slightly more advanced version, which supports the scenarios mentioned above.

Syntax Highlighting on a blog

So I plan to show a lot of code here and was looking for a plugin to handle the syntax highlighting for me. Well, as it turns out, doesn’t allow you to use plugins, however they have syntax highlighting built-in, probably because it is very useful to so many bloggers.

See Posting Source Code for the source article.

First of all, if all you want is one or two words of code, inline with other content, just use the <code> HTML tag around the desired text.

Here, I’m just going to use the built-in capabilities and describe the settings used, mostly for future reference.

In order to display code with syntax highlighting, use the [sourcecode] tag.

var example = function (args) {
    return[], arguments);

This is the most basic, just setting a language attribute to “javascript”.

For a one-liner, use the light attribute, to avoid toolbar and line numbers.

    element.addEventListener('click', clickHandler, false);

Here is some C# code:

namespace WordPress.Syntax.Tests
    public class SyntaxTests
        public const string Language = "csharp";

        public SyntaxTests()
             Console.WriteLine("Syntax Highlighting using {0}", Language);

Another important attribute is wraplines, the default is true:

Without wrapping:

var longVariableName = getResultFromLongNamedFunction(longPaameterName1, longParameterNamme2);

And with:

var longVariableName = getResultFromLongNamedFunction(longPaameterName1, longParameterNamme2);

Future Posts List


This is a list of stuff I am working on and learning about, that I will hopefully post about in the near future, in no particular order:

  • Chrome Extensions – Tips for better productivity and debugging
  • IndexedDB – The specification and Chrome
  • AMD, RequireJS and Chrome Extensions
  • Structure – A tiny JS project for structuring you JS code – View Post
  • jquery-research – A jQuery plugin for doing research-as-you-type
  • GitHub and GitHub for Windows – my impressions

I will update the list with links to the posts as I publish them.

I have more things to write about, such as JS templates, Web Components and more, but I need a better idea of what I want to say of the subject.



This will hopefully be a blog where I will document the different things I have learnt and worked on.

A little about me:

I have developed software since I was around 17, and started working professionally at 24. I am very passionate about all things software, always keeping an eye and ear out for new technologies, frameworks and ideas that keep coming out.

I have developed applications in a number of languages, using a number of technologies, and been active on both front-end teams and back-end teams. For more details, please see my LinkedIn profile.

Well, wish me luck and happy coding.