PIcking Your Javascript Mobile Framework: Part 20 – Thorax

The tag line of the ThoraxJS.org (yes, .org) site reads, “An opinionated, battle-tested Backbone + Handlebars framework to build large scale web applications.“

I mentioned that our mobile needs don’t particularly require large scale web applications, but at the same time it’s hard to deny a candidate that has done well enough in the Todo challenge.

The fundamentals of Thorax, as the tag line states, are Backbone and Handlebars. Additionally, Thorax on its down did pretty terribly in the performance challenge, so we have to add one more dependency, Lumbar. Since Lumbar is “with” Thorax (as they both come from WalMart Labs) it’s not a stretch to think that most projects will use both.

Reading on the home page of the site, it is quite obvious that Thorax is meant for traditional web site browsing a la Amazon or WalMart.com. Indeed, there is an extra section on server-side rendering, where part of the content in the template is injected by the site. We have no use for that in our mobile app, of course, but that shouldn’t disqualify the project.

Downloading and installing Thorax is pretty straightforward. You npm install yo and generator-thorax, the you tell yo to generate a new thorax project:

yo thorax my-test-app

So far, that’s analogous to cordova create my-test-app. There was one snag where yo froze up at some point after pages of downloads and installations. When I hit Enter, it complained about an invalid choice and wouldn’t move forward until I typed ‘1’. I have no idea what ‘1’ was, but it worked and gave me something.

Once you enter the my-test-app directory, you can run grunt. Thorax tries really hard and fires up Firefox (I guess the default browser?) and runs itself in it. The page that comes up is a long explanation of how Thorax works and what to do next. I had the option, though, to have it generate an empty app, a Hello, World! app, or a Todo app.

The Todo app, I’ll confess, is ugly as sin. That’s particularly horrifying, because Thorax needs all of 9,513 files (not a typo) to make that happen. At least, that’s how many I found after running grunt on the directory I created. The demo Todo, incidentally, is not only ugly as sin but also has less functionality than the TodoMVC app (it has no routes and seemingly doesn’t allow you to get rid of the todos).

Incidentally, when I ran my tried and true test of total file size,

find . -type f | xargs du -bc

I got the result 1553681. I had problems parsing that because it was so extraordinarily huge, but a quick confirmation (adding the ‘h’ argument to du) confirmed: the demo Todo costs you 1.5M.

That’s remarkable, because that’s at the far end of the TodoMVC examples. Interestingly, the Thorax example there is much smaller, clocking in at 616k. Almost a third the code base and more functionality to boot!

(The Thorax/Lumbar combo is much more expensive, occupying 1.2M. This is, of course, with all dependencies and compiled files at this point. The pure code base is much smaller.)

Back to our TodoMVC sample app, the code has some surprises in store. For one, getters and setters are explicit. For instance, the code that toggles the ‘completed’ state of a todo item is as follows:

As you see, it’s not just that there is no implicit getter/setter. There isn’t even an explicit setter (as in a function by that name). Instead, you have to use the save() function and send it an object with the correct values. That is a little odd – I would even go as far as saying it is weird. Most other frameworks would use logic like this:

toggle: function() { this.completed = !this.completed }

Frankly, given that this is a (mobile) web application framework, there is no reason why it wouldn’t offer a toggle() function automatically on its boolean variables. That’s really irritating, because the purpose of a framework, from my perspective, is precisely to eliminate boilerplate code. Thorax doesn’t think that way, and I am not sure why.

You can definitely use Thorax if you like, but you seriously have tons of options that do the same, just better. What breaks the heart is that, clearly, the WalMart Labs people poured a lot of love and work into it. They made it really easy to install, easy to use; gave us default apps to create. I would wish the same kind of effort from other players in the field.

But maybe they just have to go back and decide to put more effort into the framework itself and make it do automatically things you automatically expect.