Vue 2.x templates are just syntaxic sugar on top of render functions, just like JSX. At runtime, there is no difference between writing render functions, JSX or templates (see this package). The added bonus there are that templates can be compiled at build step OR at runtime, and that static parts of templates are hoisted from the rendering pipeline, meaning even better performance.
The whole philosophy of Vue is being progressive and incrementally adoptable. You don’t have to learn more than 20% of the api surface to start writing awesome apps or even just widgets for any webpage (for example, a PHP site). Here is an example.
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
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.
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.
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>.
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.
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 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!
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)
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.
@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!
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.
