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!
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.
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.
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.
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.
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?
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.
! Very promising.