Fog Creek

Reactive Templating Demo with Hamlet – Tech Talk

In this Tech Talk, Daniel, a Developer here at Fog Creek, gives a demo of Hamlet. It’s a simple, but powerful and open-source, reactive templating library that he co-created.

About Fog Creek Tech Talks

At Fog Creek, we have weekly Tech Talks from our own staff and invited guests. These are short, informal presentations on something of interest to those involved in software development. We try to share these with you whenever we can.

Content and Timings

  • Introduction (0:00)
  • Demo (0:58)
  • Multiple Bindings (1:32)
  • Inline Events (3:04)
  • Dependent Functions (4:12)
  • Checkbox and Disabling Inputs (5:33)
  • To-do List and HTML Elements (6:41)

Transcript

Introduction

I’m going to talk about a tool I built for client-side templating. If anyone’s familiar with the client-side templating landscape, there’s a lot of tools coming out over the past five years and even more every year and every day as JavaScript relearns things that computers have done. We want reactive interfaces. We want to make the web more powerful, more like a desktop application. So now, we have to relearn and recreate all the tools that we’ve had for 30 years, but we don’t have them on the web because it’s new. So hopefully we can learn from that and make some pretty good tools that do a good job, and this is my take looking at the landscape from a couple years ago, building a tool that met my needs very well.

Demo

So, let’s see. I guess you can see this little website here. It’s got this little guy. And I have this demo. Just trying to make it big so you can see. It kind of bumped the CSS a little. The main thing in this tool… you’re familiar with HTML templating libraries, I think Mustache is the classic one, where you threw a bunch of curly braces in and you basically just interpolate string values into your HTML.

Multiple Bindings

That’s okay I guess, but in real life you usually have specific attributes that are bound to specific values. You’re not going to cross over a tag barrier with some arbitrary strings. You’d rather have a little more structure. So given that, you can get a very nice domain-specific language. It looks exactly like this. It has… These are HTML element labels, or HTML element node types. Then these are the attributes, and I’ve got a shortcut at value syntax. So if I drag the slider, it adjusts all of them simultaneously. So I think this is what a lot of the libraries like Angular, some of the other bigger ones are going for with their… Knockout especially, with reactive data binding.

This model is a CoffeeScript object. It can just be a JavaScript object. You don’t have to use CoffeeScript. The one key attribute is this observable function, which you give it any value and it provides a way for the UI layer to have bi-directional binding. So everywhere in this template where value is listed, it’s bound to this observable object. That way the UI knows how to automatically wire it up for you. It’s the cleanest I’ve seen. So here’s that same example.

Inline Events

You can also bind events on buttons or any other element. You can just click it and it pops up. The event is just an arbitrary JavaScript function. This is the CoffeeScript syntax… basically, you’ve got a button, you want the click event to be this function. This is actually going back to the style of HTML of 1996 where you just throw inline handlers on everything. These don’t have to be implemented as inline handlers, but it’s just visually… the original way they did it made a lot of sense. They’re keeping the HTML simple.

Today, if you do have a very complicated app, you wouldn’t necessarily want to inline everything. But since this is a template and not actually HTML. It’s pretty good because this doesn’t actually do an inline function right here. It binds it using JavaScript, but it has the same value of readability, so you know what is the click action on this button. You can just read it right here.

Dependent Functions

So here, you’ve got dependent functions. This is starting to get some of the interesting stuff that this library does. It automatically tracks your dependencies for you, even through regular functions. So you have a first name, which is observable, and a last name, which is observable. You can type in whatever you want, and it automatically updates the composite name in the template. A composite name is just a function derived from these two observable values. This “at” syntax is CoffeeScript for this thought. Usually in JavaScript you have to be a little careful about using this, because based on the binding or the context in which your function’s executed, this could be different. But the runtime view layer makes sure that within your model, this is always your model, so you can basically ignore that here.

And so we see in the binding, the value is just bound to the observable, so it’s bi-directional so that when you update it, it updates the input value, and that filters back into this simple function and updates the composite value that is bound here as well.

Checkbox and Disabling Inputs

And it also just has simple checkboxes. Basically, all the HTML elements work fine.

You can toggle a value from ‘true’ to ‘false’. So, ‘disabled’ here is a way to disable a button in HTML. And by having this disabled.toggle, so it’s an observable of a boolean value, we can in real time swap it back and forth. And then, when the button’s active, you can click it, when it’s disabled, you can’t click it.

I see a lot of other libraries have really complicated ways to do stuff. But a lot of them get farther and farther from the basic HTML itself, like what is actually happening on the web page. To just put the attribute value in using a jQuery selector to do the attribute, but this is actually slightly cleaner even than that. And then with jQuery, if you want to do bi-directional binding, you have to set up a bunch of observers or listeners. It gets complicated fast.

To-do List and HTML Elements

This is the classic ‘to-do list’ app. You can see this is the full app right here, it’s just a template and a model. Other apps that are ‘to-do list’ are a hundred lines. The backbone is probably a hundred, some other new ones I think are shorter.

The add function… It just pushes the item that you create into an observable array. So the observable array proxies all the standard array methods, and then it makes… it triggers the change event, when you call any mutation that is on the array. So you can almost pretend that items is just a normal JavaScript array, as it shows up here. You can enter it using each. Then it just displays it. And because it tries to keep the exact same API as the built-in arrays, it works very seamlessly and allows you to make a very simple application using all the tools you already know.

It’s like, “oh, I have an array and I want to listen to change events, I’ll just make it observable,” and you’re basically done. You throw that into your template and it works the way you would expect. It also can run your HTML elements directly. This equal sign…

So it’s called Hamlet because it’s derived from Haml and Ruby. I think seven years ago that was popular for a little bit, and it’s been influential on a lot of other tools like Jade, or any of these SASS, LESS, these HTML and CSS meta-languages that compile down to HTML and CSS. They take away a lot of redundancy, a lot of the error-prone nature… you have to match your tags and close them and open them. Easily make mistakes. I guess the editors… the app can do that, but here you can just edit in a text area and build a to-do list. So I think it comes out slightly ahead in some respects.

That’s it for my talk. If you do have any front-end code and want to get into interactive user interfaces, I think it’s at least an interesting prospective. I hope that you consider Hamlet the next time you need to have a reactive website. Thanks.