Comparing Meteor.js and the MEAN stack

I started writing this article as an answer on Quora, seeing how there wasn't really any good comparison between Meteor.js and the MEAN stack (MongoDB, Express, Angular, Node.js).

Introduction

First off, I should mention there's no such thing as "the" MEAN stack or framework. The acronym (explained above) generically identifies using these technologies in combination. There are several implementations of the MEAN stack (a community fragmentation problem in itself). Meteor is actually a mature full-stack real-time web application platform (a framework plus a lot of utilities) that has been developed by a very well-funded and highly knowledgeable team since 2011 and has a very large community.

What Meteor gives you for free

Meteor gives you a lot more out of the box. The client and the server communicate data updates seamlessly and automatically, without you having to write any boilerplate data sync code.

The MEAN stack vs. Meteor.js

The MEAN stack is just MongoDB, Express, Angular and Node.js bundled together, but there's nothing seamless about it. You have to do all the wiring-up yourself between MongoDB and Node.js, between Express and Angular, create REST endpoints and consume them etc. - all this just to get a basic web app going, without any features that Meteor gives you for free: hot code reload, mobile development (web, Android and iOS apps from the same code base), reactive templates that update automatically when data on the server changes (try to write code for that manually and make it run correctly over intermittent network connections, and make sure it's secure), session management, packages that can install components both on the server and on the client (e.g. server-side autocomplete - you won't find this anywhere else; Twitter's Typeahead and the like are client-only solutions).

With the MEAN stack, when you make a REST request for a table/collection, you're essentially saying "Send me the results of this query". With Meteor, you subscribe to the results of that query, and any newly created or modified documents that matched will be automatically sent to the client over a fast WebSocket connection.

Thanks to its isomorphic APIs (the same methods work on the client and the server, e.g. HTTP.call), Meteor makes it easier for one developer to build an entire full-stack app, or for a team to have a better understanding of the code base across the project. The MEAN stack adds to the separation between the server and the client due to different APIs being used.

No callback hell

Meteor's server side runs on top of Node.js but eliminates callback hell by using Fibers. Even on the client, you can avoid callbacks and even promises by using reactivity via the simpler Tracker and Reactive Method packages.

In Meteor, your server code runs in a single thread per request, not in the asynchronous callback style typical of Node. We find the linear execution model a better fit for the typical server code in a Meteor application.

7 Principles of Rich Web Applications

Guillermo Rauch, the well-known author of Socket.IO, has written an excellent article call "7 Principles of Rich Web Applications". He's also delivered a talk at BrazilJS about the principles:

  1. Server rendered pages are not optional
  2. Act immediately on user input
  3. React to data changes
  4. Control the data exchange with the server
  5. Don't break history, enhance it
  6. Push code updates
  7. Predict behavior

Meteor implements #2, #3, #4 and #6 for the developer. #1 (server-rendered pages) and #5 (enhance history) are handled by ecosystem packages (Spiderable, Server-Side Rendering, and Iron Router). (#7 as described by Rauch, isn't really in the purview of full-stack frameworks.) By comparison, the MEAN stack needs to be coupled with Socket.IO to even have the pieces to implement these principles - Meteor already has them all glued together.

Meteor also has the entire toolchain built-in, from compiling Coffeescript automatically to minifying and concatenating CSS and JS. Within seconds from saving a file, all client web browsers will automatically reload and re-render the app thanks to hot code push (#6 above). The UI state (form inputs, scroll position, selection) is preserved (another fun thing to try to get right with the MEAN stack).

Meteor = MEAN stack + Socket.IO + grunt/gulp + Cordova + hot code reload + a lot more. Such as extremely convenient packages - one of the "Eureka" moments with Meteor is when authentication with user/password, Google, Facebook and Twitter is added just by including a package for each OAuth provider and one line of template code to indicate where to place the login widget:

meteor add accounts-facebook
// then add {{> loginButtons}} in your template to show the login UI

Meteor has over 4,3000 packages. MEAN.JS has only one module so far, for SEO. Meteor lets you deploy with one command to free hosting at yourapp.meteor.com. MEAN.io doesn't support deploying yet.

Which is easier to learn?

But isn't that a lot to take in all at once? Actually, not. Thanks to Meteor's focus on simplicity (one of its Seven core principles), Meteor in its entirety is far easier to learn than Angular alone. Many have found Angular to be a pain to learn and ended up frustrated - see An Unconventional Review of AngularJS:

Angular is... band-aids over self-inflicted wounds

You can get the basics on Meteor in just one hour - head over to http://meteor.com/try. Meteor's documentation is also very well-written. By comparison, the documentation for the MEAN.io stack is in such a shape that today I went through the Packages section and found an embarrassing number of typos in just a few minutes, all within two pages of the documentation. Packages seem to have no documentation, either. And not to discredit the authors, but you can't easily find who the core team is - the link in Credits is broken. The documentation for the alternative, the MEAN.JS fork, starts with,

After downloading the source code go over the official documentation of MongoDB, ExpressJS, AngularJS, and Node.js, then continue with the MEAN.JS Documentation.

Given that it really takes only one hour to make something useful with Meteor, from scratch, it's worth simply giving it a try first, to have a reference before starting to learn MEAN.io or MEAN.JS.

Of course, you'll still need to learn MongoDB well for a production app, but Meteor doesn't send you there to get started. The 80% most common cases of using Mongo are already explained in the Meteor documentation.

Community

Meteor also saves you from having to research what libraries to use for the various layers of the application (transport, data synchronization, API, security, CRUD operations, templating etc.). All the pieces that make up Meteor function together very well.

By contrast, when considering the MEAN stack, you start with the choice between MEAN.io and MEAN.JS. The short story is that the main MEAN.io contributor, Amos Haviv, Forked out of an open-source conflict in January 2014. You can read more about the story and differences on StackOverflow. This has split the community into ~6k GitHub stars for .io and ~2k for .js. Meteor by comparison has 23,000 GitHub stars.

On StackOverflow, right now there are over 10,000 questions tagged meteor, and about 1,100 total tagged mean, mean.io and meanjs

More more details on the community size, see the Community section in Why Meteor.

When not to use Meteor

As with any tool, Meteor is not always the right solution. I've expanded on when not to use Meteor in the corresponding section of my Why Meteor article (e.g. when you're building a client-only app, or when you require interfacing with databases other than MongoDB). To compare apples to apples, have in mind that the MEAN stack includes a server and MongoDB. So let's see when a MEAN stack might be a better choice for a new web application:

  • If you already have most of the pieces of your app written using the MEAN stack. Meteor provides many extra niceties, but make sure they justify the migration cost.
  • If you're only building a web service/REST API and don't need any client functionality. Meteor is a client-server platform. (Side note: if you're considering REST, consider GraphQL instead)
  • If you don't really need your web app to be real-time. There is a RAM and CPU cost for providing real-time data sync between the server and subscribed clients, even though one $5/mo low-specs DigitalOcean server can handle a basic Meteor app.
  • If you're building a website, rather than a web application, and it's more important to deliver the first page as fast as possible, rather than be able to prototype or develop very fast
  • If you already need to scale your app to millions of users right now - though with Meteor 1.3, two new developments will help in this area:
    1. The Galaxy scalable hosting platform
    2. Meteor's Livedata system now supports tunable queries to help scale large apps.

Conclusion

I've found that Meteor saved me from a lot of analysis paralysis, besides making me a ton more productive than if I had to put together the pieces in the MEAN stack. My suggestion is to read a bit on Why Meteor could be a good choice or not, give it a try first for one hour (meteor.com/try), then look at the MEAN stacks, and see which would work best for your project.

PS: skip to 44:30 in Guillermo's talk above. Someone asks him about Meteor. A month later:

love [Meteor] too <3
-- https://twitter.com/rauchg/status/522228968074661889

My tags:
 
Popular tags: