MEAN stack or Meteor
Music for reading(spotify)
Sharding ? why ?
MEAN stack or Meteor
MEAN stack or Meteor
Pros: Great to get started and quick to get a prototype out to end users.
Cons: Nightmare to scale.
The reasons I would not recommend Meteor.js are:
- Almost nobody in DevOps has any experience of deploying/supporting Meteor at scale. so if you are lucky enough to write a successful app, you will out-grow Meteor pretty quickly.
- Meteor's Plugin ecosystem "Atmosphere" has grown up with little "adult supervision" so there are several packages written with poor code quality/standards (no tests) which are not maintained or bug-fixed. So you "mrt add xyz" and it works until the Meteor core gets updated and then the plugin stops working because meteor core made a non-backward-compatible change... #nightmare
- Testing is not a focus of the Meteor framework. None of the tutorials on Meteor mention testing. This means that everyone learning Meteor is doing it "Cowboy" Style. There is Laika Testing Framework for Meteor but virtually nobody is using it. So, if you need your code/app to be reliable, best of luck with meteor.
If you are only building "proof of concept" apps for a few hundred concurrent users, and don't need to worry about the "real world" go with Meteor!
"MEAN" is a lot easier to build apps following a Service-oriented architecture.
Currently we are favouring substituting the E (Express) in mean for H (Hapi.js) because the Hapi framework offers considerable Performance, Security and Scalability benefits over Express. (See list of companies using Hapi on hapi.js includes PayPal, Walmart, Mozilla and NPM!)
Sure NHMA isn't a great acronym, but pick your stack for the individual merits of each component not because it has a catchy name.
Meteor have done a great job of marketing their framework whereas spumko/hapi have been too busy building a *great* SOA toolkit focussed on fantastic code quality, near linear scaling and e-commerce grade security to waste time on self-promotion.
If you just want to throw something together for a Hackathon and put up a demo on Heroku, you can't beat Meteor! Just don't expect to deploy a Meteor app to anything resembling scale. You've been warned!
Big difference. Meteor automagically wires up all socket calls. MEAN uses REST and not sockets by default for communication. In Meteor, you're developing front and back end all at once. In MEAN, you have a clear separation.
Meteor can "hot code push" currently active clients whenever you deploy a new app version. Those clients will upgrade to the new code without losing their UI state.
Although I don't think the concerns made by Nelson are unfair or unwarranted, I do think they are not really accurate, certainly not complete. Let me explain:
- Meteor.js is built upon Node.js and MongoDB and for the most part is configured and scaled almost the exact same way. For performance reasons, it is recommended that Meteor be configured to be able to read the MongoDB oplog tail, but this is easily performed and documented in numerous places. With regard to all the other sorts of *devops* required to deploy apps (e.g. certificates to support token passing and integration with other services, etc..), this tends to be unique for each app and hosting environment and Meteor doesn't make it any easier or harder.
- None of the package systems have much in the way of supervision. I can find tons of poor quality, untested and abandoned packages on NPM or Bower, etc. There are also many well-documented, good quality, and well-maintained packages on Atmosphere with unit testing, etc. If you are going to include open-source packages in your production apps, then you better learn to be able to perform some due diligence around those choices. You may also *shocker* want to consider reaching out the authors and consider *paying* for some support to help ensure their packages continue to be well-maintained.
- MeteorJS itself is a CLI and a bunch of packages. Packages are tested using a built-in testing framework called TinyTest, and all the core Meteor packages have tests. Yes, unit testing for many community packages is lacking, and yes, the availability of a more robust testing framework is still maturing. Once again however, the well maintained community packages do have unit tests, you just have to be careful which community packages you choose for your critical production application (how is this not true for NPM or Bower stuff too? - that's open source for you!!)
A lot of programmers and organizations are working hard extending Meteor with good quality packages, and it will only get better with the growth and maturing of both the core product and the community.
Originally Answered: How does Meteor.js compare to the Mean.io stack? NOTE: the most up-to-date version of this answer is on my website at Meteor.js vs. the MEAN stack. See also Why Meteor.
Meteor gives you a lot more out of the box. It's a mature full-stack framework where the client and the server communicate data updates seamlessly and automatically, without you having to write any boilerplate data sync code.
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.get), 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.
Guillermo Rauch, the well-known creator 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:
- Server rendered pages are not optional
- Act immediately on user input
- React to data changes
- Control the data exchange with the server
- Don’t break history, enhance it
- Push code updates
- Predict behavior
Meteor focuses specifically on implementing #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 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. The MEAN stack doesn't support deploying yet.
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). 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 (the original before the MEAN.JS fork) is in such a terrible 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 fork, MEAN.JS, 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.
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.
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: https://twitter.com/rauchg/statu....