How I Came To Use Handlebars

"If it's worth building, it's worth over-engineering" - Unknown Developer

Building something great...

It sometimes seems like the best course of action is to follow the path of least resistance. As a developer, however, that's almost never the case. Often when you're programming the best way is to make a thing is done right and for that it makes sense go down the most difficult track you can imagine. This isn't necessarily over-engineering but rather working smarter not harder

So it is that we recently identified a need for a project my team is slated to work on and I decided it presented opportunities to both learn something new and potentially give back to the community. After a couple of meetings and some discussion, I felt it would be worth it to try out HandlebarsJS as a lightweight templating solution.


I read through some documentation, and did a bit of testing locally and it seemed like a winner. Then fellow Team Lead Nicholas put up a GitHub repository of some of his own testing. That saved me the trouble of committing my own limited testing and gave me a jumping off point, because I didt' want to stop there.

I forked his work and set about building up a NodeJS / Express server using Bower for dependency management and GruntJS for task running. It's all publicly hosted on GitHub and much of my development has been done on the incredible codio, about which I intend to dedicate an entire post in the future.

That's a lot of links...

Since then, Nicholas added some fun functionality on the server side to get some random content from the HipsterJesus API to replace the static Hipster Ipsum I'd included initially.

It's come a long way in a few days, but...

Why all of this?

The idea here is to present a proof-of-concept for, what I think, is a pretty common scenario. Here's the need. You have to display a page filled with dynamic content that comes from various sources, I'll call them widgets. The content may come different parts of your code base, or it could come from external services. In addition, these widgets may have dynamic content that may be updated from whatever its sources and you will want to update the display for the user when that happens. To top it all off, you may want to change the layout / structure of the page in some way, whether based on changes in content or by user interaction.

The answer to this, in my mind, is to build up the data on the server side as present it and some kind of small template partials in a request and then watch for changes on the server and only update the content that needs to be updated.

This seems, on the surface to be pretty straight forward, but there are a lot of moving pieces. So, we set out to work on making it all work.

As of this writing we're better than halfway done with the infrastructure. We have a front end skeleton and then you can make a request and have the content retrieved, parsed and then displayed. On the sever side, some of the content is dynamically pulled in and sent back to the client on request.

The (remaining) TODOs are:

  • Storing the data locally to present something to the user right away while awaiting the response of the initial request.
  • Adding some action on the server side to change the data at interval.
  • Add a listener via sockets / long polling to check for changes on the server side and request the updates when needed.
  • Add methods for processing responses for updated content on the front end.
  • Host the final result of this little project.

Check out the issues to see progress since this posting.

What's next?

While the server side code isn't exactly relevant to the project that spawned this little adventure, the practices and front end code very much are. As a matter of fact, much of the JavaScript will be pretty directly tranlastable, and the concepts from the Node stuff will tranlaste pretty well to the PHP.

This means that it's worth our time to finish this thing up and hopefully anyone else in the world das a similar need will find our work useful.