When talking about view layer integration, at least when it comes to Vue, I think an important aspect is often overlooked - that the integration itself is actually quite thin. @akryum, a core team member of the Vue project, has done the work. vue-meteor-tracker is 261 lines of code and vue-component is approximately 1500 lines of code. The former gets us tracker integration and the latter enables use of Vue’s single file components with Meteor. It seems to me that these two packages really cover the most important elements of what is necessary between Vue and Meteor. And this is a good thing. The connection area between a framework and library should be small and well defined (and I’d call sub 2k LOC reasonably small here). Less chances of things breaking in the future and less worries about maintenance.
A good Vue integration in my opinion is not one which provides a lot of behind-the-scenes automatic connections between Vue’s reactivity and Meteor’s reactivity, but quite the opposite - a good integration is one where the link between Vue and Meteor is as small and deliberate as possible. So that the Vue code you write for a Meteor project would be as close as possible to Vue code you’d write with any other backend and the small parts of your code where you inject Meteor’s reactivity to Vue’s reactivity would be clearly visible and understandable. This will give you three major benefits. Firstly, you’ll be able to effortlessly onboard new people into your Vue/Meteor project from the vast pool of Vue devs that are not familiar with Meteor. Secondly, if you’d ever want to switch away from Meteor, most of your Vue code would likely be easily transferable to the new backend as it is not coated with a heavy layer of Meteor specific abstractions (an important insurance policy for most CTOs I’d say when an employee tries to sell them on Meteor). And thirdly, you need not worry about the implementaiton of the integration falling out of date since it’s only a small chunk of code and presumably easy to maintain, even if a completely new maintainer would need to pick it up. It seems to me that these two packages mentioned above have opted for such an approach and this is a really good choice in my opinion by @akryum .
People put value in ‘official support’ of view layers in Meteor to alleviate their fears that at some point an integration will be abandoned and they will be left in a bad place with their project. Taking the above into account, a good first step to address such fears with regard to Vue and Meteor would be a blog post by @akryum on the official Meteor blog describing what are the dots that he has needed to connect between Vue and Meteor to make the integration work. And importantly, describing that the integration is effectively very thin (you will not depend too much on him continuing to maintain that 2k lines of code) and that the integration is thin not because of lack of resources or commitment, but because this is the best solution that makes your Vue/Meteor project future proof and avoids vendor lock in and enables bringing in new developers quickly.
Also, a very helpful resource for me has been this repo by @efrancis . From the little contact I’ve had with him he seems a very nice guy. If we’d be able to convince @akryum to make the initial post describing the Vue-Meter integration itself, then perhaps @efrancis could follow with a blog post describing the choices he has made in his opinionated starter kit. Two very big ifs. But who knows, maybe if there’s enough peer pressure on the forums the guys will find the time?
This regarding communication. Regarding the Vue integration itself, it is likely that when more people pick up Vue with Meteor there will be a need to improve certain aspects of it. In my opinion this would be a good place for some modest crowd funded action, similar to what took place recently with mup here, if @akryum would be interested. Although I must say that one essential reason why Vue is as good as it is today is in my opinion that Evan You keeps the focus on things and filters out the good feature requests from the many bad ones. Having the same kind of filter on the Meteor integration would be essential to prevent it from bloating up. So crowd funding, if necessary at all, would require someone with authority (be it @akryum or anyone else) to be able to keep things lean and in focus as well.