Hamish Rickerby

Technology Consultant & iOS Developer based in Sydney, Australia

Meteor

| Comments

A couple of days ago I received an email from meetup.com about meetups that I might be interested in. Usually this is full of crap I don’t care about, like mothers groups or salsa dancing, but this most recent mail featured an intriguing group called “Meteor Melbourne - a better way to build apps”. So, I looked into it.

Meteor is a framework based on node.js that allows you to write responsive, reactive, real-time web applications in javascript on both the client and server side. I’ve always considered javascript as a toy language - I think this opinion comes from my first interaction with JavaScript waaaaaay back in the late 90’s (I think it was somewhere between ‘96 and ‘98), when all it was really used for was alert boxes and tic-tac-toe implementations. However, I’ve recently been doing a lot of work for clients with Parse and their “cloud code” functionality, taking some logic out of mobile apps and running it on the Parse servers - and you use JavaScript to do this. They promoted use of Promises, and I’ve been doing a lot with RAC in iPhone apps, so this functional style is something I’m familiar with and like. I also have a friend who is helping a mate out on a startup, who is looking at some serious “enterprise” functionality implemented with server-side javascript, so I thought it was maybe time to seriously look at this thing too, and I checked it out.

Amazeballs. Meteor is MAGIC. Don’t believe me? Watch this screencast.

I think the magic for me comes from the real-time (well, super fast at least -> sub second synchronization) nature of the system, and the automate shuffling of data between the server and client to synchronize/update pages with no specific actions on the developers part. The built in support for packages is also really tidy, although having to use a 3rd party packages system (Meteorite and Atmosphere) for more modern versions of some of the core packages (eg, bootstrap-3 vs bootstrap-2) seems a little undesirable.

It’s super fast to get set up (1 line install, 1 line to start), and this includes server, database, sync between client and server. Want user authentication? Two more command line hits (1 for a UI, 1 for a login provider package), and 1 line to get the UI template built in. Amazingly productive.

Where I see huge potential for Meteor is in the mobile space. Having a web app, which automatically pushes changes to a mobile device is super powerful. With the current state of mobile apps you typically need to poll for changes to data, unless you build your own data sync solution or rely on something like iCloud to push changes around for you (haha, yeah right). When I’ve done this sort of thing in the past with Parse, I’ve actually gone as far as abusing the Apple Push Notification Service to actually trigger a mobile device to re-query a web service to retrieve new data as APNS is the only push mechanism available. Having a service that reliably notifies a client when data changes server side, with sub-second speed, solves a whole bunch of problems for app developers.

This is the tech stack that I’m now looking at using for my small business productivity tool, and I’m hoping that mobile sync works just as well (and fast) as the client-server sync does. Next up is a small proof of concept to test this out.

I haven’t been this excited about web development since I saw DHH’s web app in 15 mins rails screencast in 2006.

Oh yeah, I went to the meetup too. Nice job meetup.com

Comments