Beginning My Meteor Journey, from a Rails Guy
Sep 6, 2014
Frustrated with not having a good javascript framework in my toolbelt, I think I’ve found a home with Meteor.js
Client-side Javascript
As a long time full-time Rails developer (since 2006, Rails 2.0) I’ve dabbled with client-side javascript frameworks. The reasons to consider it are many, and I know i’m behind the times by not yet serously adopting one.
Sure, a bit of JQuery and Ajax here and there doesn’t necessarily justify using a framework on the front end, but at some point the javascript starts to get more complicated and gnarily than expected, and I start to regret it. At that point it’s either too far into the project to justify a major refactoring. Or, since I havent picked a javascript framework as my “own” yet anyway, I’d have to stop what i’m doing to tool-up.
That said, I have looked at Backbone, Ember, and Angular. The promise (and reality) of single-page apps are… um… apt. I like the responsiveness, you dont have to keep going back to the server for html updates, which generally feels more natural in today’s world where most people use the web on mobile devices (there’s no “reload” button on apps!).
Then there’s the concept of reactive programming, which means your web page automatically updates whenever data changes that the page depends on. No more writing extra code to regenerate DOM objects. Cool stuff.
Last year I began to zero-in on Angular as my reactive framework of choice, and worked through a few tutorials, books, and toy projects. I even wrote some blog posts about integrating Angular with Rails, and did a lightning talk at the BostonRB Ruby meetup group. But I’ve yet to use it in a real project. Maybe I still will (especially where there’s a Rails back end).
Discovering Meteor
Then a few months ago I learned about Meteor.js. Well, maybe “re-discovered” is a better word, as I first heard about it a couple years ago on Ryan Bates Railscasts, but didnt give it much thought at the time. Then I saw a site that picked Telescope, a discussion forum app written in Meteor, instead of Discourse (a discussion forum app writen in Rails), and wondered why, and looked into it.
Although Meteor is pre-1.0, which means the project is still very young and subject to disruptive changes (to any apps you’re developing), it has stabilized alot in the past year. More important, Meteor also comes across as a distruptive technology in a paradym-shifting, Christensen kind of way. (I won’t toot that horn here, you can go over to the Meteor site and/or google it).
So I started listening to the Meteor Podcast (I listen to alot of podcasts, btw), a news show about happenings in the Meteor community. I had no idea what they were talking about. (And unfortunately they explained little about what they were talking about (!), as if everyone who tuned in were already insiders). But the enthusiasm was obvious, the size of the community larger than I expected, and the innovations rapid. It feels like the early days of Rails where things happen very quickly because there’s a strong shared vision of What is, What isnt yet, but What it can become…
So I looked at the Meteor official resources, read a couple books and worked along the tutorials. First, David Turnbull’s Meteor Tutorial, then Tom Coleman and Sacha Greif’s Discover Meteor (including the “microscope” project tutorial). Then I spent Labor Day weekend binge watching hours of EventedMind screencasts. I subscribed to a number of Meteor newsletters, and followed a bunch of guys on Twitter (bookmark this if you’re interested).
My First Meteor App
Then I adapted the microscope project to my first Meteor project (my first single-page web app as well), http://sandlightning.com , a simple app for my family’s videos (and potential MVP demo). I departed from the tutorials by using CoffeeScript, Jade, and Bootstrap-3. I deployed it to Meteor.com (free hosting). And it works! Yaay!!
During the process I got caught in the 0.8.3 to 0.9.0 upgrade (and then 0.9.1), all within a week! where things broke and I had to really step into the community to find out what went wrong and how to work around it.
My app does not really need to be reactive per se, and I could have just as easily done it in Rails. Actually it would have been easier to do in Rails since thats what i know and could just be a simple CRUD app. But i wanted the experience and decided to start simple, and map from what i know.
Moving Forward
So where does that leave me? I have a few upcoming personal projects that can benefit from Meteor. I have a lot of existing personal and professional projects that will remain in Rails, but if i ever rewrite them, could benefit from Meteor.
Let’s assume I want to do more one-page apps, reactive programming, and mobile apps. Most of my personal project sites are fairly simple so it just seems an extra step, an extra layer, to write the site in two parts: the server side API (rails) and the client side framework (js). DHH’s solution of rendering everything on the server just seems backwards. People say Javascript will (is) dominate the web. Ember and Angular still have my attention.
Meteor is missing some (a lot of?) nicetites you get in Rails. Like ActiveResource, SimpleForm, opinionated naming conventions, ActiveRecord relations (e.g has_many_through). But Meteor at its core takes care of many of my pain points, like Ajax, client-server data sync, reactive updates. Holy crap, I think I’m willing to put up with the missing niceities in exchange for these core benefits?? (in anticpation the rest will come as the framework matures).
In fact, working in Meteor compared with Rails, feels more hands-on, if you will. (Maybe I should be comparing it to Sinatra). It’s kind of the same feeling i had when i stopped using Cucumber and used Capybara directly in RSpecs. It removes unnecessary layers while still handling the dirty work. Does that make sense?
I hate moving away from Ruby, it’s my first love. But if I use Coffeescript with Meteor, that’ll take some of the syntax pain away. We’ll see.
Now, if only “Rails 5" were to do what Meteor does, use DDP (Distributed Data Protocol) for bi-directional JSON data exchange based on WebSockets, rather than HTTP, and let you write Ruby for both client and server i might move back!! ha ha (have you seen Opal the Ruby to Javascript transpiler?!?)
Edit: yikes! just discovered Volt framework — ruby on both server and client (using opal). Did they read my last paragraph or what???!!!
Originally published at vaporbase.com.
