Picking a JavaScript Framework – My Journey to Meteor

This article is motivated by my current day-job project. I have to come up with a decent and cheap solution to manage project requests. Before I delve into the perils of deciding for a JS framework or a set of libraries some words about what I try to achieve. That is very important in my opinion. For different purposes exist different best JS frameworks. I will from now on use the term ‘framework’ interchangeable with ‘set of libraries’. We (me and the systems users) already agreed to some extend to the basic workflow and requirements.

• Everyone (in our local intranet) can sign-up for an account.
• You need an account to create project proposals yourself.
• You can make the proposal public our keep it private for now.
• If you decide that the proposal is ready you can turn it in and have to make it public therefore.
• The decision maker can now examine the proposal and eventually accept it.
• The decision maker also can reject it.
• The requestor gets it back with some hints of what might be missing or wrong.
• The decision maker might also decline it. Meaning the proposal is dead.
• The requestor gets information why that’s the case.
• Anonymous users may view all public project proposals regardless of their progress.

Besides this functional must-have requirements exist a few others. For example, as above already mentioned, simple and fast to develop and without license fees. Additionally I want the resulting app to look gorgeous, to respond really quickly as well as to be simple and straightforward. I made some mock-ups with Moqups to get a better understanding of how the UI should look like. Here is a picture of the main functionality.

Beware this is an unfinished draft, doesn’t present the whole picture and at the same time displays some additional experiments (the star-rating). I was just going so far as to come to a sound understanding of the main building blocks and the overall layout. The page will look quite similar for different roles. Different roles require other groupings, a different filter for the projects and other buttons on the project summary headers. I omitted the actual project proposal form. Since the details regarding the input fields are still a little unclear.

How it should behave is clear: you should be able to click on every projects summary header to open up the details right in place. The other projects and headers simply move down. You can edit every value in place by double clicking it. Assumed you have the appropriate rights to do so, of course.

Well I looked around and stumbled upon many different frameworks and approaches. I found some mainstream solutions as well as some niche players which might fit. Here are the obvious main players: AngularJS, Meteor, Ember.js, Derby, Backbone.js, Knockout, batman.js. All of them follow a quite similar route: provide client side middleware for binding, templating, routing, dom manipulation – in short providing the pillars for a model-view-something design. Some take it a bit further, others quite not so far and need additional libraries to complete the picture. The two extremes: Meteor exists even on the server side and manages persistence. Backbone provides barely more than binding and custom events.

Besides those at present very popular HTML, JavaScript, CSS embracing frameworks exist different ones that are agnostic to those technologies. For me it always felt wrong to squeeze the obviously more document centric technologies of the web into something, that might resemble the foundation for a full-fledged application. It is quite a stretch, to be good at both.

One thing that might change the situation was introduced in HTML5: the canvas. You can draw in it using JavaScript. At it’s basis it is like classical low-level desktop drawing. But there already exist UI toolkits, similar to GTK or Cocoa, that speed up app-development to a reasonable level. The existing frameworks might not yet be that sophisticated, but they are definitively more the way to go for real apps than HTML-bending. I looked at morphic.js. It is part of the programming learning environment Snap! / BYOB from Berkeley. I like Morphic, since I first stumbled upon it, in Pharo Smalltalk. Unfortunately it looks like a remnant of the 90’s. Besides that, I have to support IE8, which knows shit about canvas.

But there exist even more approaches. A few years ago I made a web-app using ZK. This is a server-side framework allowing to write the whole app in Java as well as in some own XML markup. But it feels somewhat slow and heavy and the licensing might become a problem. And it is Java! There might be other server-side frameworks out there, but I decided to take the client-side approach and provide simple REST/JSON services on the server side.

I stumbled upon Cappuccino and Objective J. The later being the Objective C for JavaScript instead of C. Since I’m looking at Cocoa programming for a private project, it sounded like a good syntheses. You describe the UI similar to a native OSX app. You even can use Xcodes Interface Builder to some extend.

I decided to take a closer look at Cappuccino. But it began horribly. The installation was nightmarish. After a lot of trial and error, I did get it running, though. On my Mac as well as the Ubuntu machine, which would become the target environment. Whereas the latter was even easier. I don’t remember all the steps. It simply worked after the fourth time reinstall from scratch (and source) and rebooting or something. I made a project stub using the ‘capp’ command:

capp gen -l -t NibApplication ProPro

Opened the project in Xcode and started designing the UI in the Interface Builder. The whole time I had some bad feeling and some questions were nagging at me: Can this really be that easy? Did they really cover all available Cocoa controls? How will it look and behave in the browser? What about different windows? Do I make multiple Nibs? I tried to find some more information, but get stuck relatively soon. Before going any further I decided to “compile” the “MainMenu.xib” to a “MainMenu.cib” with:

nib2cib ProPro/Resources/MainMenu.xib

and examine the results. At this point I also had a login-HUD-window designed and choose the controls simply by their look. Well that didn’t work out so well. Buttons were drawn differently. Sizes didn’t match. I used boxes to group things together, which resulted in a bad look, because of all the shadowing stuff. But the worse was, that the windows were drawn as moveable windows. My intention was, that the main window would fill the whole browser area and the HUD window would be hidden and later used as a pop-up. I couldn’t repair it.

I made a new project, copied only the inner view over and redesigned the user interface: different buttons, no boxes but custom views. Here is the look of it in Xcode as well how it looks in the browser:

Well, both versions look quite similar, but neither I would consider gorgeous. I would rather go with the mock-up from above. The OSX look of things don’t seem to fit very well in a browser window.

I opened the projects “index.html” file directly in the browser. On my Mac this works only in Safari. On Ubuntu it works in Firefox, too. But even this half ready, no latency, simple example took some time to load. Maybe there are ways to speed things up, but for me it was too much then. I was frustrated and began the framework-search anew. Not totally from point blank, since I found other options already, mentioned above. So I decided to take a closer look at those popular HTML-bending frameworks. Starting with the most intriguing, at least for me: Meteor.

The installation was a breeze. One command:

curl https://install.meteor.com | /bin/sh

Entering the sudo password and everything was there. It downloaded and installed all dependencies (mongodb, npm, node.js) in the background. I created a sample meteor app with:

meteor create ProPro

It doesn’t do much, just generate three files: ProPro.html, ProPro.js and ProPro.css. You can instantly run the application through issuing “meteor” in the apps folder. It sets everything up and responds from now on to http://localhost:3000. The clou is, you can change everything while the server is running and see the result immediately in all browsers pointing to the apps address.

Besides this goodness, that lets my old Smalltalkers heart feeling warm and home, there are some really valuable packages you could simply add to the project. CoffeeScript for example. Entering the command:

meteor add coffeescript

is all that is necessary to use from now on “.coffee” files instead and besides of “.js” files. Meteor compiles those CoffeeScript files on the fly to JavaScript. There are even packages that implement basic user management. Besides CoffeeScript and the user management packages, I decided to make use of the following well-known JavaScript libraries, that are also available as Meteor packages: Bootstrap, Less and Handlebars.js.

I decided to develop the app in small steps, focussing at first on the user interface and pushing the server functionality and interactivity in the background for now. I made progress quickly. Many things I tried without looking at the documentation worked straight away. So I guess I’m quite attuned to the Meteor-way. Here is a screenshot of the current UI (almost no functionality, though).

There were some bad moments also. Especially to mention is the dreaded soft-tab vs. real tab problem, when working with languages that infer structure from spaces. I wasted a few hours to hunt down a problem, whose source lay in the different editors I used and their default setting regarding tabs. But on the other hand, the braces saved typing and the much cleaner look of CoffeeScript compared to JavaScrapt is worth the hassle (in my opinion).

You can find the Meteor project here. It is far from finished right now. It just reflects the mockup from above and provides some minimal functionality. I might omit, change and add a few things for the real app, running at my company. Many things for them might not be of general interest, though. I will only include things that I developed in my spare time and that are somewhat general applicable.

To end this post here come my killer features of Meteor (in no special order):

• Easy to setup and get you running.
• Allows for continually modifying your app. Live updates.
• Quite good documentation.
• Relying on modern quite established technologies.
• Easy to change and extend.
• Persistence out of the box.
• User Management included.
• Easy to grasp how it works.