Current State of Firebase vs Meteor


#1

What is the most current pros/cons of firebase? I know firebase has added a ton of value-added features in the last year-- so wondering what people think the pros/cons are (beyond just knowing one stack better than the other). It looks like they’re offering a hosting service (maybe similar to galaxy?)

I guess it probably costs more to scale a firebase app (app hosting + DB hosting) than it would with say mLab and galaxy/DO


#2

I think really the main difference is whether you want to write server-side code or not. If you don’t have any logic on the server and don’t expect to have any in the future, then Firebase is designed to make life as simple as possible. IMO most apps need some server code which is why I picked Meteor back in the day.


#3

The data store for Firebase is VERY limited compared to Mongo. If you have very simple data structures its great. Best practices require you to ‘flatten’ or normalize your data. Queries are particularly weak. You get a single property (and the object Id) to query on. If you need multiple properties to query against then you need to add that query key to the object. No arrays, only properties. I converted a modestly complex mongo document into firebase and by the time I got through it looked like more like a normalized SQL db(lots of separate objects–read collections or tables-- where to start I had only one) without the power of SQL. Very fast and Google is stunningly generous with what you get for free. Mongo it ain’t


#4

Three years ago, I started to use Meteor for one of my hobby projects. I fell in love immediately; it worked great! And it was so simple. However, I never spent enough time to actually finish it, and my life went on with other challenges (for some strange reason, I typically never finish stuff; it was not Meteor’s fault).

3 months ago, I needed to learn Firebase. Initially, I actually thought I could use Meteor, but it had changed quite much since I last used it, and with the upcoming Apollo project, I figured it would be best to wait with Meteor. So i went with Firebase instead, and I started to re-implement my hobby project, so I easily could compare it with Meteor.

I never got far with my re-implementation (abandon it when I had learned the basics), but it is way simpler to use than what Meteor is now. The only drawback is that you can’t have arbitrary code running on the server, and I guess this is what makes Meteor both more powerful and harder to use, but if you don’t need that, I would strongly recommend you to give Firebase a try.

Firebase + Vue ≈ Meteor - “custom server code”.

Firebase can even host your website for free, as long as you don’t have over 100 concurrent visitors. That’s another reason why I would go with Firebase (for hobby applications).


#5

What makes it simpler than using Meteor + Vue for example?


#6

If I choose to use Vue + Firebase, I know what I need to learn. I need to learn Vue and Firebase.

If I choose to use Meteor, in addition to having to choose and learn a rendering library and a database, I need to learn the Meteor Framework. Now, the framework is not that big if you remove everything you don’t need in order to achieve similar functionality as in Firebase, but to a newcomer, it’s not obvious what can be overlooked. Simply going with Vue and Firebase, and skipping the framework, will be faster.

Using Firebase simply require you to import a single object from a single JavaScript file. Using Meteor requires you to import different things from different files. I’m not saying it’s a totally bad idea, but it does kill my productivity, and it does make my life harder. I would prefer if I didn’t had to spend time on importing stuff from the framework myself.

With Firebase it is very easy for me to inspect my members and my database. I wish it was equally simple in Meteor. There probably exist packages one can use to quite easily add similar functionality in Meteor, but since Meteor has become more abstract and doesn’t force you to use a specific database, I need to lookup the alternatives myself (and all different alternatives needs to be configured in their own special way…). And that’s kind of a red thread in my experience of the development of Meteor; the framework becomes less and less specific, and I as a programmer needs to do/take more and more work/decisions on my own. I wish the framework would do that for me instead.

Publishing a test application that I can share with my friends is free and quite easy using Firebase. With Meteor it’s not free any more, and somehow I need to setup both the database and Meteor application.

Scaling is not something I need to worry about that much using Firebase, in addition to how I structure my database. With Meteor, I need to worry about the database and to make sure that my server code is scaleable (which I guess won’t be such a big deal if I don’t have server specific code in addition to database read/writes)

The special client and server folders for client respectively server specific code, such as shown here, makes sense, but in comparison to only having client code, this kind of make Meteor twice as complex.

I’m not saying that Meteor is down the wrong road, but if you don’t need code running on the server, my experience is that Vue + Firebase is way easier. But I’ve now argued from my standpoint. Care to argue for the benefits with Meteor + Vue? Would have been cool to get a comparison.


#7

Hey I’m on my phone right now so I can’t type out a good reply but I just want to say I really appreciate the detailed analysis!


#8

Also bindings a la https://github.com/vuejs/vuefire

(However, I gave up on Firebase after trying over the course of a week or two to get a domain verified).


#9

Hayho,
i just wanted to give you some first hand insights as i’m currently using both firebase and meteor, in different projects.

Pros:

  • a really good free tier(hosting, database, auth,…)
  • fast and super responsive servers
  • use webpack and other 3th party libs without hitting meteor borders
  • testing is a breeze
  • adding/removing firebase is done via a simple npm install
  • the auth is more intuitive
  • there’s a huge development team working on it
  • it’s updated frequently (https://firebase.google.com/support/release-notes/js)
  • good notification/universal link integration
  • servicewokers just work :slight_smile:

Cons:

  • it’s not as simple as meteor create x && meteor run start … tbh with create-react-app it’s not that much more complicated, but still it is more complicated
  • if you need a complex server side (more than validating), you have to use the node lib and roll your own server(not free any more)…(not sure if this is a real con, as you have to do this on meteor in any case)
  • if you really need a server side you have to roll it on you’re own(express+?) and it#s definitly more complicated than with meteor i guess
  • you’re bound to google services, you can’t roll you’re own firebase-database server
  • sql like queries are somehow possible(read the sql-on-firebaes guides), but actually pretty complicated and awkward when you are used to the mongodb or even sql syntax (and not everything is working)
  • auth is really restricting and not as easy extensible as the meteor one
  • as almost everything is clientside, you most likely have to rethink a lot of stuff you did on meteor

Actually I think firebase is a lot cheaper. It’s free and fast up to 100 concurrent users and after that it’s still less than ~10€ for unlimited concurrent users(for most applications it’s already hard to hit the free border i guess).

When is which stack better(that#s of course super opinionated)?
For complex server side applications i probably would still use meteor…
For mostly client side applications i’d go for firebase or sth else (e.g. meteor serviceside and vanilla react + some ddp package would be thinkable if you want to stay with meteor)

Regards,
Lukas


#10

I’ve looked at it more and I’m sticking with meteor.


#11

That fact changed with the launch of https://firebase.google.com/products/firestore/ in October 2017.