and evolution is just a theory, right? 
Vue is objectively better in a number of significant ways, including optimization efforts, learning curves, and the option to use HTML and CSS technologies without expressing them in JSX.
Despite the name, React is not even Reactive – it uses a “pull” approach (rather than “push”).
Did you read that part too? 
Also, oh man I just realized the embarassing Your / You’re mistake…
huh? You realize you just took a part of my message and changed it so that it doesn’t match yours? I didn’t negate anything you wrote / said.
I don’t think Vue is better thank React because of the clean react API and the fact that it drove the entire web components ecosystem forward in addition to streamlining on mobile development.
But I totally agree with your statement that Meteor was/is in a perfect position to adopt Vue officially and this would have helped Meteor to ride on the Vue.js hype curve.
Also if you look at the tweet, you’ll notice the following conversation:
This was all result of poor marketing moves in 2015 that resulted in so many FUD blog posts from which the image of Meteor has yet to recover. The community isn’t even aware of the work being done on Meteor since then.
I personally don’t pay too much attention to the FUD blogs, hype or Github starts. I just need the best tool to meet my objectives efficiently and effectively and Meteor for me ranks top within the node.js and web development thus far.
Do you mean the github stars marketing campaign?
Honestly I don’t know of any valuable alternative as a nodejs backend framework when it comes to ease-of-use, dev experience (file reload, babel transpiling etc.) and the ecosystem of packages around it. If Meteor was fully pluggable it’d be even more awesome (in some cases I don’t want to use the default server).
I personally think the mistake was announcing that Blaze was being abandoned (basically this post) when the plan was do decouple and open source it, people are still using and liking Blaze till today and they can use other view layer if they want to.
Back then meteor was blaze, and the community wrote tons of atmosphere packages so naturally a lot of people freaked out. So to write an “emotional” post about not supporting blaze, in my opinion, was the trigger for the FUD in 2015.
Again that’s just my personal read on the situation, I think Meteor has improved tons since then.
Yeah I remember that. It’s remarkable that people still use blaze and I think the way it is right now isn’t as bad as people thought it’d be. Definitely was worrying at the time though.
Hmm, I just received the newsletter and came here to say Our company was one of those who switched from meteor to laravel exactly when meteor dropped blaze support. we didn’t have any ready to use product when that happened and still were developing fortunately and so the cost were not that heavy. we are completely happy with vue, it is doing very well for us and we have 5 products with vue, actually we have also developed both ios and android apps based on vue as well using weex project just like react-native and the results are completely satisfying.
And by the way vue now has 84k stars in github and react has 88k I think soon vue will pass react if you look at the slope of getting stars.
It would be interesting to see vue growth by demographic, I think they went after the Chinese tech market which could partially explain their rapid growth.
It’s ironic that the founder of Vue.js was actually working within MDG at some point and he was actively convincing them to adopt vue.js! talk about missed opportunities. It might not even be far fetched to say Vue simplicity might have been even inspired by Blaze.
I think the official tools and libraries around Vue are really awesome. From smaller libraries like vue-test-utils to vuex statemanagement and more.
And I appreciate the effort to make those tools part of the official vuejs repository as it gives security that it’s not a package that’ll be outdated in a few months.
I’m not sure that the “M” in “MDG” is still means MeteorJS…
everything evolves - Apollo, Galaxy, except the Meteor…or too slow evolves…
Sad, but true.
I don’t agree with the idea that MDG missed the boat by not integrating Meteor more closely with Vue (especially since Evan used to work for MDG). I think we all need to take a step back and look at this from a business perspective. MDG has their priorities set (and funding allocated) in areas other than view layer integration. They’re working with a finite number of team members, time and money to build awesome open source developer tools, which means they have to focus in the areas that have the biggest potential of allowing them to not only keep the lights on, but to also grow as a company. What if focusing more on Vue integration took time away from bootstrapping Apollo, which prevented it from being a success, and leading to more income paths like Optics / Engine? We don’t know if this could have happened, but I’m sure MDG does.
Yes, we’d all love “feature X” to be fully supported with Meteor ad infinitum, but the reality is that while MDG is focused on making open source developer tools and they’ve more than delivered in that department, at the end of the day they have business responsibilities that need to be addressed. That’s why MDG has and is trying to involve more community members to help out with Meteor, to keep the ecosystem alive and thriving. Yes, there’s always more that can be done, but honestly that’s where we all come in. Want top tier Meteor + Vue integration? Awesome - take a crack at it like the vue+meteor folks did, and if you run into any show stoppers, open new Meteor issues / feature requests to request changes to make the integration go more smoothly. While MDG might be focused in areas other than the “feature X” we’d like to see implemented, they’re developers too. They “get it” and will help when they can, or empower others to help when they can’t.
I think many of us here have either run a business or bootstrapped a startup. If we put ourselves in MDG’s shoes, I think it’s quite easy (and reasonable) to understand why they’ve made the decisions they’ve made.
Make sense! thanks @hwillson for reminding us of other perspective. I for one is really happy and grateful to what what MDG did and doing, they surely had to make tough calls but I’m really happy with today’s Meteor 
Galaxy is their platform to host Meteor Apps on, so that’s pretty much M related. Also Apollo is something that will be helpful in advancing Meteor as a framework (by integrating it, replacing the Minimongo layer with GraphQL).
Chinese ecommerce giant Alibaba builds with Vue. If only MDG had the wisdom of Chinese devs!
Absolutely! And Evan says Vue was inspired by Elm, Angular, and Polymer too.
@hwillson I’ll be really happy to see Meteor sits on top of all backend frameworks again because I think this is really where it belongs. I think @maxhodges hit the nails on the head by identifying the real reason why something like laravel is trending back in popularity, it’s most likely due to their formal support to vue.js as their view layer.
I personally don’t use vue I prefer react, but I’m wondering what is really preventing Meteor from officially endorsing vue just like react and angular? @akryum did an incredible work integrating it with Meteor and it seems some folks in this forum are using it in production! we even have form category dedicated to vue and it’s very active. So again what is exactly preventing Meteor from officially endorsing vue? Isn’t it just adding to the main site, the guide and writing a tutorial and blog about it? I’m sure a lot of the vue users in this forum can help with those tasks as well or am I missing something here.
Just sharing some thoughts, again I’m not really a vue user but I’d love to see meteor grow and this seems to be as a reasonable step forward.
What do you guys think?
Yes! If anyone is interested in helping with this, please see the following as a starting point:
pull-requests-encouraged 
Maybe they are focusing on React and Apollo with the hope that Facebook will acquire the team and technology. Vue would just distract from a strategy like that.
I’m not sure about that, I think they’re just tight on resources with too many fronts. It seems that if the community can support in providing the guide and tutorial material for vue they might endorse it officially.
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.
