Vue as Blaze 2.0

[aadamsx]

Thinking ahead to Blaze 2.0, I think we should be talking about somehow building off of Vue 2.0 https://github.com/meteor/blaze/issues/128#issuecomment-251184658 instead of duplicating efforts or talking ourselves in circles feature after feature, and getting sidetracked or bogged down.

We need to be looking at the big picture. Vue has the momentum in the broader JS community. Vue has the features we've been asking for and need. Vue has the performance. Vue has developers working full time on the project. Vue has tempting similar to Blaze. The only thing it's lacking is tight Meteor integration and maybe a sprinkle of Blaze flavor we are use to around these parts.

I think we should be discussing how to build off Vue with a emphasis on Meteor -- as a "Blaze 2.0".

I think the timing for a move like this is just right:

• Blaze community driven and looking for change.
• Meteor classic in a state of transition and flux, open to change.
• Vue 2.0 just release with a feature set and performance to be envious of.

[aadamsx]

Here's the official Vue.js 2.0 announcement.

A few highlights for the tl;dr:

• The rendering layer has been rewritten using a light weight Virtual DOM implementation forked from snabbdom.
• Vue’s template compiler is able to apply some smart optimizations during compilation, such as analyzing and hoisting static sub trees to avoid unnecessary diffing on re-render.
• Vue’s reactivity system is able to precisely determine components that need to be re-rendered in a large and complex component tree.
• Vue 2.0 maintains a largely 1.0 compatible template syntax with only minor deprecations.
• The templates are compiled into Virtual DOM render functions under the hood, but the user can also opt to directly author render functions themselves when they need the flexibility of JavaScript. There is also optional JSX support for those who prefer it.
• Render functions open up possibilities for powerful component-based patterns — for example, the new transition system is now completely component-based, using render functions internally.
• Vue 2.0 supports server-side rendering (SSR) with streaming and component-level caching, making it possible to achieve blazing fast renders.
• The engineers at Alibaba, the biggest e-commerce company in China, have been working on a project called Weex, which renders components written in a Vue-inspired syntax into native mobile UI.

Performance:

Roughly speaking, It seems Vue 2.0 has most things we are wishing for in Blaze 2.0 and maybe more.

[stubailo]

Why not just use Vue 2 if that's what you're looking for?

[msavin]

There's something that Blaze has that nothing else does: easy to use handlebars, natural HTML in template tags, no special syntax or attributes.

[laosb]

Maybe we just need a Blaze-compatible Vue 2.0 wrapper package :laughing:

[stubailo]

I'd be in favor of closing this issue.

[aadamsx]

I'd be in favor of closing this issue.

I'd like to discuss how we could go about testing out the feasibility of this approach to Blaze 2.0. Also, their should be no rush to close.

Why not just use Vue 2 if that's what you're looking for?

I like the Blaze api, but everything else about Vue more -- including and especially the feature-set.

[laosb]

I like the Blaze api, but Vue feature-set.

I like too. But I think it should be a Blaze-compatible Vue wrapper package which has similar API, instead of building Blaze 2.0 on the top of it.

[msavin]

I wonder if @yyx990803 https://github.com/vuejs/vue/commits/dev?author=yyx990803 could be persuaded to try this. It could bring at minimum thousands, maybe 10s of thousands, new developers into Vue ecosystem since, perhaps most of the Meteor community would prefer to see a Blaze 2 instead of a different framework.

On Monday, October 10, 2016, Wexpo Lyu notifications@github.com wrote:

I like the Blaze api, but Vue feature-set.

I like too. But I think it should be a Blaze-compatible Vue wrapper package which has similar API, instead of building Blaze 2.0 on the top of it.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/meteor/blaze/issues/131#issuecomment-252757356, or mute the thread https://github.com/notifications/unsubscribe-auth/AB7-g1e20eI7wacgIfzH9znrsy-X5pNhks5qyrUkgaJpZM4KO8g7 .

[Akryum]

@mitar mitar/meteor-blaze-benchmark#2

Vue outperforms React and Blaze, while being very close to manual DOM on my desktop. (I'll post results soon.)

[Akryum]

Result blaze other-table1 2398.5333333333333 15.82145998240985
Result blaze table1-other 571.8666666666667 11.514093959731545
Result blaze other-recursive 7040.733333333334 35.83678316932474
Result blaze recursive-other 3617 16.750540290213028
Result manual other-table1 151.6 1
Result manual table1-other 49.666666666666664 1
Result manual other-recursive 196.46666666666667 1
Result manual recursive-other 215.93333333333334 1
Result react other-table1 1019.8666666666667 6.727352682497801
Result react table1-other 203.86666666666667 4.1046979865771815
Result react other-recursive 2956.6666666666665 15.049202578893789
Result react recursive-other 686.2 3.1778326644025934
Result vue other-table1 316.06666666666666 2.084872471416007
Result vue table1-other 51.333333333333336 1.0335570469798658
Result vue other-recursive 412.53333333333336 2.099762470308789
Result vue recursive-other 218.46666666666667 1.0117320160543377

[Akryum]

Here I made a spreadsheet with more details and a chart: https://docs.google.com/spreadsheets/d/1gajp9ieaGiP7T-0tvO0U0XyRiINZ-rPn7vA4PZqst4I/edit?usp=sharing

[aadamsx]

@Akryum thank you for your contribution. What do you think is the feasibility of building a "Blaze 2.0" (aka successor to Blaze) on top of Vue 2.0 to some degree or another?

It sounds to me like both @mitar and @yyx990803 would be on board, think it can be done and would even help to an extent. Looking at your contributions and background you seem like the guy with the skills to pull something like this off.

[aadamsx]

@laosb instead of a thumbs down, would you mind speaking your mind?

[laosb]

Even I use Vue for my Meteor projects, I won't suggest using Vue as Blaze 2. If we use Vue, then what is Blaze? A wrapper? I don't think we should do it. A new package with Vue which is compatible with Blaze syntax is a great way but I'm against making a separated template engine become a wrapper package.

[aadamsx]

If we use Vue, then what is Blaze? A wrapper?

Yes, absolutely. Whatever you want to call it. Proudly and loudly.

.

I don't think we should do it.

Why again? This time with actual substance.

.

Face it, Vue 2.0 is almost everything we want and need from a Blaze 2.0. Why duplicate when we can collaborate and build on.

In fact, isn't this the new standard by which MDG lives by? One of the rationales behind the move away from Meteor classic? Why build it all internally, instead use the best of bread projects, use the wider open source ecosystem we are told.

This is what MDG has done with Apollo as well. Build off of a GraphQL foundation instead of building it entirely in-house and starting from scratch.

.

To boot Vuejs has the momentum outside Meteor, momentum to overtake Reactjs, and star-level developers working on it full time.

.

Have you read the Vue 2.0 feature set?

[laosb]

I guess we should have a vote on forums, shall we?

[mitar]

Why vote on forums? Vote here. Currently there are two votes for and one against. See above. But feel free to invite people from forums to come here and vote. So vote on initial comment in this thread.

[laosb]

OK so I'd post one.

---

Posted: https://forums.meteor.com/t/vue-as-the-base-of-blaze-2-0/30466

[laosb]

@mitar In fact https://github.com/meteor/blaze/issues/131#issuecomment-251722650 has 6 upvotes which means many people don't understand why we need to do this.

[mitar]

? Blaze around Vue would have all that from that comment. It would look the same as Blaze, have handlebars syntax and so on, only internally we would render with Vue for performance. And especially for getting all other features from Vue which are currently lacking in Blaze.

[tcastelli]

I think the only problem here is terminology (calling it Blaze 2 instead of being called Blaze2Vue 😆) since we all agree in that Vue 2 features are the ones that we want to have in Blaze2, and honestly I don't see the point in reinventing the wheel. As long as we keep the easy development flow that makes Blaze intuitive and fast to learn I don't think there should be a problem in how it works internally. I think that this wrapper could also be useful in terms of the global npm ecosystem for quick integrations with tracker for easy reactivity with Vue (once tracker and other meteor packages are moved to npm)

[rjakobsson]

This is a really interesting idea, indeed. Would love a easy-to-migrate path that would give me the performance of Vue.

[aadamsx]

Just a heads-up, it looks like @akryum as taken the initiative with a Vue-powered blaze repo:

https://github.com/Akryum/blaze2

Please let us know how/if we can help.

[Akryum]

Post from the forum

We could get the following while using Vue internally for Blaze:

• Very high rendering performance
• Server-side rendering with streaming, caching and re-hydration capabilities
• Template local state with optimized reactivity
• Template static parts optimization
• Cached, two-way (get, set) computed properties
• Templates custom events
• Template methods
• Two-way data-binding (for forms?)
• Using JavaScript expressions in template (if, each, etc.)
• Event listeners (@click, @keyup.enter, etc.) in template
• Locally importable templates inside a template
• <script> and <style> inside a template
• Template css-scoping
• Animation/Transition support
• Transclude content using named slots
• Async templates (lazy loaded at runtime)
• Extends other templates or use mixins to share functionality
• Use advantage of optimized vue-router (routing) and vuex (flux-style state management), with SSR support included
• Hot-Template-Reloading?

[Akryum]

Proof of concept

[mitar]

Proof of concept

Mind blown.

But maybe it would be easier to simply change this code?

So I would really like to keep the same parser, so that we can make sure we are fully compatible.

[mitar]

Hm, but there does not seem to have an easy extension point. It would be great if we could abstract parsing out from generating code. So that we would have two code-paths coming from the same input.

[aadamsx]

Awesome! I knew @Akryum was the real deal! Starting it up now!

[aadamsx]

So I would really like to keep the same parser, so that we can make sure we are fully compatible.

Compatible with Blaze 1.0?

[mitar]

Yes.

[mitar]

I do not know what Blaze 2.0 is. But this is for debate. If we can make Blaze work with Vue, that would be great. But why would we be developing Blaze 2.0 if we can just go to Vue, I do not really understand. So if somebody wants something new, not compatible, then they can just use Vue. If you want Blaze as you know it, with Vue for rendering, then you got with this new thing and should be compatible with Blaze 1.0.

[aadamsx]

If we can make Blaze work with Vue, that would be great.

Of course.

If you want Blaze as you know it, with Vue for rendering, then you got with this new thing.

Yes, this is what we want. I guess I'm confused as to what you mean by compatibility.

.

There may be a few bumps in the road, and just because there's one or two shouldn't mean we abandon this approach.

[laosb]

This makes sense to me now with more people agree on this. But in fact we can't do much on providing backcompat, I guess. @Akryum 's PoC looks promising, and I think we just test it out. If it can be used on 90% existing cases without code change I guess using Vue as the base of Blaze is acceptable.

[mitar]

So yes, but to assure compatibility at least in syntax, if not behavior, I think using Spacebars compiler might be useful. But I am not sure.

[priezz]

Let me join the discussion :) My first reaction was "Wow! Cool idea, I should upvote!". However after some thinking I have understood that I would like to change the subject of this issue to 'Vue 2.0 as Blaze 1.0'. The wrapping approach and keeping the full API compatibility with Blaze will definitely help to improve the performance of existing projects (for those, who really suffer). So it would be just the same good old Blaze with all it's advantages and disadvantages, but which works faster.

But why should we follow this wrapping approach for the "Blaze Next"? I agree with @stubailo, if you like Vue, just use Vue. If you like it, but some features are missing (which still exist in Blaze), why not to contribute directly to Vue development, extending its applicability? @msavin have mentioned nice to have features - "easy to use handlebars, natural HTML in template tags, no special syntax or attributes". Let's just analyze what is missing, consider is it really necessary for modern Meteor apps (probably the other, already implemented in the Vue approaches could fit better) and if it is add it into the Vue. The MDG marketing machine will do the rest to popularize the transition.

What do you think, guys?

[aadamsx]

Thanks for your feedback @priezz.

.

The MDG marketing machine will do the rest to popularize the transition.

MDG is NOT marketing anything related to Meteor classic anymore. In fact, afaik the MDG team has basically mostly moved off working on Meteor, leaving just benjamn at this point.

That's one of the reasons we now have this repo, MDG has released Blaze it to the community for any further/future updates because they're no longer going to be allotting man hours to Blaze. For the most part, afaik this also goes for Livedata/DDP/Tracker/Minimongo.

Us Meteor classic users have to fend for ourselves from now on. Part of that means doing exactly what MDG is now doing with Apollo -- leveraging the open source community.

To Blaze enthusiasts that means looking around for something we can built on, and that something to us is Vuejs.

.

We can keep the API we are familiar with and potentially in a short turn around gain all the features we've been begging for for years on end. Backwards compatibility, easier migration path, and oh yeah -- a ton of new features. Heck we could even potentially get bragging rights back over React in the performance department.

Simply put, why duplicate work, right?

For all these reasons and so many more mentioned in other posts above, I think this is the right move for the Blaze community.

[priezz]

@aadamsx,

As MDG is interested in the community, I am sure they will (and they do) try to pay users' attention at the new approaches, that fit well with Meteor.

Progress always means changes. Keeping the something's API unchanged means stopping the progress. So my question is, why to stuck with Blaze? Why not just move forward with Vue (which is really better in many aspects), if you like it so much? Why not to contribute to Vue instead of building the new bicycle (2.0 in the title always means new for me)?

For those who really want to stuck with the current Blaze API, wrapper is a good idea. But in my opinion it could be done once, called something like Blaze+ and never touched in order to add functionality.

I was happy with Blaze for about two years (well, in it's Jade incarnation), but for now I use it only when maintaining the previous projects (here Blaze+ would be nice, but is not the "must have") and will unlikely use it for any new project. Just prefer to move forward and change the stack, when more efficient solutions appear. I believe guys at MDG think similarly, that is why DDP, Tracker and friends are not under heavy development anymore and they pay more attention to newer solutions integrations.

And sorry, I didn't get, what have you meant when writing about the work duplication. Please clarify. Do you mean the contribution to Vue? If so, it is not more time consuming (probably less) than making and maintaining the wrapper.

[aadamsx]

As MDG is interested in the community, I am sure they will (and they do) try to pay users' attention at the new approaches, that fit well with Meteor.

So you're saying MDG will pay attention to us, and that will be marketing? Okay, great. But that's not our primary goal, as Blaze api is already apart of the documentation and guides and Vue has a life of its own.

Keeping the something's API unchanged means stopping the progress.

If you read these posts on here you'll see we are trying to be as backwards compatible as we can, all the while gaining new features of Vue. I don't think we are talking about stopping progress.

why to stuck with Blaze?

Being stuck is a relative term. Just because you consider using the Blaze api being in a state of stuck -- others might disagree, and further enjoy the api. To each his own.

Why not just move forward with Vue

Look at some of the posts above in this thread.

Why not to contribute to Vue instead of building the new bicycle

We are doing something similar to what MDG is doing by switching focus to Apollo and building off of GraphQL. We don't want to build a new bicycle, we want to use the upgraded bike called Vue with all the bells and whistles -- but just put our old Blaze handlebar grips on it. That's kinda the point isn't it?

Just prefer to move forward and change the stack, when more efficient solutions appear

Exactly, and Vue is is one of the more efficient solutions you should be referring to -- seems to beat out Reactjs in many aspects.

[laosb]

Besides technical problems, this proposal is more like a directional problem - does this means Blaze is dying in fact? If we use Vue as core, Blaze 2 will be a wrapper - or if you don't like my calling it wrapper - a backcompat layer for people on the way moving to Vue 2. That means no Blaze anymore. We should be aware if we are actually taking down Blaze or continuing to support it.

[laosb]

We should wait for more input anyway. Hard turn if we finally decided to make it so.

[stubailo]

If we are going to consider this, we should consider two more options:

1. React as Blaze 2.0
2. Angular 2 as Blaze 2.0

If this requires some transpilation to achieve Blaze-like syntax, why Vue specifically and not one of the above?

[aadamsx]

does this means Blaze is dying in fact -- labos

To me this means just he opposite.

With Blaze over Vue, we have the chance to breath new life into the API we know and love. It's keeping the API and gaining features and performance that matters.

.

why Vue specifically and not one of the above? -- stubailo

Just looking at one metric alone -- performance -- Vue beats out the competition.

[Akryum]

@stubailo That's a legitimate question to ask. My own pov on this is that Vue beats React and Angular in terms of performance, usability and it is almost in feature-parity (Vue is going to have a React Native equivalent soon, called weex). Vue also has the advantage over React to have official support libraries like vue-router and vuex.

Also, there is a Comparison with Other Frameworks page in the official guide.

[aadamsx]

The Blaze2 PoC has been updated with new things like easy subscriptions.

[tcastelli]

I also agree in that we should evaluate all those options @stubailo, but from my point of view, besides being more performant as stated before, vue is more aligned with what it was planned to do with Blaze 2. Anyway I'm not an expert in the three frameworks and I just talk from my own "testing" perspective.

Besides all of that, @Akryum has done an awesome work in a very short amount of time to demonstrate that the "wrapper way" with Vue is possible, while I'm not sure that we will find people interested in doing the same with Angular(own template system) or React(jsx).

But yes, let's listen what everyone has to say. Even if the decission is that Blaze 2 should not become a wrapper, I'm really excited about supporting the parallel Blaze2Vue project 👍

[aadamsx]

You should be able to create Meteor apps the old way with the last version of the experimentation with Blaze-style events map. Some Spacebars tags and other things like data context, helpers params and passing props are not implemented yet, but it has new features thanks to Vue.

@mitar have you had a chance to look over the repo lately?

[aadamsx]

Check out the Vue numbers within this post: https://medium.com/@sachagreif/the-state-of-javascript-front-end-frameworks-1a2d8a61510

Here's two graphs taken from the article:

The first demonstrating popularity and interest

The second developer satisfaction

[laosb]

Good job @Akryum! I'm wondering why you didn't publish your packages to give people a easier way to try.

[daquinons]

After playing a bit with the concept I only can say I want this. I don't care how it's called, Blaze 2.0, Blue, or whatever.

But I think that working on duplicated things should be avoided, so the idea of basing the future of Blaze on this has more positive than negative points for me.

[tcastelli]

Also have been playing a little bit with @Akryum last changes, and I really think it should become a published package, no matter what name it has. (Maybe something temporally before going for blaze2)