JavaScript developer with a passion for architecting and building client-side web applications. Several years wide ranging experience, from leading large front-end builds to getting elbow deep in test driven code on highly-interactive, data-driven apps.

Constant exploration has given me production experience in a wide range of technologies and I am always keen to try more. Most of all, I still get a kick out of turning ideas into beautifully functional, well architected products using lean, modular code and a text editor.

05. April 2014

Client vs server side rendering

One of the biggest problems with the front end web application stack is the lack of code sharing. This is particularly frustrating when it comes to rendering. We are forced to have two different rendering contexts; one for the server, one for the client. At first this seems reasonable - the server needs only produce one mammoth piece of static HTML whilst the client needs to be more dynamic and modular. While this will always be true, I believe we have overlooked some opportunities for code sharing.

The old web application architecture (Rails and Django etc) saw all the logic and rendering on the server. The client was little more than a web page renderer with full reloads between each view/action. This resulted in a clunky feel to the application which ultimately could not compete with a native experience.

More recent solutions like Backbone (which I have been using for 3 years or so now) sought to take advantage of AJAX to provide richer interfaces. Apps started to feel faster, slicker, and allowed for more complex visuals and interactions. Definitely a positive move. Unfortunately this richness came with the caveat that all the rendering takes place on the client. This has reuslted in many apps having slow initial render times and sometimes even the dreaded loading bars of the Flash era. Where we have gained we have lost elsewhere. Apart from anything else this clearly wastes the power of the server turning it into a dumb web server and data provider.

While I understand you cannot always expect complete render parity between client and server (the server shouldn’t be handling every single interactions via full page reloads and the client probably shouldn’t be juggling massive data sets either) I feel the black or white options we have available to us are too simple. A balance must be struck. We can do better.

What can we do?

As I mentioned in an earlier post I believe templating is a key area to look at. Templates can do more than just compile down to HTML. In fact we are seeing solutions like Ractive from the tech heads at the Guardian take bolder steps. They take an only slightly enhanced super set of Handlebars and give you back a nice two-way bound DOM, ready to roll. Everyone knows Google’s Angular gives us the same in a more declarative form, using the DOM as the template. Again another great step but both solutions leave the server out in the cold, rendering partial views and leaving the rest to the client.

To improve on this, I’d like to see templates treated like blueprints which could be used in one of the following ways; either

  • taking a model and producing HTML or
  • taking a model and producing a ready-bound DOM fragment or
  • taking some unbound DOM and binding it to an existing model

The first is the process we are familar with from the Backbone universe - producing HTML is still a cumbersome approach on the client but still necessary for the server. The second covers client side rendering as with Ractive’s techniques. The final approach would be massively useful when working with pages pre-rendered on the server (using the first approach incidentally). Angular has made a move towards the latter but expects templates in the DOM rather than the final mark up.

That’s a tall order. What would this require?

Templates would need to output HTML/DOM such that the data model bindings can be inferred using only the original template as a reference. Essentially templates that allow for reverse compilation.

Current languages, such as Handlebars, support features that prevent the original template being inferred from the HTML, as highlighted by blerik’s this excellent Stack Overflow answer. Using a subset, aligning to blerik’s rules, should give us a workable solution.

05. April 2014

Front end analysis

I’ve had my frustrations with front end application frameworks/libraries for a while now. None of them are quite perfect. I’d like to get down what I’d like to see and feel should be feasible.

  1. Self contained functional view components - pass them data, a template and a little view-model mapping magic and you’re off! On the server these return HTML, on the client they produce ready-bound DOM.
    1. Two-way data binding built in as standard on the client side.
    2. View logic defined declaratively in the templates.
    3. A simple way to map the data-model to the view-model.
  2. Sharable logic
    1. Routing - just needs to invoke a controller.
    2. Controllers - a controller defines a mapping of a layout, to functional components, to data. This mapping exists, in the same form, on both the server and client so it should be sharable.
    3. Models - business logic exists independent of any presentation format so should easily be sharable.
    4. Views - compiled as they are on the front end, not from some nested set of Jade templates but as the output of the controllers compilation of layout, model and view components.
  3. Templates that can be used as blueprints to both compile and parse HTML/DOM. This is a big one. The ability to compile HTML is the well trodden path of templating languages. The next step, as I see it, would be to define a template once and then use it to both generate ready-bound DOM and also to augment any existing unbound DOM with bindings. The latter is particularly important as it opens up the options of server side view rendering. Perceived load times would be shorter and the requirement of JS rendering would be removed entirely.