Meteor.js is a cohesive development platform, a collection of libraries and packages that are bound together in a tidy way to make web development easier. It builds on ideas from previous frameworks and libraries to offer an easy way to start a prototype app, but it gives you the tools and flexibility to build a full fledged production app. There are libraries like Tracker and Blaze that the Meteor Development Group has built specifically for a reactive front-end experience.
This article is meant to show you what makes up Meteor and what it would take if you went and built your own framework instead.
The command line tool is the glue that creates all of this. The command line tool has everything you need if you want things like Coffeescript or LESS compiler support. It also has the package system built into it:
The server is a Node.js app built with certain libraries in place to make the communication happen over DDP and EJSON to the front-end:
The communication layer is the real magic that binds the client and server together. EJSON is used to serialize and deserialize data moving across the wire via DDP.
The Cordova integration is built into the command line tool and the package system. A simple
meteor add-platform ios will get you started. The cordova app will be compiled into an app, but the hot code reload will bring over new code and cache it on the local device and load that next time instead.
The Cordova interface is just built upon the same libraries as the browser, listed above.
I cannot begin to comprehend the overall business value of this integration. The ability to build your app for three platforms (web, andriod, iOS) from one codebase will be of immense value to developers and businesses.
I mentioned ISOBuild above, but I wanted to reiterate how much power can come from a package you add to Meteor.js. The package system has a few 'core' packages that can easily be added, like
accounts-google. These packages are little libraries built to take of things like login and authentication, oauth authorization, etc. You also have user created packages on Atmosphere, like
iron:router, which has become the defacto router for 99% of all Meteor.js apps.
Remember those commercials from the 80's and 90's that would show you how many bowls of cereal you would have to eat to get the same amount of vitamin totals that a bowl of total would give you?
I've had the fortune to watch (via github and conversations) a friend try to build a complete meteor.js replacement with just Node.js and it has given me some deeper insight to what it would take to not rely on Meteor.js. Here are some things you would need:
On paper that doesn't look so bad, right? I think most people underestimate how much time is spent getting all of the above to play nice in a way that works for your app.
In my original "Why Meteor will kill Ruby on Rails" article I talked about how it would take up 12 hours to get an alternative built - I was way off. Anecdotally, it seems to be taking more like 80 hours to get everything hooked up in a functional manner. Those 80 hours don't even account for hitting bugs or weird edgecase interactions, such as the oAuth library not working correctly. We are talking about real measurable value for a startup with limited resources.
I had a very interested interaction, with a buddy of mine that uses Rails, the other day. It highlights the common thing I hear about Meteor.js - Meteor is great for Rapid Application Development. He brought up maintainability in the conversation, which most people view as the trade off point between startup speed and speed later in the app development cycle.
Friend: 'Show me how maintainable a Meteor.js app is over a long period of time'
Me: 'I've worked on plenty of poorly written rails apps'
Me: 'Writing maintainable apps is about good practices and standards for people to follow. These things are established through learning, sharing, blogging, etc.'
Friend: 'Well building a blog in 15 minutes was a cool demo way back when'
Me: 'Sure, rapid application development feels like a less business value because it has been around for a long time and kind of fallen to the back of the interesting topics around rails'
Friend: 'yeah, starting fast is not in itself a bad thing. I think I've come to not value it nearly as highly as I used to.'
Me: 'Fine, stop using ruby on rails, go build something from scratch just using various libraries. See you in 4 weeks :)'
Maintainability is something we should all strive for in our applications, but to be clear I don't think that is a focus on Meteor.js, Ruby on Rails, Ember, etc. Maintainability comes down to strong culture and solid dev practices instilled into the core of your business. Perhaps some of these values can spill out of a framework or a platform, but I think it comes down to the organizational level to implement the right practices in the end. I believe there is strong business value in getting started fast and relying on a cohesive well-tested platform to do it.
I think the world as a whole is just starting to see the bigger picture in terms of business value that can be derived from Meteor.js. We have already gained a lot just from the 0.9.2 release that integrated Cordova directly into the platform.
I think one of the reasons this platform is so strong and worth learning is the fact that a group of smart people have gathered together to create a company and community that is pushing this technology forward - and with $11 million reasons in the bank, they should have some time to do it!
I am pretty excited to work with this platform every day and can't wait to see what comes down the pipe next.
If you enjoyed this content and want to get started with Meteor.js, be sure to check out my affordable new 8 days of Meteor.js email course.
Also, I want to give a big thanks to Nick Wientge for making the infographic sexy. Another round of thanks goes to Eric Ripa, Ben Stafford, Mark Shropshire, and Sacha Greif for reading this post and suggesting edits.