Vue as the base of Blaze 2.0

Originally posted there by @aadams:

Thinking ahead to Blaze 2.0, I think we should be talking about somehow building off of Vue 2.0 #128 (comment) 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.

How do you think about using Vue as the base of Blaze 2.0? Please vote on the issue and feel free to discuss about it!


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?

The real question is, why not use vue directly? To have curly braces instead of attributes?


For the one who wants to keep the Blaze syntax and separation between templates and logic, to have a easy migration process, and not have to relearn something entirely new?


The real question is, why not use vue directly? To have curly braces instead of attributes?

I would also say for easy template subscription management and reactivity with Tracker by default.

Maybe calling a “wrapper” Blaze 2 is not the best idea, but sincerely, if all the features that we want in Blaze 2 are already in Vue and there’s the possibility of using Vue as the render engine for the Blaze syntax, I don’t see why we should reinvent the wheel. Just my 2 cents.


You guys should make vue first class with meteor and apollo. A variant of vue with meteor blaze sweet sauce -vue- blaze.

+1 let’s get started!

1 Like

@akryum do you mind reposting your list inside the issue as well please? I think it would help. :slight_smile:

This is one of the reasons why I would like to take the Blaze over Vue approach. I think the repo would get tons of traction and support from those looking to finally, after all this time in limbo, get a real update to Blaze.


Great points all around here.

1 Like

I am still forming an opinion. I think that on paper it seems promising, but in reality we might not really be able to achieve full compatibility. And then we will have painful small breaking changes to consider.

But let’s see what community thinks.


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

Please let us know how/if we can help.

Blaze is in mature state. It needs some innovation to prevent declining or even dying. Adopting the beauty of Vue should be enough to extend life cycle. Just like Meteor adopting GraphQL. Why not use GraphQL directly? Because I like Meteor way.

If this succeed, Blaze 2 much more attractive than Vue.

I would say this is the smart way to win the competition.


Hey, just did a Proof of concept in a few hours:


This is a solid observation. Indeed has merit.

Wohoo :smiley: ! Very promising.

Am I the only one who thinks we already have more than enough Front End frameworks? I mean, let’s either use Vue or Blaze, but please don’t merge them to build a new one.


If you need precedent for this, look at none other than MDG itself. Instead of building everything in house, they’ve decided to “embrace and leverage” the community with their Apollo strategy (build on top of GraphQL).

Besides, the Blaze community is very long overdue for some much needed upgrades, and Vuejs will provide them in spades. In fact, maybe Blaze will get back much needed bragging rights on the performance front.

I think for the longevity of having an HTML-based framework it would indeed make sense to stop duplicating our efforts.

Can we dice up the brainstorm into streams to we can think through them well:

From a risk perspective:

  • How active is Vue development – probably a silly question given how popular it is, but we should ask the question
  • Once we stop working on Blaze, there is no going back, as key people will move on. We saw this with MDG, when there was a staff change we couldn’t get answers to some Blaze questions (we had to manually go through the code)
  • Will we lose or gain developers in the process?
  • Why not ViewModel? Is it because it’s local vs. Vue.js?

From a business perspective

  • Will we keep using the term Blaze? I am asking as it does have some following, let’s not lose those people. Maybe call it Blaze2 or BlazeVue2 (i.e. it’s clear that there is some departure – sorry if 2nd is silly name).
  • Can MDG publicize this with us (on their blog and we can reach out to the Vue folks --> this could drive some meteor adoption there as well, as universe is made up of more than just React)

From a technical perspective

  • I had to dive into Blaze code to see if we can improve performance (maybe use IncrementalDOM). What I saw impressed me. This view layer has to be faster (excluding the buggy diffing done externally) than React and Angular. It litterally parachutes very focused changes into the HTML DOM. Does Vue do things similarly?
  • Are we dependent on Tracker/ livedata? Can the community take it over too?
  • GraphQL integration?

Just some thoughts, please free to chime in!



I vote for Blaze2. Retro-compatible with Blaze, but with fancy new features.

That would be great, and I don’t see why they wouldn’t.

Do you have more specific examples? Vue has a lightweight virtual-dom implementation, but with lots of possibilities to manipulate the DOM.

We could, there are Tracker integrations for Vue like the one I made and I use in the PoC.

The Vue backend could use vue-apollo.


What Blaze does is keep handles to DOM elements that need to be changed reactively. So when a change comes in from Tracker, it compares with prior version and then affects DOM element only when it needs to. I expect this to be faster than VirtualDOM and IncrementalDOM. This is welcome by-product of meteor’s design of reactivity.