I would like to begin with clarifying against @cloudspider’s comment and say that I definitely am not suggesting a “lesser” tool, in fact I am suggesting vue because I think it is a better tool for you for the reasons I’ve listed.
Otherwise, all these ui frameworks/libraries are, again as he said, equally powerful and offer almost the same featureset where it may be easier to do one thing with one than the other but mind you there’s no magic wand out there that’s great on all aspects.
It all boils down to experience and preference.
That brings me to my conclusion; you don’t have the experience, nor a preference (yet) for a ui framework. But looking at other people’s experience, especially people who come from mostly server side “non enterprise web” stacks (php, perl, ruby) with some templating language experience, it looks like - based on statistics - that vue is going to get you from zero to mvp much faster.
But since it is also a very powerful alternative with a very vibrant community, the odds are you are going to continue with it and reuse parts of your ui codebase for the next iteration of your product.
By the way, I prefer react for my development because I am very experienced with it and know how to both quickly build stuff and architect a future proof codebase. I also happen to believe that the corporate backing is a good thing. But these are all opinions.
Just the other day, I was discussing a similar topic with a ceo planning to rebuild their product from scratch. They wanted to use vue and are recruiting. What I said was “get react developers to build your project with vue” because a good share of people who develop and become highly productive with vue have been using vue as their first library. They might kind of lack why vue was created and in what ways it might be better/worse for a specific task etc, but the ultimate reality is, they have become productive with it in no time. That’s vue’s main focus, developer experience.
Now coming back to the “official” word. I think it is one of meteor’s main pain points in communicating what it is.
It just happens that, blaze, angular and react have been documented by mdg (company behind meteor) and they have also released some tools and utilities around them, but they are so small or simple that there’s not much that differentiate those utilities from their community counterparts. In fact, that’s how angular and react entered the meteor ecosystem in the first place.
At this point, MDG’s official stance is to encourage the community to build utilities, documentation and governance around these new ui frameworks and they (imho rightfully) don’t want to maintain all of them themselves “officially” because there really is no extra value that they can provide.
As for the vue-meteor community, they are quite good in what they are doing. You’ll very soon realize that the meteor-integration is such a thin layer that you’ll even forget it is there and you’ll spend most of your time going over general vue docs, tutorials etc.
By the way, these arguments can all be repeated with the data system. I’ve advised that you stick with meteor’s built-in data system with publications and methods and mongo whereas I could have advised you to go with apollo, or something else entirely. But the reality is, the built-in data system is going to make your life so much easier, getting out of your way, solving many problems for you so that you can build your mvp. Don’t get me wrong, it will also get you up to some quite large scale, too, if you architect those building blocks correctly.
And lastly, again, stop burning rubber thinking about these, pick the tools and release the brakes. Come back and ask more questions, this time for features of your app, parts of your codebase, begin building so that we can help you build!