Just a collection of random memory dumps.

Jekyll for Client Side Web Apps

29 Jul 2013

One of the problems with building a static, client side HTML app is that by it’s precompiled nature you are going to get lots of duplicate HTML and files that are almost identical. This is becoming increasingly noticeable with my Budget Management Application that I’m working on, which I want to be able to run anywhere regardless of connectivity. Having recently rewrote my website in Jekyll (purely because I love it when a site loads so fast) I made the decision to give it a try for client side apps too.

Jekyll is one of the more mature static site generators, but I would assume that most of what’s here will apply to other static site generators too.

It didn’t actually take that long to move the site to Jekyll as all I had to do was take the majority of the shared part of my application and make it a layout, then just moved the differing parts into separate files. It took me less than half an hour to do in total. The advantages you get by using a static site generator are pretty good too:

Automated pipeline with plugins.

Due to the fact there is a lot of plugins for Jekyll, there are lots of little things that can make coding your app a lot simpler in a lot of ways. A good example of this is the jekyll-less plugin, which will automatically build less files for your project. If you’re looking for something more powerful you can use the jekyll-asset-pipeline, which also has the power to compile CoffeeScript and compress and optimize Javascript. There are even localization plugins that allow you to easily manage different languages for your app such as jekyll-localization.

Less HTML to work with

Things like navigation, messages and common forms can be abstracted out of the solution using Jekyll template engine Liquid, which also allows parameters for certain things. For example this form element for a bootstrap input field:

<div class="form-group">
	<label for="exampleInputEmail">Email address</label>
	<input type="text" class="form-control" id="exampleInputEmail" placeholder="Enter email">

Could become:

<div class="form-group">
	<label for="{{}}">{{include.label}}</label>
	<input type="{{ include.type }}" name="{{}}" id="{{ }}" placeholder="{{ include.placeholder }}">

Which then could be called in any HTML with something as simple as:

{% include input.html name="email" type="text" %}

Delve into the template engine even deeper and you could maybe even do things like client side validation, password strength meters or forms that update with Ajax given certain parameters. Even more simple additions would be very useful, like having a prebuilt list of countries or currencies.

It helps make code more modular.

One thing I find about bootstrap is I always end up with a lot of Modal’s sitting at the bottom of my HTML files, using Jekyll I have been able to move these into separate files which I can swap around or easily update whenever I need too. If my application was a lot bigger than it is (and it will grow as I continue to work on it) it will keep the code much more maintainable.


So I’ll probably be doing most client side applications and even just static websites this way in the future, the amount of flexibility and features it provides for such little set up time would make it a waste if I didn’t, and my applications will hopefully be built much more quickly and be much more stable because of the better maintainability and code reuse.

comments powered by Disqus