Meteor is F***ing Awesome
And other reasons it’s a great web and mobile option.
Meet Meteor, “an ultra-simple, database-everywhere, data-on-the-wire, pure-Javascript web framework.”
I first stumbled across Meteor in mid 2012, just after they announced their fundraising success. At the time, Meteor was very far from production ready. I’m talking “no security at all” far from ready. Because of this, I took a quick look and decided to pass. Fast forward to today and they’re about to release the third version of their rendering engine, security is baked in, there’s a robust third party package system, and more. About a month ago I decided to give Meteor another look and boy am I glad I did. It is f***ing awesome, and fundamentally different than what you’re probably working with right now.
Below are a few broad reasons I’m excited about Meteor.
One Language to Rule Them All
Javascript. Javascript. Javascript. You’ve heard it before. It’s “cool” when the language on the client is the same as on the server. That Ember/Angular + Node app you’re building is going to be that much better because Ember and Node are javascript. Except that when you get into it it doesn’t really matter that they’re both the same language. Your ember/node app will look and function very similarly to your ember/rails app. You’ll still be writing code on the client that communicates over HTTP with your server code.
Meteor blurs the line between client and server, and actually takes advantage of the fact that it’s all Javascript. Methods are functions that can be invoked from the client, the server, or both. With Meteor, you’re actually sharing big chunks of code between the client and server. While it’s possible to do something similar using ember/node, it’s difficult enough that most people don’t do it. This really changes how you build things. More client/server sharing = less code = less work and fewer errors.
The Form Element
Let’s take an HTML element we’re all familiar with: the <form> element. A user fills out a form, presses submit, and the browser sends a request with the information to a url defined in the form element. The application responds at that url, usually creating or updating some resource. This pattern is used in every conventional web app (rails, django, ember/rails, angular, express, plain old vanilla html, etc).
In meteor, there is no url to post a form to. You simply catch the submit event in Javascript and call a Meteor method. The Meteor method reads/writes directly to the database, and then returns the result to the client. Furthermore, since both the client and server can have access to methods, the client can simulate the method call and update the app before the server has responded. This is part of how latency compensation in Meteor works, and it makes apps feel extremely responsive.
Meteor & Mobile
When I started with Meteor a month and a half ago, I knew I wanted to do something in mobile with it. At the time, there were only a couple of Meteor apps in the app store, and very little documentation on how to get going with Phonegap. I tried several solutions, and ended up using a modified version of this tool. I’d been meaning to build a local chat app since June, so I gave it the first name I could think of, and out came Ralph.
Benefits
- You only have to learn enough Objective-C to use Phonegap. Otherwise, it’s all Javascript.
- One codebase for Android, iOS, etc (thanks Phonegap).
- Hot code reload. You don’t have to go through the Apple approval process every time you want to update the app, and you don’t have to maintain old versions. Everybody is instantly updated the next time they open the app.
- Realtime by default. Mobile apps tend to have stricter feedback requirements than web apps, so it helps that everything in Meteor is realtime by default. The built in latency compensation helps as well.
- DDP. It minimizes the amount of data the app sends through the phone’s connection, which helps when the connection is poor.
- Since it’s just a website, you have access to all the amazing web tools out there.
Issues
- It’s not native, so certain things don’t quite “feel” right. For example, input elements and fixed positioning have a host of issues you must work around.
- In general, I’m not sure how well Meteor will scale. The guys behind Meteor are working on a more scalable implementation, and it should be in place before 1.0.
And there you have it; some of the reasons I’m excited about Meteor. I’ve learned a lot over the past month building Ralph, and can’t wait for the upcoming Meteor 1.0 release.
I plan to write a follow-up post with more specifics on how to get Meteor running on mobile, and a few Meteor specific mobile tricks I’ve learned over the past month. In the meantime, if you have questions about Ralph or Meteor, connect with me at @marbemac and @RalphApp.
