Ability to Write JavaScript and Templates in same file
More Granular Controls for Tracker/Reactivity/Rerendering
Better support for form binding and validation
Move to NPM / support using Blaze with other build tools
Ability to lazy-load templates
Scoped, importable templates
Implementation of Incremental DOM
0voters
There’s a new team forming around Blaze with many new ideas. I thought they might like if we show them which updates we hope to see the most with Blaze. Maximum of 3 votes per person
Please, instead of using the poll above, come instead to GitHub and upvote/downvote ideas in this ticket:
You can also add your own ideas. Do not discuss ideas there, open new tickets for discussions. But you can add clarification questions and propose alternatives. But do not discuss implementation details.
Agree with @mitar here, Can you take polls in Github or otherwise link to an external poll of some sort? You really want to take the opinions of devs that are using Blaze right?
I wanted to comment on Incremental DOM. As someone who took on this task (see #45) and tinkered with the internals of Blaze (see PR here)
Blaze if very well built. It affects in the DOM only what has changed. So it’s already doing what Increment DOM (idom) is doing. When using idom, you are supposed to create your HTML with their api, then patch it up (with same api) and it takes care of rendering for you.
That’s already done by Blaze (they were ahead of the curve).
Where it does not do a good job, is that re-renders too much and the comparison it uses (it creates a DOM element and compares against it) is expensive. When we fixed that in Blaze itself, adding a deep comparison function, speed went up. Way up on mobile. We monitored the number of already-created objects we skipped and it was substantial.
So I recommend we drop Incremental DOM - at least for now. There is no real benefit. Let’s fix diff-ing.
Moment of truth: To do things right, we should be fixing the diff-ing algorithm used, not adding another one like I did. But that’s a bigger job. So for now, this PR will result in improvement until we can get to it.
I hear you there - agree, Blaze was way ahead of the curve, and I find the rendering system to be very good.
I’m hearing a lot about React performing better, but am reading a big problem lies in the APIs built on top of Tracker, particularly with Reactive-Var and objects. Maybe what we really need is smarter tooling built on top of Tracker.
On a side note - when Crater.io was updated, a lot of the performance boost was attributed to switching to React, but it’s important to mention that we do not know how well that theme was implemented in Blaze, and that there were database optimizations as well. Blaze rocks
Agreed. I do believe Tracker and its diff-ing engine need work. For instance, it was built for Mongo, with a focus on _id. It also does not go deep enough in objects to clearly identify what changed. Likely it was enough for observe and observeChanges but not detailed enough for a templating engine.
Maybe we need a completely new diff-ing for Blaze - This repo is simply amazing and would do the job great.
Nice. Is it a fair observation to say React may perform better than Blaze in Meteor because with React, you are passing data down from a top component, thus, tracking far less dependencies?
Yes, we are stopping as the purpose of achieving improvements has been fulfilled. You won’t get improvement from Incremental DOM. Just like @msavin commented, the reason React was faster than Blaze lies elsewhere (in the diff-ing), which we worked around.
I don’t think so (can’t say for sure as I don’t know how React works internally).
With Blaze, you use reactive variables, the changes of which are injected directly into the DOM. Blaze knows exactly where that variable is located in the DOM, so the swapping is blazing (pardon the pun) super fast.
I think with React, it should be the same thing. Likely that React remembers where each function’s JSX returns fits in the Virtual DOM and can diff locally (in the Virtual DOM, so faster than actual DOM at the expense of memory).
In IDOM you can chose which element to affect, so it can diff locally too. However, the diff-ing is slower as it a DOM-diff (which is what Blaze did before my change, it would render a DOM element and compare) and is computationally expensive.
Technically, I expect Blaze to be faster, as we are diffing variables in JS, not DOM (like IDOM) or JSX (like React). But I am shooting from the hip as I don’t know how React diffs (maybe it diffs variables too within the Virtual DOM).
Lol, you stopped half-way through. Just because you observed optimization you think you are done? Of course is faster if you improve reactivity. But it is just partial faster from what it could be.
Again, every code has much more data than DOM. Data >>> DOM. Because humans have to process DOM. And we are limited in how much information we can take in.
So diffing at DOM level instead of data level means that you have to diff much much less. React observed this fact and discovered that it is faster to just compute everything and diff at the end.
Blaze is great because it has also low-level data management. So we can have the best of both words and leave to developers to tweak things as they need. But diffing only at data level will never be as fast as React. But combining those two things, that could be the most powerful thing ever. Especially if you can tweak them to optimize for a particular use case.
I talked with Pete Hunt (creator of React) at length about this when we organized his talk at Berkeley.
(We also had Matt from Meteor over. It is really interesting to compare those two views, especially now in retrospective.)
That’s why I am suggesting we should be doing diffing at the HTMLJS level. Remember old HTMLJS, diff, apply changes. That could even lead to long wanted feature: callbacks when Blaze changes something. From diff you could exactly know what changed and call callbacks for that.
Of course the downside is that you cannot use 3rd party things then. And this was a design consideration with original Blaze, when jQuery was very strong. I think it is a powerful thing to have, so we should create that you can switch this HTMLJS diffing on or off as needed. Some templates you would use diffing for, and for example you would not be able to use template.$ for it.
But we are repeating again things from GitHub issues and this is bad because arguments are being lost. So I will not comment here anymore on this and let’s move discussion back to GitHub again.
Diff-ing at doc level will always be faster (unless the developer is providing more fields than needed). It’s a gift that Blaze gave us to be so low-level. And if we wanted to, we can diff only right at the end before a field is about to change (so we diff String, Number and Boolean vs Object). My PR does both checks (at the doc level and at the field level).
The challenge of diffing at the end is that you ran so many lines of code before getting to a field, diff-ing the source doc could be faster for unchanged objects – but that part will be flushed once Tracker is improved.
Even if I am wrong, we are 80% there. We have more important things to fix before we get to that last 20% (if it indeed exists) and start looking at semantics (and whether we can dispense with jQuery and the like).
Which is always? Because it is so painful to have to specify fields at Minimongo query, which you can then use in the template somewhere completely else and you have to keep those in sync.
We should really stop using of Minimongo fields and make use of JavaScript getters to register dynamic dependencies on fields as you access them, if you do so, in a template.
So yes, you can try to limit reactivity with limited fields, but it is really painful and is destroying logic/template separation.
So all those points you are mentioning are true. Those are points on how to optimize Blaze today. But we are discussing Blaze 2.0. The future. And in the future developer would not have to be doing those things.
Blaze 2.0 should be fast even if developer is doing bad things and are passing all data around. And it should have features to tweak things for those who want more control.
This is why Blaze is neat. Because it is easy for beginners. And sorry, limiting reactivity with Minimongo fields is not easy for beginners.
If we were in the world before React existed, I would maybe believe you. Now it is clear that this “intuition” you are having is plain wrong because React is doing exactly what you are saying that will not work, and they are doing it very well. So if you want to convince anybody that you are right you will have to show some numbers. For that you will have to implement HTMLJS diffing or incremental DOM and then show that you are right.
Ok, let’s fix Blaze 1 so we don’t lose people and then we can implement things right.
People want improvement NOW. If we lose users there will be no one left to work on Blaze 2. Many who switched to React are not returning because they have a working toolkit, we need to have a working toolkit today.
