I’ve chosen Vue for a new project, and am bootstrapping it with Firebase b/c I feel like Meteor is a moving target. I plan to loop back in a few months and think about whether Firebase is a long-term solution I feel comfortable with. If not, I’ll reconsider Meteor, among other options.
I totally feel the whole moving target phrase. I also came to meteor from laravel, and realized it seems alot of it is a mess, from someone who’s entering the meteor world it looks like chaos, so easy to get lost in some of the discussions, about the view layers, blaze vs blaze2 vs misc, and the discussions about meteor’s future. Makes someone new to Meteor very uneasy.
Nonetheless, I found this a few minutes ago.
If we use that library combined with
It seems we’ll be able to use Vue, without much trouble(just speculating, ill try building something this week).
Sad to see Vue not getting much love/talk as an (optional) view layer for meteor, especially when the developer of Meteor is part of the Meteor Developers.
How do you like firebase? I’ve been looking at it as an alternative based on the state of meteor. What don’t you like about it that you get in meteor? Sorry if that’s a basic question but I don’t know much about firebase other than hearing it around and checking out the website tonight.
Used firebase with angular and would strongly not recommend it over meteor’s mongo solution for building a general app. Mongo, minimongo, pub/sub, querying in mongo are far superior to what firebase and angularfire offered half a year ago.
My experience with firebase:
However, if you were building something very simple that needed realtime reactivity, then it can be suitable.
It’s not that ppl didn’t use Vue with Meteor but more that up until October last year, everyone was using Blaze because it was inbuilt. It was the way to go in a framework so opinionated, it even had an opinion about where you should put your files least it didn’t get picked up by the server.
But this is changed and Meteor is becoming more open to be used with other front ends, Angular2, Aurelia, React, Vue, Cycle.
However, as this is all pretty new, and no one really knows where this is going or what it means yet, there’s no consensus about which framework to use so it’s a bit of a free-for-all atm.
This may not be the best time to pick up on Meteor if you just want something that works.
I’d be interested in the specific pain points you hit with Firebase. Is your data highly relational? I can imagine that being a case were Firebase isn’t the best option.
Comparing it to Meteor really isn’t apples-to-apples, but Firebase does offer authentication, querying, queues, and built-in hosting/deployment. And it’s vaporware until it ships, but Firebase is also building ‘triggers’, which promises to allow you to run server-side code without an external node.js app in response to changes in Firebase (basically what you can now do with queues, but without managing your own node server).
The mini project I did had a concept of users which could be either a trainee or a trainer. There were training programs comprised of modules. Each attendee of a program would record their own progress through the modules and have a quiz at the end.
It was a fairly simple system but because of the points I mentioned in the linked post, the code turned very quickly into callback hell. In firebase, you do a async call to get one endpoint which is one collection. If you need to get linked documents you either denormalize it into the one you want or have a reference. In many situations I chose to have a reference and that was the start of my woes.
And the built in security feature (access to a root node means access to all children) makes sense in firebases’ architecture but it meant that I had to create proxy collections for referential purposes and separate out a single document into several based on how many roles I was planning to have in the system. If I ever needed more than trainer, trainee it would be hard to stop users from viewing the db.
In terms of the rules system… even for my simple app, I generated a nest of intricate rules that was very brittle and complex to follow. It meant when I was debugging why some documents weren’t returning, I was looking in my controller, service, data providers (eventually did this so I didn’t have to write massive queries to simply fetch and join) and also rules (looking mostly for typos) to work out why it wasn’t working.
In comparison, minimongo, pub/sub does what firebase offers (no friction to your db on the client) whilst giving you a server where you can put your business logic/authentication rules in one place.
I found the latter to be a magnitude of order easier to develop with.
I really like Vue js. I’ve only been using blaze for a few weeks so a comparison is a little difficult right now. But, what I will say is Vue is clean and pretty straight forward. It feels lighter than Angular. I’ve used it a lot with my Laravel projects in the past and after an initial tutorial I was loving it. It is very approachable.
I’m still undecided what will work best for me. ViewModel (Blaze), React Meteor way, React Mantra way… Vue.js seems to be the most elegant tbh.
So, really interested in Vue.js with Meteor. I’m just getting into Meteor (and Node for that matter), so maybe not the easiest route, but did someone already tried Vue.js + Vue router + Vuex (and maybe more) as NPM packages in 1.3?