Seven Principles of Meteor.js

On my previous post, I mentioned how Meteor.js is one of the most sensible frameworks for creating single page applications.

I read a few books and got started easily within a few hours. If you are interested, Packt Publishing has a “buy one, get one free” deal which ends tomorrow. Both Instant Meteor JavaScript Framework Starter and Getting Started with Meteor.js JavaScript Framework were helpful in understanding the framework.

Of its many advantages, I like how it’s easy to install and start a Meteor.js application.

One line to install nearly everything:

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

It’s easy to create an app and learn the examples:

$ meteor create --example todos
$ cd todos

Assuming you haven’t started MongoDB, it’s usually not a problem because you only need one line to start processes needed for your app:

$ meteor

Compare that to Ruby on Rails development. Most of you wouldn’t think starting Rails is a problem but I do.

I usually create an alias to start everything I need and it’s never too simple even with an alias. I don’t like everything to start whenever I boot my computer. That just an insensible default in my case.

You will know what makes Meteor.js different from other frameworks by reading the seven principles.

Data on the Wire

“Don’t send HTML over the network. Send data and let the client decide how to render it.”

Insensible code that include HTML on JSON output is not a fault of any framework. In fact you can just add handlebars on your Ruby on Rails application and that should sort things out. It’s used as a default in Meteor.js.

One Language: JavaScript

Initially daunting for someone who uses Ruby on Rails and who believes in JavaScript minimalism, but it makes a lot of sense just as writing an app entirely on Ruby or Python makes sense.

Database Everywhere.

“Use the same transparent API to access your database from the client or the server.” This just means there’s one way of getting data from any table. This is how you define a list of items on either the server or client:

Lists = new Meteor.Collection("lists");

Latency Compensation

“On the client, use prefetching and model simulation to make it look like you have a zero-latency connection to the database.”

Prefetching is faster than it is in Rails naturally.

Full Stack Reactivity

“Make realtime the default. All layers, from database to template, should make an event-driven interface available.”

This is the behaviour needed by some people I talked to. They don’t like to keep on clicking on buttons. The user should just type and see results quickly.

Embrace the Ecosystem

“Meteor is open source and integrates, rather than replaces, existing open source tools and frameworks.”

You can use Node.js libraries for most of the things that Meteor.js lacks.

Simplicity Equals Productivity

“The best way to make something seem simple is to have it actually be simple. Accomplish this through clean, classically beautiful APIs.”

Nothing is so simple. But it’s not a reason to refute the last principle. There’s no reason to not get so excited about creating something. I just found it common for people to get so excited at the inception of a project or on the process of learning and then give up at some point. But that’s Psychology and it’s not related to programming. That’s often because they don’t consider all of the details or see the big picture or both.

I have more to say about Meteor.js and most of it have to do with going against certain defaults and recommendations but for now, this will suffice as a clear statement that Meteor.js is worth considering for some projects.