Blaze to React wrapper (for package creators)


What can package creators expect from the Blaze to React wrapper?

Just to be clear I’m not looking for an (ahearm) “Official MDG Press Release”, only your feel for how things will turn out. A reasonable expectation if you will. In particular I’m interested in:

  • Is it going to be supported in the long run? (will it be updated if React’s interface changes)
  • Will we be able to add onCreated/onRendered/onDestroyed/helpers/events to templates?
  • How about custom helpers (Template.registerHelper) and something like onViewReady (to run a function after the custom helper is on the page)?

That covers pretty much everything I need to keep ViewModel going.


1 Like

Geoff’s post may have left the impression that there’s going to be a standalone project like “Blaze 2” that wraps React as the underlying implementation - however my honest expectation is that after the view layer transition, package authors should consider React as the baseline, where the template layer, if ever built, will be more like an optional mixin or addon to React. We don’t want to reinvent a system that is neither Blaze nor React.

We just had another round of internal discussion this past week, and I will post something explaining it in more details Monday.


Oh man… the overall chaos is killing me… this isn’t helping…

this meaning the chaotic envorinment that Meteor (for me) currently is, by MDG dropping things all over the place :smile:


Well, putting it politely, I’d say that’s understatement.


An understatement indeed…

What would be great is if you could get the best of both worlds: Blaze-style reactive templating, combined with the component model of React and full compatibility with the React ecosystem.

So what we’re planning to do is to build templating on top of React, and to encourage Blaze users to upgrade to it (or, for those that prefer it, to plain React JSX). We think that this is the best possible “Blaze 2". If you choose to upgrade you’ll have to port your templates, but that’d probably be the case no matter what direction we go with Blaze 2.


That’s an understandable decision, given the ramifications:

  • react developers might not easily be able to port their components to Meteor
  • and Meteor developers might feel uncomfortable by being boxed into a custom solution

However, conversely, Meteor may go from being an “isomorphic” framework to just a server side framework if Tracker is replaced by a purely functional approach not their own, and the only remaining remnants of Meteor on the client is subscriptions and ajax calls (i.e. all “Meteor methods” really are). I’m not sure MDG recognizes the ramifications of that. Basically it means this: the next logical thought is forget Meteor, I’ll just use RethinkDB with React/Redux on bare metal NPM. And that’s the end of the story.

As I suspected, MDG would take the “safe” approach. It’s an approach that I predict will hurt Meteor drastically. I know you imagine all these view layers, and being able to inter-opt with them all, especially since you yourself made one of them. However, I think 80% of your customers (i.e. Meteor developers) will want React, and 20% the other options. Meteor specifically targets intermediate developers looking for that 80% good enough solution across the largest swath of the stack using the most popular tools. So in short, you’re giving 80% of your developers nada, zilch, zip, if you’re focus is to provide many view layers, rather than do just the one they really want [React] extremely right. I and many of us wanna see something fantastic and Meteor-specific in terms of the view layer, not just what everyone else has, namely plain old React (plus Spacebars). This is basically the message that everyone in this forum is saying if you read between the lines. If you tell everyone: “look we got this kick ass Blaze + React approach, the crowd goes wild and all your Meteor developers are excited.” You could even pass on transpiling Blaze 1.0 at that point and be let off the hook. I hope we can come to more than an “agree to disagree” situation this time–but that’s my prediction here; that’s what they want. It seems MDG is hell bent on not giving that to them. It’s a case of: Startup knows better than customer, remains unwaveringly focused on their mission. I’ve been in this business for over a decade–I get it. It just would be nice if somehow some resources could be allocated to this approach…

As an aside, there already is Jade templating for React for example–it’s nothing special if we also get handlebars.

That all said, there’s a silver lining in the sky. I’ve put a lot of work into that “hybrid” approach you forewarned about. The first part was TrackerReact which is already out, which you have likely seen. I’ve got a lot more I might as well just put out there this week. Collectively it’s called Meteor.Component, eg:

class MyComponent extends Meteor.Component {


…it’s late for me, but I wanted to make sure I responded to you here before I went to bed…Evan, i’m going to show it to you real quick right now cuz I know you guys are about to make an announcement–maybe it will factor into what you guys are thinking. Here’s basically it:

I’m doing some transpilation tricks here in my own version of the React runtime:

it’s currently done with a regex, but will be replaced with a babel plugin I wrote which directly transforms the AST.

and here are the mixins:

those mixins will be incorporated in Meteor.Component in the next stage, which will be a drop-in replacement for React.Component (and won’t require actually including the mixins). Yes, I know, React itself is moving more towards “higher order components” in place of mixins and the like–but I think a flat class is something we’ll be able to maintain for a good long time regardless, and exactly what Meteor’s target customer is most comfortable with. …There are a few more mixins such as AutorunSubscribe, etc. It will very much be the Blaze 2.0 people everyone imagined in the back of their head, but in React. It will be a crowd-pleaser.

NEXT: I’d like to show you the versions used by the Sideburns project which replicates the Blaze 1.0 behavior:

That’s actually the more important code that you guys should look at. Basically, you can truly compile Blaze 1.0 to React. 100%.

I’m not sure why MDG wouldn’t want to do that.

As for the hybrid approach going forward, it may work out very well for us if you guys stay near the base-line while I scout out riskier territory where MDG wouldn’t want to promise too much to their developers. After all a lone developer like myself can promise Blaze 1.0 transpilation and fail and not much will happen to me, whereas a well-funded company like Meteor could get itself into some serious trouble if they did that–I get it. However, i think there’s some opportunities for some collaboration. For one, spacebars transpilation to JSX desparately needs your help–and that’s something you guys are promising too. The regex approach Tim Brandin has been using with Sideburns won’t work. At this point, spacebars transpilation to JSX is the only missing part. If you examine the last 2 links above, you will see that. My hope is you examine that and triage helping us with Spacebars transpilation to the front of the line.

So in short, all Blaze behavior is proven possible to replicate–yes, via hacks–in React. As mentioned, I get why MDG wouldn’t wanna get behind that. My suggestion is: empower me and let me be the fall guy. See what I’m saying.

Final Thought: Tracker has a magical implicitness to its abstraction that functional approaches make up for in predictability. I think if we could make Tracker and the patterns to use it more reliable, then we could compete with React and Redux. I think if we could make both fit nicely together (i.e. TrackerRedux) where developers could choose either for granular parts of their app, then we’d have a better option than either on their own. One of my ideas for improving Tracker is using a transpilation build step to fill in finder fields, i.e. {fields: {foo: 1}} based on “property level cursors.” So basically when transpiling spacebars, we determine which properties of a model are accessed, and then automatically go back and fill in the initial find call with those fields. I’m bringing up this example because the biggest problem with tracker is that it re-runs functions many more times than it needs to, and the biggest culprit is that nobody uses the fields option to constrain reactivity. The next idea is snapshotting Mongo and using the oplog to produce Time Traveling functionality. Totally doable–I just gotta get to it.

I’ve put many hours thinking about how to optimize Tracker/minimongo so it can compete with Redux. What I just mentioned were a few examples of many I have to optimize Tracker. I’m not sure if MDG internally feels that Tracker has some terminal issues with its reliability that make them willing to throw it out. It does throw exceptions that have nothing to do with anything you did wrong every so often. My goal is to essentially build an environment where Tracker runs less, developers have tools to constrain it’s behavior, and functional programming can be easily intertwined where its explicit predictability is needed. I think that’s a sound goal–unless MDG plans to ditch Tracker because of “irreconcilable differences” lol. You tell me.


@faceyspacey thanks, I really appreciate the effort. It is true that we don’t want to commit to a 100% Blaze-to-React compilation project, and you already understand why (if we had infinite resources we would definitely do it, but…).

I’m glad that you are willing to step up and take this challenge - and I think it would be great for all current Blaze users if it works out. But I’d like to focus on what value we are trying to provide here: in the long run, it’s better for everyone to be leveraging raw React for its ecosystem. What I consider most valuable from your work is the potential of auto-transpiling existing Blaze code to React code and just go from there. This would be a great migration path. I’m not sure if we really want to stay in the middle (i.e. an API that is neither Blaze nor React).

In short, I think our strategy will be align with React community’s best practice, but provide opinionated (but compatible) configuration/components/guidance as part of the framework. I’ll be honest that I don’t know what role Tracker is going to play in that world - fully reactive render functions is pretty much the opposite of what React promotes: contain your data source, make dumb and predictable components.

As for Spacebars -> JSX transpilation, have you thought about working on top of the Spacebars compiler? That’s what I did in my experimental branch. I mean we already have the parser/HTMLJS (somewhat like an AST)/codegen in place, that should be much more robust than regexes.

Fianlly, re: where Meteor’s value is after the view layer transition: I will explain more in another post.

1 Like

Thats exactly the conclusion I’ve come to about the best way to approach it. I actually never did any of the spacebars transpilation work. When I stepped into Sideburns I realized there’s a big difference between transpiling spacebars and replicating Blaze behavior–so I set out to prove we actually could replicate the behavior. And we could. Now that I’ve circled-back to spacebars, I’ve researched another Handlebars to JSX repo in the works and a few other options, including your experimental branch, and the Spacebars compiler is most definitely the way to go. That’s why I was asking for your help. Maybe it’s best we talk privately about that one. But I’ll be honest, my first forays into transpilation have been just these past few months building build plugins using regex and my first babel plugin last week. I’m down to tackle any problem though, including Spacebars compilation, but I may need you to kickstart me. At the same time, if it’s something you and MDG can just crush once you can allocate the time, that may be the better option. At the same time, I actually really do wanna master this sorta skillset. If you can give me a well-documented initial assignment to get me started where you left off, I can get going this week. I currently work exclusively on open source Meteor packages (got a framework on top of meteor I’ve been working on for exactly a year).

ps. looking forward to hear where the value will lie after the “view layer transition.” Obviously, I’m a Meteor-lover–been using it since the start. It would be interesting if Meteor found a way to double-down on Tracker, rather than just succumb to the functional pressures of the rest of the NPM ecosystem. Here’s my article on that topic from last week: …not sure if you read it. But basically my hypothesis is Tracker is in fact good, and it doesn’t need to be one way or the other (functional or not). I’ve figured out how to play with the data structure of React component instances for example, all while functional operations flow over it. And ultimately it really isn’t that hackish what I’m doing. Otherwise, there are ways I have in mind to automate the work of Redux while maintaining its predictability. I mean just think about it: Redux has you create actions where you would call collection.insert with Minimongo, and then bind stores to components where you would simply declaratively use the data you need (Tracker). Tracker + Minimongo saves you 3-5 steps that you are doing with Redux. All we need to do is solve the “traceability” problem. I.e. the problem where nobody knows what’s triggering their autoruns, cycles, etc. I think getting to the core of the problem isn’t just replacing Blaze with React. That’s akin to sweeping the problem under the rug, or shooting your own son in the back of the had if you’re willing to just get rid of Tracker. Getting to the core of the problem is making Tracker + Minimongo (and ReactiveDict etc) more predictable. There’s so many things we can do here, a few such ideas I mentioned already. But I really do got a lot more. I’d love to share em with MDG and generally get a feel if it’s worth me investing my time in salvaging tracker. I don’t wanna waste my time if MDG has it slated for the chopping block lol. Anyway, you get the idea. Hit me with some insider tips, i can help.

1 Like

That’s it. You nailed it. This is what’s truly missing from Blaze and when we “boil it down” the real value from React standing on its own.

1 Like

But is easily solveable with tracker. I honestly have fell in love with all these tools, i.e. on both sides. I’m genuinely interested in making them all play nice with each other. We definitely shouldn’t say good bye to tracker just to be purely functional. There’s no need when we can still be consistent with react’s rendering behavior or when we can intertwine nicely with redux.

The only fear literally is: only that other react developers will look at you “sideways” for using sideways data loading based on autoruns. Lol

It’s a valid fear from the standpoint that developers not coming from the meteor world won’t be familiar with them. But otherwise it’s kinda stupid, once we box them in, since they mean a lot less work.


@evanyou: This example from manuel is a perfect example why it’s currently so frustrating to work with Meteor. It get’s ignored whenever I see someone mention it, but how is this example possible? @gschmidt says A and you say B. Litterally the opposite of each other. Who do we need to take for granted? So frustrating :smile:

1 Like

@Ben @manuel

That’s not true though. You misinterpreted what Geoff originally said. He said primarily that whatever they come up with won’t be backwards compatible. And the only thing they ever really said they would likely do is a spacebars to jsx compiler. I admit the original post was somewhat ambiguous. But evan’s been pretty much saying it all along not to expect much blaze-wise.

That all said I have made react components render to blaze, when once they can use spacebars, will mean a component based API that can render to both blaze and react. This along side the blaze to react transpiler will give u the best of all worlds.

In addition after all my research I really wouldn’t worry too much about this. MDG has the right idea about sticking close to react proper. React is shaping up to be a great ecosystem and the Facebook team is making world class decisions about both its interface and implementation. If you look into everything coming out of the Facebook stack: relay, GraphQL, etc–you will see they are coming up with sound and thorough solutions. The interfaces they provide aren’t super automated, given their functional nature, but, since a hybrid OOP approach is exposed, leave a lot of room for others to build on top of it via various entry points they provide such as mixins.

So basically what I’m saying is it will be a great thing to move to the Reaxt ecosystem, and as long as some project exists such as Sideburns and Meteor.Component, you will have a nice migration path forward. It doesn’t need to be sponsored by MDG. After all they didn’t build React themselves, yet it interopts with Meteor quite nicely. Deep knowledge of Meteor internals that only comes from MDG (or @arunoda) isn’t needed to hack on React and make it presentable to Blaze developers.

I don’t agree with the bolded text above. They didn’t build React, but the DID BUILD Blaze. They built Blaze, integrated it with Meteor, and we had to learn it in order to develop with Meteor. It was inseparable from Meteor. Therefore they took ownership and responsibility for it. Now it’s MDG’s responsibility I believe to ween us off of it as smoothly and seamlessly as possible.

Hey well u know id love em to sponsor and help me with my packages. I’ve been one of the number one guys saying they really need to do all they can do to make the migration strategy as seamless as possible. I’m just saying I understand their decisions based on the resources they have available.

Hassle em to help me with the spacebars to jsx compiler. They haven’t even started that. At least not since evan’s work in May. If we could get going on that we’d have a start to something tangible rather than just talk about what is and what is not gonna happen. For real, email whoever u talk to st MDG. Spacebars to jsx transpilation needed to happen like yesterday.

1 Like