Vue as the base of Blaze 2.0

[mitar]

Vue 2.x templates are just syntaxic sugar on top of render functions, just like JSX.

Same in fact how Spacebars compile templates into Blaze render function.

[wecare]

Because of the syntax. Most of the people get started with meteor use blaze. And if use vue directly, the learning curve will be too high. Adding options for react, angular, just kill the simplicity of meteor

[gusto]

Imho, Vue has actually easier syntax than pure Blaze, so I cannot see that as killing the simplicity.

[Spyridon]

Not trying to be too pedantic, but the sentence

We expect a future release of Meteor will turn on modules by default for all code …

really implies that there will be an option to not enforce the use of module imports, just that sometime in the future it may not be turned on by default

I really believe that people tend to read too much between the lines… I expect that applications developed using pre 1.3 will continue to work very much as they were written for a long time.

Understandable why you can interpret that sentence in that way.

But I’m not just going by that sentence, but also the discussion that was around when 1.3 was released. I actually learned the backwards compatibility was temporary through the forums, and at the time, even MDG was saying it was temporary in order to align with JS.

Which is why, if that changed, I’m hoping for a solid confirmation specifically about that issue.

Backwards compatibility is a huge, broad issue. I’m happy to know MDG is doing their best on it as a whole… but imports is something that we were warned for in the past, that may or may not have changed.

[mitar]

To be a bit more on topic again, and more constructive.

I just finished porting Tracker to Vue’s observer. Vue has a similar concept to Meteor’s Tracker and it is so similar that mostly there is just API difference, while semantics are the same. I made a Tracker API wrapper around Vue’s observer. It is 100% compatible with Tracker. Now one can use all Meteor code directly in Vue and get all reactivity you were used in Blaze, with all benefits of Vue.

For now, it requires a forked version of Vue. Pull request is here. Please upvote it to show support.

More of my ideas of how I think Vue could be integrated with Meteor is here: https://github.com/Akryum/vue-meteor-tracker/issues/3

Feedback welcome. Help as well. I slightly remember that somebody already did a version of Minimongo which uses getters to register dependencies on Tracker, instead of having developers specify fields precisely to limit the reactivity. Does anyone remember that? Or maybe I was just pipe dreaming.

Blaze 2.0 could then be just a syntax preprocessor for Vue, similarly how Jade is already supported. Search for “jade” here. So one could do <template lang="blaze"></template>.

Example app: https://github.com/mitar/vue-test. Notice how I can use Meteor ReactiveVar inside computed value directly.

[lassombra]

I slightly remember that somebody already did a version of Minimongo which uses getters to register dependencies on Tracker, instead of having developers specify fields precisely to limit the reactivity. Does anyone remember that? Or maybe I was just pipe dreaming.

I talked extensively about a closed source project I did that with. I haven’t open sourced the code as it was never made to be widely consumed and it doesn’t play nice with other tools that people have created to manage mongo schemas.

I could open source a trimmed implementation (without all of our API connection crap) that you could run with if you were interested.

[efrancis]

it never hurts to throw it out there even if it’s only usable by you in its current state, if any part of it’s helpful for someone else they can either contribute or fork it

[mitar]

I would love to see how you did this. And then see if it can be reused or at least be inspiration for more.

[aadams]

I just finished porting Tracker to Vue’s observer. Vue has a similar concept to Meteor’s Tracker and it is so similar that mostly there is just API difference, while semantics are the same.

I read through your comments on the vue repo and more regarding your efforts on this. Thank you! I just hope @yyx990803 will crack open vue just enough to make this happen!

The PR on the vue repo: https://github.com/vuejs/vue/pull/4652, please everyone upvote there to show support!

[lassombra]

@efrancis

it never hurts to throw it out there even if it’s only usable by you in its current state, if any part of it’s helpful for someone else they can either contribute or fork it

I wouldn’t say never hurts. There is a decent time commitment on my part to put this out. I wouldn’t want to do so if it wouldn’t get used at all.[quote=“mitar, post:154, topic:30466, full:true”]
I would love to see how you did this. And then see if it can be reused or at least be inspiration for more.
[/quote]

I’ll try to get something up by the end of next week for you, and I’ll post it here. It’s gonna be fire and forget, I am not offering really anything more than providing the code sans our internal api craziness. (which we are moving to a graphql solution for)

[mitar]

@lassombra: Any update on this?

[robertdavid010]

Great post. Have been using Blaze for over a year, and had to solve many issues on my own. I agree on performance potential, having witnessed it first hand as well.

Also patterns and workflow of Blaze are what make it a preference to me (also the “trap” in the Facebook TOU for React kept me from going that direction).

I feel like actually the biggest problem with Blaze is that a lot of its features, functionality, and best practices, are not as explicitly defined as they could be. And I think addressing this is actually probably the only major stumbling block for developers using blaze. However any improvements are welcomed, but when it comes to Vue, its templating syntax is nowhere near as unituitive and simple as raw Blaze. I think it’s overkill to try and merge Vue into Blaze.

[efrancis]

(also the “trap” in the Facebook TOU for React kept me from going that direction).

fwiw that’s not true anymore

[robertdavid010]

Will try to confirm. Althought not really interested in React. Several anti-patterns it seems to me.

[aadams]

12 days ago Evan You added the “pending” label to the all important PR https://github.com/vuejs/vue/pull/4652.

@mitar, can you make out if this means he’s interested in accepting it? If this is accepted, what else is required for this initiative to move forward?

Also, everyone that’s interested in seeing this come about please post an encouraging response on this PR!

[mitar]

If this is accepted, what else is required for this initiative to move forward?

On my list of features I think only better integration with Minimongo is missing.

Probably somebody should make some benchmark first to see if we even need anything fancy for Minimongo at all. Maybe just doing Collection.find(query).fetch() and leaving to Vue to do the diff between new and old versions could be good enough. But my intuition is that it would still be good to limit reactivity invalidation at source, Minimongo.

@lassombra said that they have some code for Minimongo. I am waiting to see it and see if we can reuse it.

Otherwise, for normal reactive variables (like for keeping internal state of components) it already works.

[gusto]

Will this Tracker integration be available only with Blaze syntax or also with Vue syntax? Will it affect Vuex in any way?

[mitar]

This does not prevent anything else to be used. It just adds that Vue recognized Tracker-based reactivity as part of its reactivity.

If anyone makes a preprocessor to convert Blaze syntax into Vue, then you can use it for both. I am not planning to do it.

I am not familiar with Vuex, but I do not see how this could interfere.

[aadams]

I could open source a trimmed implementation (without all of our API connection crap) that you could run with if you were interested.

@lassombra, did you ever get around to OSing a trimmed version for us?

[aadams]

@mitar, if your PR (https://github.com/vuejs/vue/pull/4652) does not get accepted, is it a reasonable path to fork and apply to the PR to that? We can then pull in your forked version on our projects as a solution?

Heck, why not try that approach now? I’d like to give it a try on my project for one. If the PR ends up being accepted, we can always switch over to the main fork.