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
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.
2 Likes
Automatization! (I want copying this solution to Vue).
v-bind - is field name of model, viewDoc & modelDoc - is read & write data via ViewModel & Model
@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!
1 Like
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?
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! 
2 Likes
@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
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.
1 Like
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.
1 Like
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.
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.
6 Likes
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!)
I think this means youāre far more qualified to build an integration with Vue than I would be.
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.
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.
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.
1 Like
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.
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.
2 Likes
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.
1 Like