🔥 The current state of Blaze & Async - Or: everything I learned about Blaze and Async in the last 6 Months



I’m Daniel :smile: and our company has built a big Blaze - Everything-and-the-kitchen-sink - App in the last years.

This post is meant to become a “clearinghouse” of the current state of Blaze & I’ll likely update it going forward as new information arrives.

Please feel free to add any kind of information or constructive feedback! It’d be nice if you’d include to which part of the post you’re responding to in your replies to keep the discussion focused on the different issues.

Our Stack

Think “classic meteor” + kitchen sink.

Think Meteor & MongoDb. Blaze. Flow-Router. Pub/Sub and validated methods.

Think Cordova & Desktop. Android. iOS. Push Notifications. Video Calls. Fotos & Audio recording & sending. Custom / patched Cordova packages abandoned by others many years ago :slight_smile:

Think multiple Admin-, Back- and Frontend-Interfaces for users in different roles. Think lots of different views. Custom & Handcrafted UI & Styling, all built on a fork of a CSS / UI Framework abandoned years ago (Meteor-Ionic, Based on Ionic Framework 1 I think :slight_smile: ). SCSS, obviously.

All of this with full-stack-reactivity, and End-to-End - testing to go.

We have 50+ atmosphere packages in our packages file.

Current Situation with migrating to Async & preparing for Meteor 3

Since the beginning of the year we’ve been working on trying to figure out a way to navigate the maze from Meteor 2.0 to Meteor 3.0

We’ve been in touch with a handful of Projects & Teams who’re also basing their Stack on Blaze.

We’ve also been supported by @grubba and @radekmie to get the first versions of a workable version of Blaze running.

I wouldn’t say we’re there yet, but

:fire::fire:I hope we’re now finally approaching something useful - as a stop-gap measure! :fire::fire:

:stop_sign: The sentence above is designed to induce terror in anybody having built anything substantial on Blaze, to get in gear to get more eyeballs to look at this & finally start converting their apps to ASYNC! :stop_sign:

The state of Blaze, in general

Blaze, in it’s entirety, conceptually foots strongly on a) Tracker for reactivity and b) synchronous code to control the entire process of rendering the entire page & data.

Also its data-available-everywhere model when using the minimongo liberally leads to really big issues with data not being fetched centrally, but things being re-run granularly in all different kinds of places in more complex projects / templates.

Which makes it unfortunately really difficult to just wrap access to reactive data sources in a little Tracker.withComputation block and be done with it… Access to the Tracker.currentComputation - objects is lost as soon as one async function is being awaited.

Making it fully Async-Aware would be a major undertaking, bordering on a re-write and possibly a re-integration with all areas it touches within meteor. I don’t think it’s going to happen, there seems to be too little interest an resources available to take a real stab at it.

The state of Tracker

Tracker and ASYNC / Await: Cat, meet Dog…

Tracker & Async: they’re unfortunately conceptually basically incompatible. The one (Tracker) builds on a global state being accessible (Tracker.currentComputation) to enable reactivity.

ASYNC / Await builds on the foundation of “it doesn’t matter when this code gets executed, as long as it gets executed in a plan-able way”, unfortunately not having a mechanism for storing & restoring global state.

This means, our Tracker loses control of the global variable and can’t control it anymore for ASYNC code as the code execution becomes asynchronous.


There are measures to work around this, but they all orbit around the idea of trying to store the current computation somewhere, locally, and passing it into and around all reactive code, around the async/await callbacks, mostly using lexical scoping.

This means we now have to become very conscious of where reactivity comes into play, which autoruns are essential, and which code they call.

How’s tracker / async going for the non-blaze projects going by the way?

It looks like all the integrations into the major frontend frameworks are based on Tracker / autorun, right?

Are there maybe negative effects which might come from helper code suddenly becoming ASYNC there too (and thus breaking the reactivity)?

Or are the patterns there in general unproblematic? The recommended / default react-meteor - package, react-meteor-data seems to rely on Tracker to synchronize & fetch its information & keep it reactive - how’s the state of the union over there, guys?

(The same is true for vue & svelte too I think?)

The problem with Blaze - there’s nobody having real “ownership” I guess?

I mean, there are maybe people still using it, and it’s getting patched and prodded from multiple sides, but really, there’s no plan here, no central communication & no leadership.

If I’m wrong here and you or someone you know OWNS Blaze and WANTS to lead it into the next years, I’m all ears!

Anyways… here’s our current “solution” stack: :syringe::hocho::pirate_flag:

First and foremost: These are basically all bandages around a very sick patient who is bleeding from multiple major wounds… Blaze isn’t looking good and probably isn’t feeling well either! :sweat:

WITH THESE MEASURES we mean to be able to convert out app to ASYNC to become ready for Meteor 3.0.

But Blaze itself isn’t really ASYNC aware and probably will never be.

So for many this might be the stopgap measure to convert your existing codebase, and start saying goodnight, sweet prince… You were great while you lasted. :racing_car: :cherry_blossom: :heart: and I’ll miss you.

So, on to the meat - the current state of ASYNC Blaze, to the best of my knowledge:

I. Spacebars & Async Data

What would a frontend framework be without it’s friendly templating language?

Here a lot of progress has been made, although not everything has been resolved. @radekmie did most of the heavy lifting, though he did make it look easy :slight_smile: Cool stuff @radekmie !

Is there any documentation about what works (and what still doesn’t) in Blaze? Well of course not!

Let me give you the low-down, as far as I have it:

a) Implemented async bindings in #let

Thank you @radekmie !

(This is already in Blaze if you’re on the current 2.x branch.)

Thanks to this PR, you can fetch whatever code you want if it returns a promise & stuff it in a variable for the current block:

<template name="example">
  {{#let name=getName}}
    Hi, {{name}}!

Works with both synchronous and asynchronous getName:

  // Synchronous value.
  getName: 'John',

  // Asynchronous value.
  getName: Promise.resolve('John'),

  // Synchronous helper.
  getName: () => 'John',

  // Asynchronous helper.
  getName: async () => 'John',

Also provides additional Async state information in the new global helpers @pending, @rejected and @resolved, if you’re into that kind of thing, and it can also accept multiple parameters, eg. {{#let name=getName shoeSize=getShoeSize}}.

BAM! one thing done, this is a good as a catchall for other things which might not work in the template.

Again, The docs are here: Implemented async bindings in #let. #412

b) Added support for Promises in Spacebars.call and Spacebars.dot. #413

Again, thank you @radekmie !

(This is also already in Blaze if you’re on the current 2.x branch.)

In his words:

“In this pull request, I made Spacebars.call and Spacebars.dot helpers aware of Promises. The former resolves all of the arguments before calling the function, while the latter wraps property accesses in Promises.”

That means that this will now work whenever some part of your hpefully soon-converted-to-ASYNC API (any day now!) starts handing out promises and not result in flames and errors:

From this:

{{#if someFunc ((await calcParamA) (await someOtherparamB)) (await calcParamB (someOtherparamC) (someOtherparamD)) }}

This will have to unwrap the Promise, but the entire computation will be simple:

{{#let result=(someFunc (calcParamA someOtherparamB) (calcParamB someOtherparamC someOtherparamD))}}
  {{#if result}}

Of course, it’ll be possible to use the @pending, @rejected, and @resolved helpers to check the progress of calculating result as well.

Ah, isn’t that just beautiful? :innocent:
Response: No.

But at least it’s something! :smile:

c) Added support for Promises in #if and #each. #424

NOTE: Not in Blaze / your Meteor 2.13 or what have you yet (see below for how to put together my / our current stack):

Third cheers to @radekmie here! :cocktail: He’s the real hero Blaze needed, he took the time to make this work to help out us poor Blazers.

Again, see the PR for more details: Added support for Promises in #if and #each. #424

Basically, Radek is I following up on #412 and #413 above by supporting Promises in #if/#unless and #each. The idea is basically the same as how it works in #let except for where we actually store the ReactiveVars.

So that means, you can use your helper / data / whatever in {{#if}}'s and {{#unless}} and {{#each}}'s again - I mean it would have been a sad thing if we couldn’t have used those going forward anymore, right?

:white_check_mark: TODO: This should get checked and merged soon-ish for the transition to continue.

d) What doesn’t work (without a little help from your new friend, the await template)?

Aside: Thank you again, @radekmie! :smile: for this idea :stuck_out_tongue:!

So what doesn’t work here?

Hahaha… outputting async values / promise results in templates, for example!

Like this:


Sorry, can’t do that! :smile:

But fortunately, our new friends, the await and the awaitRaw - templates can help us here, by creating a view which can then react once the data arrives:

    {{> await myAsyncHelperResult}}

(You could also use a {{#let }} of course, but I like the simplicity of not having to wrap too many things.)

Where you can find these awesome helpers? Just put them in a .html file in your project & import it, here they are (- Gist here, same thing):

    Display potentially async data source results in the template.    Unsafe Content / HTML will be escaped like with regular {{ someValue }} blaze syntax.  
    Use like this:  
    {{> await someValue}}  
<template name="await">{{#let value=.}}{{value}}{{/let}}</template>  
    Display potentially async data source results in the template.    Unsafe Content / HTML will NOT be escaped, similar to using the triple bracket {{{ someValue }}} blaze syntax.  
    Use like this:  
    {{> awaitRaw someValue}}  
<template name="awaitRaw">{{#let value=.}}{{{value}}}{{/let}}</template>

Ta-Daa! :smiley:

e) What doesn’t work Pt II: Mostly things in attributes, basically:

None of these will work as soon as there’s some async going on:

    <div class="{{#if getHighlight}}highlight{{/if}}"></div>
    <div class={{getAwesomeClassList}}></div>

etc jadda jadda. Which is a bit sad.

f) - Bonus why is all / some of this so difficult?

If a spacebars language expression doesn’t create its own view, then it’s difficult to handle. That’s the main point why we can’t just create new await helpers and such, because there’d be no point in the rendering process where the template could actually be rerun once the async data has been resolved / rejected.

So the fixes & hacks from above all work because there’s some place in the template where there’s a view which can be re-rendered when its state changes.

Everything else and you start to have to touch the spacebars compiler, and the whole framework, basically, and it’s all really complicated. See the red/blue problem: What Color is Your Function? – journal.stuffwithstuff.com

g) what are further workarounds to keep in mind? :construction: → Stuff stuff into reactive vars & fetch from there

So, basically everything you want to do in templates you can still do - if you go the detour :construction: & use reactive vars & share those with the template & use those.

For example, I’ve enjoyed using the template-controller - package a lot in the last years, which allows you to add stuff to a reactive dictionary called state and access that in the template, I’m sure there many other ways too to do this without adding extra helpers for everything.

For example for the attribute helpers above you could do something like this:

<template name="coolStuff"
    <div class="{{#if getHighlight}}highlight{{/if}}"></div>
    <div class={{getAwesomeClassList}}></div>

Add this to the template.js:

TemplateController('coolStuff', {
    state: {
    async onCreated() {
        this.state.hasHighlight = await myCollection.findOne().highlight
        this.state.awesomeClassList = await awesomeClassesCollection.findOne().awesomeClasses

state is an automatic helper in all TemplateController templates, so we can use spacebars in our attributes again now:

<template name="coolStuff"
    <div class="{{#if state.hasHighlight}}highlight{{/if}}"></div>
    <div class={{state.awesomeClassList}}></div>

“But, but, that won’t work in my {{#each}}'es and what have you out of the box!?!”

I know, I’m crying too… :sob:

We’ll have to deal with it. There are probably many ways to slice this, we just can’t have the promises end up in the attributes of our HTML elements.

II. Babel Plugin to enable autorun across async/await yields

Basically this: Babel Plugin to enable autorun across async/await yields

Here’s a link to a gist of the plugin: Meteor Async Transition: Babel Plugin to keep Tracker Computation alive after "await"s

It’s a Babel plugin we wrote to allow for rudimentary automatic passing of Tracker.currentComputation in computation contexts across async function calls and awaits contained therein.

You can see more details & examples in the link above.

The good:

  • works for simple code, async calls and simple assignments from async calls, mostly
  • doesn’t break complex code (I think!)
  • is only executed for client code / skips server code
  • seems to be working in our relatively big & complex Blaze app
  • Can be used as a stopgap measure to transition codebases into the ASYNC world


  • could become more optimized
  • could be extended for slightly more complex cases
  • adds build & runtime overhead

Whether this is a good idea & should be used in wider circulation remains to be seen :slight_smile: But it’s there in case you want to give it a go!

By the way: This could be used outside of Blaze for any other Tracker code as well, Hint Hint to the react / vue / svelte gang :slight_smile:

III. - Allow await-ing autoruns by adding firstRunPromise to computation objects

This PR: # Allow await-ing autoruns by adding firstRunPromise to computation objects adds a new, await-able field, Computation.firstRunPromise to newly created computations to allow autorun blocks with async autorun functions to be run in a predictable manner.

Note: This hasn’t been merged yet into Meteor, but you could still try it out anyhow… I’ll get to finishing the open tasks on the PR as soon as I can. I think functionality-wise it’s pretty final.

This allows you to await autorun functions until they’ve been finalized:

Template.onCreated(async function() {
    // autorun 1
    await this.autorun(async(c) => {
        // 1 - 1
        await Tracker.withComputation(c, () => { ... }) 
        // 1 - 2
        await Tracker.withComputation(c, () => { ... }) 
        // 1 - 3
        // (...)

    // autorun 2
    await this.autorun(async(c) => {
        // 2 - 1
        await Tracker.withComputation(c, () => { ... }) 
        // 2 - 2
        await Tracker.withComputation(c, () => { ... }) 
        // 2 - 3
        // (...)

    // autorun 3
    await this.autorun(async(c) => {
        // 3 - 1
        await Tracker.withComputation(c, () => { ... }) 
        // 3 - 2
        await Tracker.withComputation(c, () => { ... }) 
        // 3 - 3
        // (...)

Without awaiting the firstRunPromise for all autoruns, each autorun function would “yield” / leave the current thread on the first await & the thread would zig-zag / ping-pong between autoruns as the individual.

Without the await this.autorun().firstRunPromise, the order of the comments being reached up top would be:

1-1; 2-1; 3-1; (Now all bets are off, but maybe): 1-2, 2-2, 3-2, 1-3, 2-3, 3-3

etc etc.

Which could lead to a) lots of unnecessary re-runs and b) to actual race conditions where autoruns would run and complete in different orders, thus leading to unpredictable and random behaviours.

But - await the firstRunPromises - and at least you can force your autoruns to run in a repeatable and predictable fashion again.

Some final points: Blaze was never made for this - async vs. lifecycle callbacks; Blaze rendering in general; What next.

Have a look at chapter III above…

I said “now you can await your autoruns”.

But that means you have to turn your lifecycle function into an async function.

Blaze doesn’t await its lifecycle functions. And it’s also not easy to make it wait for it because it continues to render all children as soon as one call returns…

So turning you onCreated into an async function means that now your onRendered will be called before the async onCreated function has been completed.

**I actually don’t know how many issues still slumber below the surface ** besides the ones we have patched & tried to mitigate, see above.

Where do we go from here?

As I mentioned in the beginning,

I think there are basically two ways to go here -

a) a rewrite / total reevaluation of blaze - which probably will not happen.

b) we can continue to try to mitigate issues the best we can as they pop up and try to convert our existing codebases to ASYNC - for the short term. But Blaze will probably never become a fully supported citizen of the ASYNC world of Meteor 3.0 .

The latter is what I’ll continue to try to be doing. It’s a bit sad because it means accepting that Blaze will never be “fixed” for Async and will live in a continuous state of “known brokenness” until the end of its days.

Our little demo / template project

Here is a little sample project which contains all the code mentioned above in one package - plus some sandbox code which isn’t really guaranteed to do anything for you :slight_smile:

But you can use it as a grab-bag to get all the mentioned code, merged or not, in one handy package right now, here: - Blaze Async Sandbox

To use this “stack” in your own project, the easiest thing to do would be to

  • clone the project above
  • copy the following packages from the packages directory to your own projects’ packages directory in the convert-to-async - branch of your repository:
    • blaze
    • tracker

Copy the babel plugin plugin-trackerAsyncMitigation.js from the babelPlugin folder into a cozy place in your project and update your .babelrc like eg. this:

    "presets": ["@babel/preset-env"],  
    "plugins": ["./babelPlugin/plugin-trackerAsyncMitigation.js"]  

NOTE: you have to delete your meteor build cache once (eg. run meteor reset once) after adding the babel plugin in order to get its effects applied to your codebase.

Calling all Canaries / Blaze users

These are all the people I know who have shown or expressed an interest in Blaze recently. I’ll mention them here to GET YOU IN HERE!!! HELLOOO!!! NICE TO SEE YOU GUYS! :smile:

Hi @fredmaiaarantes @TatiBarros @grubba @radekmie!
Hi @sebastianspiller and @thebarty !
Hi @alimgafar, @jkuester, @storyteller and @dr.dimitru !

This one has been a long time in the making, thank you all for your help so far.

But now I’d need your help again: Please reply, be heard, tell us about your current status re: Blaze & Async! Your news, your updates, your interests going forward, and all feedback in general! Anything. Please! :smile: (Just do it!!! :white_check_mark: )



It is important that we ORGANIZE ourselves and that we get a good picture of who still uses Blaze, what is still being done out there with Blaze! and how we move forwards TOGETHER!!!

Thank you guys!

Slow claps from the only two chaps in the audience :clap: :stuck_out_tongue:


Amazing summary @DanielDornhardt !!!

From what I see it may open the question, whether Blaze needs a complete major rewrite in order to become fully async aware.

1 Like

That’s just really nice to read and a great summary, it is really admirable to see folks pushing complex code and doing migration to keep things up to date.

1 Like

@DanielDornhardt woha! This is an awesome post and it shows the kind of :heart: LOVE :heart: you have put into this. :grinning:

Also really nice to see that some of the old fellow meteor experts are around - props to @radekmie (thanks for putting react autoform out - it had helped me a lot back in the days) and @dr.dimitru I think I once used some mongo package of yours.

I have been out of the dev-game for a while now but still look back with a LOT OF LOVE to meteor. I really hope that you guys find a good solution for this. In my world I had left blaze for good and switched to react with meteor.

Keep on pushing it and all the best!!!

And: ANYONE using BLAZE + METEOR should start contributing to this project. Looks like it needs to be a community effort. :muscle:


Thanks for the great summary @DanielDornhardt and for calling out all Blaze developers.

I would like to emphasize that Blaze is important to us and we care about it. In fact, most of the work done by @radekmie was during the partnership that Meteor Software had with Vazco. @radekmie is very knowledgeable, a great developer and our team loved working with him.

Additionally, our team is working on a guide to help with the transition to asynchronous and we’ve added some of these Blaze examples into it. Is it published @grubba?

I agree we could find a way to centralize the work and discussion around Blaze. I tried to find some discussions we had on Slack, but unfortunately the messages were removed due to it being a free account. My suggestion is to use the GitHub Discussions, creating a new one just for this.


Thank you @DanielDornhardt for putting all of this together. You and @radekmie are doing terrific job.

I still use Blaze to this day and I’d definitely be interested in making sure it survives the 3.0 avalanche.

In terms of helping out, I tried to read into the code but honestly couldn’t figure out much and there’re not much resources to go around except for these which are pretty outdated. I know, there’s the source code so just read it™ but I couldn’t.

Maybe if @radekmie cloud offer some mentorship along with more split-up simple tasks, I’ll be able to chime in.

I guess this isn’t much but an admission of my inability to help in terms of code which has been the biggest blocker, at least for me. :slightly_frowning_face:

I still have a long road to grow as developer. :man_shrugging:

The best we can do is to financially support @radekmie. If we can setup a pot for everyone interested in Blaze to donate some cash for @radekmie to finish the remaining tasks. I’d not be able to help much :smile: I’m fresh out the army and yet to receive my first salary. So don’t hold me for my word please lol.

But if @radekmie could set a fixed price for his work/tasks, like if I get x amount of money I’d finish y task. I’d be willing to dig up my secret stash.

Aside from that, is it really as serious as you paint to be? Because you mention couple of times how Blaze doesn’t go well with async. Then you mention that currently async attributes are the only remaining problem be solved which isn’t a big deal IMO. So, all in all aside from attributes is there any other blockers to Blaze to work with async?

Keep up the good work and thank you!


I think that train has probably left the station, but I’d gladly be proven wrong here :smile: - It’d need one or more really motivated individuals to attempt a re-write and/or overhaul of Blaze.

I’m sure it’s possible, as in “everything is possible”, theoretically.

But in practice I think Blaze - as amazing as it is - has been left behind by the more react-style / component-style frameworks, which in general use very different models and approaches I think.

We can collect possible approaches about this somewhere & maybe have a discussion on that point, but at least as I know, a rewrite hasn’t been started so far, and with a look at the target date for Meteor 3.0 - April 2024? - It seems to be a tall order to have a new frontend rendering engine ready until then if a real initiative with that goal hasn’t been startedyet.

I’d gladly be convinced otherwise, if there is some strategic plan for how and when Blaze should be updated to be 3.0 & Async compatible somewhere, I’d really be happy to see it…

:white_check_mark: I’ll create a separate Post with the current Issues and also a place where a potential rewrite could be discussed later


Thank you for taking your time and replying in @fredmaiaarantes !

(I know it’s still a bit messy but I hope to clean it up a bit in the coming days :slight_smile: )

Yes, thank you! Yes, props to where props are due! :clap: Both @grubba and @radekmie took time to investigate the situation. @radekmie especially came through again and again with solutions to urgent issues - and he still does! So thank you all, to Meteor & the Vazco team and those who helped us to get this far!

Additionally, our team is working on a guide to help with the transition to asynchronous and we’ve added some of these Blaze examples into it. Is it published @grubba?

:bangbang: Now this would be great and very timely & important right now! I’d be really happy to contribute our refactoring notes into a shared guide or document, most of the stuff from this post should probably be there and not here! :smiley:

:white_check_mark: @grubba Could you please share this guide? And is it possible for the community to get involved to edit it as we learn?

I agree we could find a way to centralize the work and discussion around Blaze. I tried to find some discussions we had on Slack, but unfortunately the messages were removed due to it being a free account. My suggestion is to use the GitHub Discussions, creating a new one just for this.

I really think for now the forums are a great place because not all people are following individual threads on issues tickets, that’s a pretty hardcore thing to do & not very discoverable IMHO.

I’d really like to create & have a handful of forum posts as starters, where we can discuss these things in the open, so the wider community can follow along, and then we go and create issues from actual work items which migh come out of it! :slight_smile:

Thank you again for joining the discussion, looking forward to working on Meteor 3.0 together!

1 Like

Yeah! The guide is here for those who want to contribute is in this file


Hello Harry! Nice to hear from you! :slight_smile:

Thank you! :slight_smile:

Very cool and interesting links! I think we could all look through our browser histories and maybe collect threads which have happened since 2021 which talk about the ASYNC transition too, especially towards blaze. I know many interesting discussion have taken place, both on the forums and on Github, and some are actually still being revisited, on and off, but I think we should try to “catch them all!”

:white_check_mark: ToDo: Collect & groom Blaze-related links & previous discussions so we can all get to a current status…

One thing is, I think having forum posts, a bit bigger, like this one, could be nice, but it can only ever be edited by one person I think, so I think we’d need to look at where we could share this knowledge best.

(PS: Oh the meteorpedia is still a thing?! OMG… :smiley: )

There’s soooo much stuff out there…

The best we can do is to financially support @radekmie. If we can setup a pot for everyone interested in Blaze to donate some cash for @radekmie to finish the remaining tasks. But even then, I’d not be able to help much :smile: I’m fresh out the army and yet to receive my first salary. So don’t hold me for my word please lol.
If @radekmie could set a fixed price for his work/tasks, like if I get x amount of money I’d finish y task. I’d be willing to consider blowing the dust off my secret stash.

I think that’s one thing to look at, whether there’s enough enthusiasm in the community to move this forward in some way… Financing & coordination would certainly be important topics…

I’ll try to get some more buy-in / interest in the community by stirring this pot here now and then & continuing my previous work in the open, and if we get enough people “on the hook” who understand the importance of this going forward, then we can think about how this could work in more detail…

Aside from that, is it really as serious as you paint to be? Because you mention couple of times how Blaze doesn’t go well with async. Then you mention that currently async attributes are the only remaining problem be solved which isn’t a big deal IMO. So, all in all aside from attributes is there any other blockers to Blaze to work with async?

Unfortunately that aren’t the only things missing, they’re the only things missing in spacebars / the template features.

But other things relating to the actual rendering process & autoruns in general aren’t solved / easily solvable as far as I can see…

:white_check_mark: Todo: Make list of currently known Issues with Blaze

Keep up the good work and thank you!

Thanks! :smile:

Wow, thanks for compiling this @DanielDornhardt and thanks for keeping it humorous as otherwise I might have cried :laughing: I had no idea what the meteor 3 update meant for blaze. We’re happy to contribute some :moneybag: to a fund to get this done.

1 Like

I think we all had a great lesson on communication skills! It was enjoyable read :ok_hand:

1 Like

I’ve never used Blaze, so this is probably a very unworkable idea.

I asked a chatGPT-4 service (phind.com) to translate some Blaze code to React, and here’s what it came up with.


Thank you @vikr00001 !

I’ve actually used ChatGTP extensively to develop the Babel Plugin mentioned above! It’s really great to dive in into a new domain.

The automatic conversion from Blaze to React code is one part of the story, but that’s not where the big difficulties pop up, for us at least.

Most problems come from the template code & the data querying & distribution part.

The conversion of the templates is more or less a mechanical issue, yes, but first all other issues need to have solutions in order to be able to convert an existing project I think!

1 Like

Since I’ve been tagged 24 times in this thread already, I think I should say something too :sweat_smile:
(I was off for the past week so I’m a little bit late.)

First of all – once again, thank you @DanielDornhardt for pushing for all of it! I wouldn’t put even half of the work I did if you wouldn’t ask or test it. It’s also great to work with someone who actually uses Blaze on a daily basis (I no longer do; just touch it from time to time, mostly to rewrite it into React).

Next, I think I have solved the async attributes (I have some working draft locally but need to test it more and see if it doesn’t kill the performance). Similarly for async onCreated, I have an idea I’d like to explore. I also have an idea on how to test Allow await-ing autoruns by adding firstRunPromise to computation objects by DanielDornhardt · Pull Request #12805 · meteor/meteor · GitHub too – will post that soon.

I think that’s the best moment to say that I’m no longer working at Vazco. I moved to aleno.me now (it’s actually one of the showcase projects on meteor.com). And while there’s no Open Source Group at aleno nor I don’t expect to make one, but I won’t stop working on open source. Of course, I won’t put that much time into it, but I’m not planning to stop.

Yeah, Blaze code is rather complex. I’m totally up for such sessions (we’d need to come up with an appropriate form for that), but I think that going through the PRs I recently made (Implemented async bindings in `#let`. by radekmie · Pull Request #412 · meteor/blaze · GitHub, Added support for `Promise`s in `Spacebars.call` and `Spacebars.dot`. by radekmie · Pull Request #413 · meteor/blaze · GitHub, Added support for `Promise`s in `#if` and `#each`. by radekmie · Pull Request #424 · meteor/blaze · GitHub) would be a good start – I tried to make them as small and clear as possible.

Thank you for those kind words, really! But I do want to make it clear I won’t be able to work a lot on that each month. I can’t give you exact numbers, but a couple hours each month is definitely doable. As for getting paid for tasks, I’m open for that. Ideally this would be some sort of an actual invoicable collaboration, since the way taxation for GitHub Sponsors works in Poland is far from ideal.


Hi everyone!

@radekmie : Sorry for not getting back to you yet! Thank you for your reply & information & help!

In general: If you were interested in this thread you might be interested in filling out this survey here as well:

Please contribute your progress towards the Async Effort in you projects so we can work together as a community to help each other solve any open issues going forward!