Why Meteor will kill Ruby on Rails

Meteor Logo

Why Meteor?

I remember first getting started with Rails back in 2004, it was a "magical time" - of course I remember get questioned at least once a week why someone would want to use rails. My answer was always the same, developers love the framework because they can build things faster in a way they enjoy to work. I've been working with Meteor full time for over a month now and I wanted to give some answers to "Why Meteor" because I am hearing the same question a lot.

Hook-ups are hard

When a client asks us to build an app, they are really asking for a fully interactive web app that utilizes javascript to get rich client interfaces. The problem is when you start with something like rails then javascript was an afterthought - something bolted on long after the technology was built. Sure, you can spend a few days getting something cobbled together that is workable and a developer could be happy working in, but rails was developed and became widespread because it adopted convention over configuration. I've worked on 4 different backbone apps, large and small, and not one of them has been setup the same way. If everyone has a custom setup of Node.js, angular, etc - how will we ever be able to quickly jump in on a project?

Meteor solves this issue by putting together a "cutting edge" set of packages that work together in a well defined manner. jQuery, Handlebars, Node.js, websockets, mongoDB, and DDP form a well orchestrated tool that allows us to build things quickly and efficently. We've launched client MVPs in 3-4 weeks time, something that likely would have taken me 4-6 weeks for previous clients using rails. Before you go crying "Legacy apps" on me, just bear with me while we walk through this. We spent over two days recently getting angular.js and rails wired up for a brand new project, that comes out to 12-16 hours spent on configuration instead of writing actual code to build an app that does something the customer wants. When you are paying quality developers somewhere between $100 and $200 an hour to build something great, those 12 hours are costly if you only have $20-25k to plunk down on building a product. In the worst case scenario you just dropped 6% of your cash on getting one framework to work with another. The cost for this doesn't even include hooking up something like websockets to get real time two-way communication applications going. All of this comes for free in Meteor.js.

Context switching sucks

Can we all agree that multi-tasking is hard and there is some loss of processing power/time when you switch from task to task? Yes, we are all smart programmers capable of knowing and working with multiple languages - but we lose something when we have to switch from Rails to Angular and back again. If I am spending time writing a Backbone app or an Angular app that needs to interact with data in the rails app, I have to spend time writing that controller in rails, which is in turn accessing the database through ActiveRecord. It is just plain inefficent to make my brain switch back and forth, thinking about validating data in the front and back end.

What if you could spend your time in one language and one framework? Built from the ground up to operate together effectively and easily! I don't mean to sound like some sales stooge, but it really is eye opening to see a framework that can achieve these claims in a functional way. I realize that Meteor has a way to go in certain areas of discovery like testing and scaling, but having watched ruby on rails do it once before, I feel confident that it just takes time and small efforts to get these pieces right.

Ra-ra-ree, kick them in the…

Let's be real, Javascript is the #1 language on Github and for good reason - it runs everywhere. Java promised this too us back in the 90's, but it was too big and bloated and hard to work with (caveat, I only used java in college), but there was clear interest in seeing an unbiquitious language that worked everywhere. Of course by everywhere, I really just mean in the browser - all of them. Being the most popular language comes with it's advantages, the chief one being lots of people know the language.

Recruiting becomes much easier to pull off when you have a large group of people to choose from. I guarantee you could hand off a Meteor project with a decent structure to any JS dev and they could pick it up and get running on the app pretty fast. This is very important in the world of software development, overly complicated structure makes it harder to switch teams and maintain development velocity. No one really likes feeling locked into one person or one team, especially if they found out going a different direction could give them way more options later.

Designers love it

You remember that commercial for Life cereal and Mikey - "He likes them, he really LIKES them". I've worked with many designers over the years, helping get Ruby set up on their machines, training them the folder structures, conveying how the asset pipeline works, introducing them to SASS/Less, etc. I always like to do the last part, because I've yet to find a designer who didn't like SASS or Less better than writing regular ole' CSS. I haven't yet spent less than multiple days helping and re-helping a designer when they get started on rails. It is a complicated structure and takes time to wrap your head around it all.

I kid you not, our designer (who we introduced to rails first) has really take a shine to Meteor, so much so that he spent time creating a "Meteor boilerplate" starter repo that we use as a starting point for all our new Meteor apps. On top of that, he got tired of being forced to use rails for our own company website, so he ported the entire design to a new Meteor version and got the site about 40% functional before he needed help. I'll let that sink in for a minute…

A designer didn't need a developer to put any code or structure in place to get started - this has been the holy grail for a long time, in my mind. Teach a man to fish, etc.

White gloved solution

Meteor has drawn pieces from many frameworks, and I think that has led them to create a superior solution - they've learned from everyone around them to see what works and what doesn't. The event handling portion of Meteor reminds me a lot of backbone and how they handle events, one of the few things I loved about backbone! The packaging solutions remind me a lot of NPM and Ruby Gems, I love that people can write code once and reuse it and Meteor brings that same ease with it. They blend all these ideas with cutting edge technology like websockets and MongoDB to really speed up the development process.

So why Meteor?

These bold claims are the views of myself and are fully backed by everyone at Differential.

Because when someone who is in the "alpha wave" of early adopters makes a bold switch and trumpets loudly for something, you will likely see that gamble pay off later. That is not to say that Angular, Ember, or Backbone won't stick around or be huge - they have their places in life, mainly supporting existing apps that want rich interfaces. Every developer and new entrepreneur should legitimately give Meteor a serious look. Your time to market will be shorter and developer happiness will increase 10-fold.

Looking to get started with Meteor? We can help you build a meteor app!

Comment on Hacker News