So I just found meteor and I think I’m in love. However I want to specifically use the Vue Ecosystem for the front-end and meteor for everything else. Is this recommended?
I’ve seen this https://atmospherejs.com/vue/vue
and
https://github.com/vuejs/vue-webpack-meteor-example
Which would be the recommended way?
I’m liking Evan’s approach a bit more than the community package. Would I be able to use the full vue ecosystem (vue, vue-router, vuex, async components) efficiently with meteor?
I guess not many people use this type of setup then…
I would also like this setup. Used vue with Laravel and I am familiar with it. However, I’m new to meteor and can’t answer your question.
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.
The current state of affairs in Meteor-land is a bit frustrating, but you only have to spend a few days developing with vanilla Node to realize how much potential Meteor still has to be the best way to build Javascript apps. They just need time to reconcile their initial goals with the needs of developers in 2016.
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.
I’ve done some work with Meteor & Vue. I recommend using the libs you point to.
@raponte
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).
This post is still very useful when thinking about Firebase: https://www.firebase.com/blog/2013-03-25-where-does-firebase-fit.html
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.
How would you compare it to Blaze?
Vue.js? There’s a bit of a learning curve alright. It’s like a mixture of Angular & React components (markup, styles & js in one file) but the API is certainly much easier to grok. I highly recommend https://laracasts.com/series/learning-vue-step-by-step
Vuejs has components like React without embedding html (like jsx). It uses templating like Blaze but has a much better event handling.
IMHO it’d be great if Vue was a View offically supported like Angular, React and Blaze.
In any case it’s easier to use (almost as Blaze), makes sense and its way of doing stuff is logical to me.
Finally it’s already easy to use with Meteor.
Personally I used Vue with Meteor and developed a mobile app. After installing the pacakage vue:vue https://github.com/zhouzhuojie/meteor-vue) I had no issues whatsoever.
Look great, 
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.
+1 for Vue.js - love it and would love to see MDG adopt full support for it.
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?
Would love to hear your results!