Exactly. I was disappointed that there was absolutely no attempt to look under the hood of this thing. That would actually be an interesting blog post to read: like a look at the system, pre-installed programs, the difference between it and PearOS, whether you can install whatever software you want on it, whether there is a package manager and, and then of course some wireshark captures.

Docker was written off with the caveat of, "but I still use it for my local development environment". I feel like that's a huge advantage for Docker. Maybe I missed it, but all the other mentioned technologies didn't try to solve the problem of providing a consistent development to production environment. That said, Docker still has a lot of problems around making the dev-to-production experience smooth, especially for teams that use OS X for development and run Linux in production.

That's always been the least interesting thing about Docker for me, since Vagrant solves that particular problem much more completely, and has been around a lot longer than Docker has.

Using Docker for this forces you to do things the Docker way, whereas Vagrant is much more OS and CM agnostic. (CM is configuration manager: you can use puppet, chef, ansible, shell, salt or even Docker: whatever you're already using in production).

My current web app is composed of 10 database hosts and 11 REST APIs. 21 VMs would blow my laptop's resources away while 21 containers run just fine. For me, that makes Docker a lot more attractive for local development. Also, Docker removes the need for a CM if you are into stateless deployments.

We've had a lot of vendors, like Firebase, approach us at Poll Everywhere over the years. Despite how awesome they are as people, a company, and the huge problems they solve, I've always avoided it getting in bed with any vendor for something that I think is fundamental to a realtime web application. As a result, we developed our own realtime web framework at http://firehose.io, open sourced it under the MIT license, and made ourselves immune to these circumstances.

We use hamlc and Backbone.js in our stack. This lib looks like it will simplify a lot of that.

I have a few questions:

1. Its interesting to see JS events specified in the template (e.g. `%a(onclick=@doSomething)`). Is there a way to specify that in the JS/model?

2. Does "Observable" mean that the value is updated when the model changes, when the DOM changes, or both? Could all of the attributes of the object passed into the template be observable by default or would that incur a significant performance penalty?

When is the DOM updated? Are the changes performed as soon as they are observed or are they queued? Does Hamlet implement some kind of "virtual DOM" for diffing or does it sync DOM and model directly?

Looks very nice, just this weekend I looked at some frontend frameworks, including Vue, Mithrill, Ractive and React and found some issues with them all. Hamlet would fit my use case very well, I think. One thing I'd like is more technical details on the main page - not how it "looks like" compared to other frameworks, but how it does its thing (compared to other frameworks).

If you haven't already, check out http://fontcustom.com/. Its like Font Awesome, except you drop a directory of SVGs at it and it generates a ton of fonts. The project could use help in a few areas including: