Why doesn't MDG just adopt Vue.js and forget about React vs Blaze?

[agusputra]

Vue.js will support virtual DOM and jsx. Read this : https://forums.meteor.com/t/with-vue-2-0-why-not-use-vue-js-as-view-layer-vue-js-will-support-virtual-dom-and-jsx

[emhmark7]

I agree, Vue.js gives the same feeling as Meteor: “It’s the thing” and makes water get out of our mouth about programming applications. And when I attend meetup about Blaze or other stuff, I get a bad feeeling about: Hum, it’s so much simple with Vue.js

More precisely: Meteor templates seem not natural for managing variables within the template (not object oriented) and ya, it is creazy to have several files for the same template. Vue.js fixes that.

[comerc]

To me, proxying through “state” before I put my data in a model and save it (or directly insert/update it) is just an annoyance–an unnecessary extra step or 2 or 3.

Automatization! (I want copying this solution to Vue).

v-bind - is field name of model, viewDoc & modelDoc - is read & write data via ViewModel & Model

[msavin]

@evanyou Hey man- any chance we will see an integrated Vue environment? I’d love something “high level” like Meteor but with your stack, and just the front-end. It seems like learning that would last me 5 years!

[emhmark7]

I m not an expert, but I do not undertand your comment. OK, like Evan’s own Meteor but just front-end. ?! Vue.js: isn’t it just that: a front-end?

[akryum]

BTW, I’m working on a extensive integration to turn vue into a full ui-layer for meteor. Don’t hesitate to post suggestions and issues!

[msavin]

@akryum not sure if timing is good, as Webpack integration and new build tool will eventually arrive… but am interested!

@emhmark7 well technically, a front end also needs a data layer, build tool and a bunch of other stuff. Maybe he can make it all work together. Can probably improve the developer experience a lot if he built an end to end solution

[laurentpayot]

@akryum not sure if timing is good, as Webpack integration and new build tool will eventually arrive… but am interested!

Indeed @sashko interview in Transmission #13 leaves no doubt that Meteor will use webpack in the long term.
I’m using webpack:webpack with akryum:vue (Tracker integration) and akryum:vue-i18n (i18n with lazy loading of locales, and more) and it is working great so far. Hopefully it will still work with the future webpack-based meteor build tool.

[FDisk]

Vue.js is already web component based
heres is my example: https://github.com/nfq-eta/vuejs-env/tree/master/src/js
1 vote from me goes to vuejs integration to meteor.

[aadams]

1 vote from me goes to vuejs integration to meteor

At this point with MDG divesting itself of Meteor, if anyone wants viewjs integration, they’ll have to write it themselves.

Here’s the Apollo + Vue integration package on NPM.

[sashko]

The Angular and React integrations were both developed initially from the community. So I don’t think this is anything new. The best way to make something happen is to put it together yourself and convince others it’s a good idea.

[emhmark7]

But there is not logical link nor it is an excuse not to do it. To do what you say, one need know how that not everybody has. The best placed here is the MDG because they know perfectly one side of the couple to match, and maybe the most complex side; also, for best integration. The MAIN idea behind Vue is that when we discover it, and compare it to React and Angular, we feel: this is it, I do not want the others, it should look like that (an object oriented approach, not a verbose jquery-like-locator-with-helpers). One of main points of Meteor is a well integrated stack, one that takes care of everything every projects need anyway. I read React doc (a taste of vomit) and read Vue doc (a taste of wow!)

[sashko]

@emhmark7

I read React doc (a taste of vomit) and read Vue doc (a taste of wow!)

I think this means you’re far more qualified to build an integration with Vue than I would be.

[aadams]

@emhmark7

The best placed here is the MDG because they know perfectly one side of the couple to match, and maybe the most complex side; also, for best integration.

…

One of main points of Meteor is a well integrated stack, one that takes care of everything every projects need anyway.

I don’t know if you got the memo – but MDG has long since taken down any philosophy they espoused to Meteor and are in the process of divesting in favor of their Apollo strategy. From MDG’s perspective Meteor will be an integration point for Apollo going forward.

The well integrated parts of Meteor you speak of are in the process of being handed over to the community – and it will become their responsibility to take the reins or not. Any new integration with Vue or otherwise will become something the community will need to sponsor.

I’m not saying MDG is closing shop and turning off the lights on Meteor just yet, as they’re still releasing improvements to the build tool and helping some with the migration of Blaze and the like to the community – but the day will come when this will be the case.

[emhmark7]

I was sincere. Not shure how to interpret your comment. I am shure my knowledge of JS and all interpreter workflow involved is low to none.

[aadams]

@emhmark7

I was sincere. Not shure how to interpret your comment. I am shure my knowledge of JS and all interpreter workflow involved is low to none.

Please read my comment just before yours friend.

[sashko]

MDG has never been in the business of building integrations for things ahead of the community. Literally, this has never happened.

React - built by the community first
Angular - built by the community first
NPM - built by the community first
Modules - built by the community first

Our job has always been to take the best of the JS and Meteor community and make it accessible to Meteor developers.

Also, all of our own production applications are built with Meteor. One of the apps we are using to work on speeding up build times is Galaxy – so we feel exactly the same pains everyone in the community does when things don’t work.

Never in the history of MDG was there a time when Vue JS integration would be built by MDG before it was widely adopted in the community.

[emhmark7]

Bottom of the line: For shure there are plenty ways to do things and plenty of preferences among programmers (that I am not aware of, but at the end of the day, there are programmers (of any level) wanting to acheive a project, as smootly as possible and if possible, with enjoyment of what they are doing. Meteor is aimed a being a tool for that. No?

Feedback from the ecosystem can be a good source of reevaluation of the direction to take. I am not saying my suggestion is the best way.

[sashko]

@emhmark7

wanting to acheive a project, as smootly as possible and if possible, with enjoyment of what they are doing. Meteor is aimed a being a tool for that. No?

Meteor is currently a great tool for that. I’ll be the first to admit that recent developments in Meteor have made the onboarding experience a bit more complicated, but it’s still the easiest way that I know of to get a full-stack JavaScript app built and deployed.

Anyway, there are two conversations here:

@aadams going on many threads to remind people of his opinion that MDG is not interested in working on Meteor anymore, which is far from the truth because our own business is built on it;

@emhmark7 talking about Vue integration, which I think is a great idea, but nobody at MDG uses Vue so we wouldn’t be able to build a great integration for it.

[emhmark7]

I understand your point in the fact that innovation comes from where it comes. But I saw project leaders such as for Drupal and Symphony choose to merge somehow. Whatever the value of their technology, I recognize the move is somehow admirable.

The point is that it helps when people agree in connecting their technologies, supported by their respective knowledge of their respective technologies.