Simple SPA for old-time programmer (and maybe newer one)

Note: Somehow it is hard to keep a regular schedule on blogging. Mostly because I have nothing worthwhile to write

Single Page App (SPAs) is the rage nowadays. Everyone seems to do SPAs left and right, whether it fits their application or not. As with anything concerning web development, there are billions of tools, helpers and frameworks to choose from. Most popular one are Angularjs (1/2), Emberjs, React and Vuejs.

There are older one like backbone, etc. but we won’t be discussing them todays.

Personally, I have tried Angular 1, and I absolutely hate it. I have tried Emberjs, and while I am neural about it, it looks (and perhaps is) complicated. I have played with React briefly, but honestly the complexity of setting up React went over my head. (That was before there are standardized tools to generate a react project). Vue.js, however, is my choice right now. Even though I know nothing about webpack/browserify, I could follow tutorial and cook up a simple application within a few hour.

But that is another story. While I like Vuejs, and I agree that other SPA frameworks has their place in community, many of them require setting up some kind of preprocessing pipeline (be it simple grunt/gulp script or webpack/browserify). I like webpack, honestly, but all of those tools are complex and required time to learn. Today, I will talk about the SPA technique I used the most in my small to middle project. It is very simple to use, and is quite obvious once you get to know it. A lot of people may have already considered this technique, but I find that many programmers nowadays find this new to them.

Old times developer should be able to grasp this technique quite easily, because we will be using jQuery and Handlebars. You could probably throw in ES6 via Babel. but if you goes trough the hassle of setting it up, you might as well as just use one of the huge frameworks.

Now, in standard SPA the main component is router which are bind to a template. State management is also important, but I find that there is no single ideal state management. In small to medium project, I find that just have one big global variable for states is sufficient. As long as you namespace yourself (For example, state specific to user route are stored in GLOBAL.user.*), it is pretty managable to a scale.

Template definition I normally use a handlerbar way:

<script type="text/x-handlebar-template" data-name="{your-template-name}">
    <!-- whatever -->
</script>

And the application script, I put

TEMPLATE = {};
$('script[type="text/x-handlebars-template"]').each(function () {
    TEMPLATE[$(this).attr('data-name')] = Handlebars.compile($(this).html());
});

In case you don’t know jQuery, that basically just compile all Handlebar template into TEMPLATE map.

Now we have to write the actual router logic. I typically go with simple one, for example:

Transition = {
    // Define transition
    user: {
        login: {
            template: 'login',
            attach: function() { /* Blah */ }
        }
    }
};

ROUTER_STATE = {
    current_route: {},
    target: $('#content')
};

function transitionTo(route) {
    if (ROUTER_STATE.current_route.detach)
        ROUTER_STATE.current_route.detach()
    ROUTER_STATE.target.html(TEMPLATE[route.template]());
    route.attach();
    ROUTER_STATE.current_round = route;
}

$(function() {
    transitionTo(Transition.user.login);
});

This is just an example. You would put your jQuery binding inside atach() and cleanup inside detach(). You could integrate it with history library (that change hash portion of the URL, etc. It could be extended on the fly, as you need it. IMO, it is perfect for small to medium one-off project or when you really need to cook up something really quick.

I hope this is beneficial to someone our there :) And if you have no idea what I am talking about or how to actually weave it into actual application, I think you would better off just use one of the framework. This is intend to be an idea to be toyed with, not a tutorial.