Hey folks, I posted some thoughts on why Blaze 2.0 needs to happen. I don’t think it’s realistic for it to become as robust as these other frameworks, but I think there are some reasonable improvements that can make it a lot better.
It would be great to hear what you think.
Nice article - couldn’t agree more about Blaze’s role in Meteor, and especially the part about how Meteor needs it’s own view layer. Blaze is indeed a great introduction to the stack, even if that means it’s less performant than certain alternatives.
I agree to some extend, but I don’t think it should be hidden. As Tracker and reactive computations is the foundation on which Blaze is built, I think it’s vital to expose it, as it is (in my opinion) one of it’s most powerful and unique mechanisms. I’m not saying that using Tracker is as straight forward as it’s implicit usage through for example helpers, but it doesn’t take a lot of work to understand how to use it correctly, and avoid side-effects.
Better debugging is definitely something that could improve the Tracker experience 
Isn’t Blaze just a dialect of handlebars with “some” implicit reactivity sprinkled on top? 
Isn’t Tracker just a dialect of handlebars
Nope! Tracker is a library for reactive programming, but it is not necessarily tied to your templates.
I’m going to edit “Tracker” into “Blaze”, as I mistyped xD oops!
I particularly like the lazy loading part (even though I think that goes way deeper down the rabbit hole than Blaze), because it would solve many issues about applications rapidly growing larger. I also think that it might help the mobile use case where we don’t want to automatically include admin screens meant only for the desktop, etc.
It would be great if the route could actually decide what is being sent to the client.
@msavin I’d love it if you discussed more how we can hide Tracker? You kinda lost me there.
My conclusions have been that if you “hide tracker” and perhaps use it to power Redux and an app which uses only unidirectional data-flow, then you might as well just get rid of Tracker. And that’s a very solid option. In fact, my research has led me to the conclusion that the best part of Tracker is in fact just the mongo style interface in your helper methods!
So one path is providing an interface within your component methods that mirror minimongo like this this.posts.insert({}) and this.posts.find(selector, options) but behind the scenes trigger Redux actions and intersect data placed in component props via Redux ;). And of course, Relay is likely a better backer than Redux.
THIS MAY MAKE IT MORE CLEAR:
class MyComponent extends React.Component {
allPosts() {
//notice how here we are not doing `Posts.find()
//this is because Redux (or Relay) already populated props with them
//and we are just extracting them from props under the hood
return this.posts.find();
}
changeTitle(id) {
//again, notice the usage of `this`
//that lets us wire everything up to Redux or Relay behind the scenes while
//keeping an identical interface to what the Meteor user is familiar with
this.posts.update(id, {$set: {title: prompt()}});
}
render() {
return (
<div>
{this.allPosts.map(post =>
<h1 onClick={this.changeTitle.bind(this, post._id)}>
{post.title}
</h1>
)}
</div>
);
}
}
From a Meteor developer’s standpoint, it’s almost identical to how they currently use Minimongo as part of the Transparent Reactive Programming scheme Blaze uses. But the way the data flows, is standard unidirectional Redux stuff. So that’s my conclusion of how we best “hide” tracker, which is basically getting rid of it, but keeping the best part, which is the Mongo finder interface. Oh, and actions are automatically generated for insert, update, etc, which result in your data stored in your Redux store, but look like standard collection methods.
The other options I see is to enhance tracker so it re-runs your functions less, and just use it part of Tracker React and call it a day. …Well, I’m kinda kidding. Basically we need to put a new “shine” on tracker so it feels as trustworthy as React + Redux. And by “shine” i mean build some truly solid tools that make Tracker-based apps debuggable. Some of examples of tool sthat would provide that are:
I think if we can make Tracker style Transparent Reactive Programming feel as trustworthy as the unidirectional forceUpdate stuff then we may have something the industry will respect up our sleeves. As Tracker currently is, we get no respect in the greater JS/NPM ecosystem. So we gotta lock these things down, and then position it as an option that plugs in nicely alongside the unidirectional stuff within React, just as Mobservable and TrackerReact do.
Hey @faceyspacey, my thinking was far simpler: I just mean’t hide it as in take it out of the official documentation and discourage it’s use. Make it an internal API so that people don’t fall for its traps. Maybe release a guide for advanced developers on how Tracker works and what the limitations are.
Combined with the addition of incremental loading, Blaze users would have less problems and would be able to stack on any library they want. I think this makes Blaze a lot more solid and if it’s development were halted, this would be the mark to do it on.
Then, if MDG wants to build a new front-end solution based around React + new data layer + etc, that would be cool, but that I think would be like a 2.x release, while the 1.x release can be sufficient for the stuff we’ve been using it.
But then how would Blaze reacrively update? It depends on tracker to reactively update somewhere. Even if it was just in the router and u trickle all data down as props, the router is still using tracker.
Tracker should still be in the core, but it’s use shouldn’t be advertised.
You explained it pretty well in one of your blog posts:
Let’s get back on track…What’s preventing that predictability with Tracker I’ve discovered to be precisely this: its autoruns are triggered more than it should be. The reasons:
- developers don’t use the
fieldsoption to theirfind()calls.- developers combine multiple, but unrelated, data sources in a single autorun
- autoruns re-run when changed dependencies have no effect on the main output
- autoruns re-run when data dependent on doesn’t even change!!!
The easiest solution, then, is to “remove” the option to do that. People can probably achieve whatever effects they want through other means. To clarify, I’m not saying Tracker should be removed from the code, it just needs to be removed from the documentation and reserved for Jedi Masters.
In other examples of this kind of design, think of the oplog tailing. If we had access to the oplog API, people would probably start triggering all kinds of events around the server database, kind of like they do with Tracker on the client-side database. That would probably open up a new class of problems, and then people would say “this is buggy crap.” Instead, it’s quietly tucked away… so I am advocating we take a similar approach of tucking away Tracker the same way we tuck away oplong tailing and other stuff.
On another note, it’s pretty cool to think of Tracker and LiveQuery as client and server counterparts. Maybe the solution to Tracker is to package it as a “LiveQuery for the Client.” Instead of tracking everything, it lets you observe minimongo and call a function when a specific database action happens. Hmm, maybe I’ll test it as a package this weekend.
I’ll add for emphasis: there has never been a case where I needed to use Tracker or tap into LiveQuery (Meteor brand for oplong tailing). It may be convenient at times, but it feels a lot like a hack to use it. I do love Session/ReactiveDict/MiniMongo.
Excellent point of view. It is really hurting the case MDG fails to see the logic at this point. No idea how to convince them though… they seem gone into space lately…
@lorinthe, feel the need to understand where MDG is coming from? Try this thread, where Geoff himself speaks to their rational and future general strategies in some detail. Looking forward to reading their feedback on Blaze and Tracker specifically.
To be fair, he hasn’t addressed Blaze yet… But I’m excited to hear what he says.
Geoff suggests a couple of days… so we will know soon I suppose. Interesting to see by the way that this is as far as I know the fist time MDG’s management reacts on the turbulence: the word “fork” did the job I suppose?
Haha I found that odd too.
In other news: https://voice.kadira.io/sneak-peek-mantra-7161624acaa7#.fexy3kj87
Just noticed Kadira wrote “Right now, Meteor is a mess. Frankly, this is a really bad time to start a new Meteor app.” Coming from one of the greatest contributors since the beginning, well… it sucks, let’s be honest.
And we need to start yesterday with a complete new app… pff
I definitely do think 1.2 is kind of stranded right now. There are no modules, and the only way to get that to work is to bring in a whole lot of scaffolding. Right now, I am working on a project with Meteor + Webpack + React and I can’t help but see that it’s simply not going to age well.
1.3 will make things a lot better, as will all the tools that follow (read: Mantra). But before that happens, we’re kind of in a weird zone.
But you do need Mantra traction from the community. No matter how good you make it, without some mass behind it, it still worrying about how Mantra will age…