Why do we need meteor when we have angularjs + firebase?

Newbie question yes,meteor is great for frontend folks as they can be a full stack dev without understanding back end.

When there’s such service like firebase that handles backend and it gets cheaper what makes meteor special?


This is all about to be pretty biased: Because Blaze is 1,000x better than Angular (and yes, I use both, and I have to use Angular at work). Something about Angular, the documentation, the fact that 2.0 has to be a complete rewrite with no backwards compatibility, the fact that they really push you away from jQuery, the custom ng-everything (“let’s just totally ditch the HTML spec and create unnecessary learning curves everywhere” I imagine it’s creators saying), the fact that the framework regurgitates itself all over the DOM (ever use ng-repeat before? yeah…) … it all left a bad taste in my mouth. Also, with firebase + angularjs (to my understanding) won’t get you full database-to-ui reactivity. Angular was made to work with any backend. It couldn’t be too opinionated in any which way, except on the presentation layer. By presenting itself as a full-stack solution, Meteor was able to introduce novel concepts that have, in my opinion, introduced a new paradigm in web development, for the better, and significantly so.


I would say the biggest advantages are:

  1. You can host it on your own server - no need to be tied to Firebase infrastructure
  2. It’s open source, so if the backend framework stuff doesn’t quite work for you you can dive in and add optimizations specific to your app - I know Hansoft X did this
  3. You can actually write backend code when you need to - if you need to call an API from the server, do complex server-side data validation, connect to some other database, etc, it’s basically impossible in Firebase

If you just want to build a simple app with some tree-shaped data and user permissions, Firebase is a great choice. But a lot of people with more complex apps will need more control over the server side.


This isn’t actually true with Meteor. Meteor allows you to reuse your front-end and back-end code in various places, but a failure to understand what’s going on in the backend will likely bite you in terms of security and performance. I suspect the same applies to complicated apps on Firebase as well.

I actually came to Meteor from the other angle. I started off as a back-end developer first and used to get super-frustated at having to rewrite a lot of very similar code (validation, persistance, etc.). Meteor made it easy for me to reuse a lot of that on the front-end.


Here’s an alternative answer:

if you have angularjs and firebase and you’re happy with it, what’s the problem?

I think we’re in a better place thanks to having these different options. Firebase is heading in the direction of integrating well with Google Cloud Platform. If you have, say, an Android app with a web dashboard that you’re hosting on App Engine and you want to use BigQuery, why not use Firebase too? Same goes for the Facebook “stack” that’s evolving right now with React/Relay/GraphQL/Parse, etc.

Or you can use Meteor. (or one of the other platforms similar to it)

Ultimately, Meteor is a way to tie together a bunch of Javascript technology on the front and backend and make them work together seamlessly. If you like that kind of thing, Meteor will probably make you pretty happy. If you prefer something else, use it!


I really like this answer.

All these solutions trying to solve a similar problem in different ways.
It’s not a good idea to ask someone to compare.

First check what those platforms do. Then check what you wanna do.
Check your teams competencies.
Decide and move on :slight_smile:


angular is garbage compared to blaze/react that’s why.


Why do we need pizza when we have tacos?


Actually with Angularfire you will most certainly get full ui reactivity; 3-way data binding is a feature they’ve shown off many times.

1 Like
  1. Agreed, but scaling your own infrastructure for Meteor will almost certainly cost you a lot more money. I find that with Meteor, you trade development costs for scaling costs.

Other solutions have scaling costs just as well. Galaxy seems fair-priced.

This is a funny statement. That’s like saying you can drive a car because you ordered a cab.


I would also add to the existing arguments that there is just no comparison between having 14 different tools (packing, minifying, deploying, watching, building etc.) that often won’t cooperate, and having 1 tool that integrates all you need in to one magical command, without sacrificing the ability to mix and match your preferences.


With Meteor, you get a client, server, build tool, support for different databases, and more. With Firebase and Angular, you just have a client and database.

Meteor is an integrated, open source solution, which has been helping a lot of developers build really quickly. Meanwhile, Angular is (imo) more complicated than it should be, and Firebase locks you into their service from the start.

1 Like

What solutions are you referring to? We’re talking about Firebase here; they take care of scaling.

Agreed, but the fact that Meteor now supports Angular kinda blurs the lines a little. No matter what DB storage engine you chose you’re locked in. With Meteor you’re pretty much locked to Mongo and probably compose.io, Firebase is no different in this context. If I were using Angular, I probably wouldn’t use Meteor as Firebase happily takes care of scaling concerns. I’d just spin up some microservices to process serverside code from a Firebase queue.

@niallobrien What do you mean by locked in? MongoDB and Meteor are open source, while Firebase is closed source.

I think he means locked in in the sense that if you write your application in Meteor and if you later want to move away from Meteor, you basically have to do an entire rewrite.

In both cases you’re locked in, but at least in the case of Meteor you are in control. If firebase suddenly stops its services, you’re pretty much screwed.

One reason why businesses are not using Meteor is the lock into Meteor. If I was running Meteor I would offer a premium paid for service which takes a Meteor application and converts it to a standard client and Node server app which a business could then adapt as required.

Meteor builds to a standard node server app and browser app…
Businesses are happy to have a lock-in in .Net and other technologies, so why would Meteor be any different as long as there is commercial support available (which is now the case). Also, there’s no such thing as a standard node server app. Especially in javascript, you’re always relying on a large amount of different libraries. I’d rather not rely on 200 small libraries maintained by random people in their spare-time on github, but on 1 big one, maintained by a company.