Most of the JavaScript frameworks I’ve seen suffered from over-configuration and exposing too much detail. Error reporting is usually obscure, there are too many ways to accomplish the same thing, and there are no clearly defined conventions.

And then came Meteor, a “full-stack JavaScript platform for developing modern web and mobile applications.” It works right out of the box, provides a nice command line tool with readable output, and clearly establishes a “meteor way” of doing things.

Installation

On Arch Linux, Meteor is available with an AUR package:

$ yaourt -S meteor-js

Here you get the first surprise: 150Mb to download a JS framework?! What? A lot is bundled in, including large number of npm modules. An interesting approach, but does it mean Meteor has everything needed for development?

Tutorial

OK, let’s check out the official tutorial.


meteor create simple-todos
cd simple-todos
meteor npm install
meteor


Hey, that started Mongo for me. Looks like developers are getting lazier. I bet the next step will be to bundle Docker directly into the framework.

Now the app is running at http://localhost:3000/, and when I change source files, the page is reloaded automagically. Cool.

Then I continued with the tutorial, tinkering with it here and there and adding support for to-do items and images.

When thinking of the pros and cons of this framework, I focus on its architecture. Here are some of my impressions.

Use of MongoDB

Mongo deeply influences Meteor’s design. Generally, all the advantages and disadvantages of that database apply here.

Mongo is schemaless, which is both good and bad.  The fact that you don’t need migrations eliminates some of the hassle but forces you to either tolerate inconsistent data or take care of updating it somehow.

Another key point is the lack of transactions. Yes, this approach supports atomicity, but the sad truth is that once you have implemented complex business logic, you will suffer from not being able to conduct real transactions. It is possible to go without them, but this will bring additional development cost.

Having to use Mongo query language takes time to adapt to, but it is very powerful.

Websockets

By default, a Meteor app does not expose an API. instead, it uses a WebSocket connection to monitor data changes. This feature allows user-facing content to display updates as soon as it is changed in the database.

This sounds great but you will inevitably run into all the normal WebSocket issues: network topology problems, firewalls, and performance issues.

Error reporting

Though Meteor has come a long way from the Express way of articulating problems, you still can get a giant, horribly misleading trace in your console, even if your only fault is misspelling a template name.

Native app

Meteor advertises native iOS and Android support, and the app you build in the tutorial does work in an Android simulator. But I haven’t noticed any significant benefits, compared to running the website in a mobile browser.

Nevertheless, the ease of creating native apps in Meteor is impressive.

Opinionated Framework

Meteor is very opinionated. It provides you with the “right way” to do things, and if you follow it, everything goes smoothly. A good design principle states that simple things should be easy and complex things should be possible. Meteor definitely sticks to that principle, which is a sign of a good framework.

A good example is account management. Need users to be able to sign in? Just drop in a package. Facebook authentication? Another package. And since you can customize it, it’s hard to find a situation when you have to implement sign up/sign in functionality yourself.

Testing

Tests are essential, and in Meteor they are a piece of cake to write and run.

Event handlers work for dynamically created elements

Meteor includes the callback handling the new task form submission:


Template.body.events({
'submit .new-task'(event) {
// ...
},
});


It is attached to the form element that we have in our body.html template:

<form class="new-task">
  <input name="text" type="text" placeholder="Type to add new tasks" />
</form>

But what happens if that element was not present at app load time? Just load the app and create another new task form using the developer toolbar.

And yes, the form submission still works and creates a new task. Awesome!

File uploads

Due to the presence of Mongo, the recommended way of handling files in Meteor is to use GridFS. I used the meteor-file-collection adapter, which allows to manage files almost as if they were an ordinary collection. It’s fairly straightforward, but for a real-world application you would probably want to set up a separate upload endpoint.

Conclusion

What I can say about Meteor?  It’s astounding! In my opinion, this approach to web applications has a bright future. Of course, this comes at a cost: the resulting application is heavy, and when things go wrong, you have a hard time exploring the framework code. But that is just the other side of the coin.

Meteor can be a good choice for both prototyping and building small-to-medium general purpose websites. Using Meteor? I’m in.