Next steps on Blaze and the view layer

I am not sure a client that has spent over $30k on building an app with Blaze feels like shifting to react is 100% ‘foolproof’ for their business. Trusting MDG and building with Blaze in the first place felt like the right move as an early adopter. Honestly, this is kind of a crappy move imo, @gschmidt. How many packages in Atmosphere rely on Blaze? Can we just flag all those as outdated when this new Blaze 2 comes out with a complete lack of backward compatibility?

I really appreciate MDG opening up about it’s plans, but it just feels very short-sighted for the community and like a lot of projects may be left in a lurch and will find it easier to just leave the Meteor ecosystem all together. I certainly have put my reputation on the line every day by selling Meteor and this feels like I bet wrong.


+1 to blaze templates on top of react, like the Sideburns project. Templating allows traditional separation of responsibility between html/css and javascript coding. Also lack of if/else driving me crazy!


If we’re ditching Blaze 1 and Evan You is on the project, can we not just use Vue.js instead altogether? :slight_smile: I’ve had great success with Vue, Vue-Router, Vue-Meteor-Data, Webpack and Meteor and it’s much easier to learn compared to React.


This is absolutely the right direction and decision. MDG simply doesn’t have the resources to maintain the entire UX experience with raw libraries for everything. Take what makes Meteor magical (focus on dev ux) which includes reactivity and use the best tools out there to accommodate that. Meteor had to invent Blaze + Packages because it wasn’t available when Meteor started (in a good shape). Now there’s things to rely on without needing to focus it as a core asset (React + Webpack). Integrating those tools tightly into Meteor and shaping it so it’s extremely easy to use is a huge win.

Great decision, do it. So stoked.

We have a massive app, and I’m looking forward to rewriting the views in Blaze 2.0 It will be faster, and more composable. Winning. We have over 350 template files.


First of all I really appreciate the fact that MDG are asking the community about their views.
With that said, I think Meteor developers have been very patient and understanding of breaking changes to Meteor as it is growing and being developed and one of the reasons they have been so understanding was the speed the simplicity of blaze and the speed it let people code(which I hope will not change).

I think the big fear shared by most Meteor developers is a feeling of lack of stability.

Today React is big, but what will be big tomorrow? Is MDG going to decide to move to the next “big thing” the second it comes out causing 1000s of lines of legacy code to be obsolete? These are all questions that need to be answered. Meteor was built on the premises that I can run the same code in both the server and back end with little to no separation(depending on security considerations).
With the introduction of react is MDG moving away from this principal and if so what is going to be the main driver for me to use Meteor over things like the MEAN stack.

In all honestly, right now my big fear is what will happen to all of our legacy code and how easy it is to upgrade it. The next obvious question is should we be coding in react or blaze if we were to start a new project today.

Other than that all we can really ask for is lots of updates on the way and to write some really good tutorials on how to upgrade our legacy code.


Hi Geoff; Hi Evan,
Thank you for weighing in on this topic. I just wrote a page of text replying to Evan’s questions; and as I was sorting through my thoughts, I came to a conclusion similar to Josh Owen’s recent post… this is fundamentally about backwards compatibility and a migration and maintenance issue.

The question shouldn’t be ones of ‘what do we like/dislike about Spacebars/JSX’. That’s really missing the point. The questions should be:

  • What are the migration and refactor paths from Blaze to Blaze 2?
  • What utilities do we use to move to Blaze 2 (i.e. and therefore to React)?
  • What upgrade utilities were missed during the Meteor 1.2 release?
  • What packages/utilities can be created to coherently integrate or migrate apps from Blaze to React?
  • Is Blaze 2 going to be API compatible with Blaze 1?
  • If not, what happened to the '1.0 release` and long-term stable APIs that were talked about pre-0.9?

The reason that many of us are clamoring about Sideburns/Blaze-React as a workable solution, is that it offers a super clear migration path for all the existing Blaze applications in production. The refactor path is basically this: add the timbrandin:blaze-react package; replace .html file extensions with .html.jsx file extensions; et voila; your app is running on React. That’s what existing Blaze users need to get all of our projects migrated over to React.

Seriously, don’t change the existing API if possible. Not right now. The API isn’t perfect, but that doesn’t matter. Use the existing API as a baseline; swap out the underlying functionality; and make sure it’s feature compatible. It’s a classic refactor. It’s not as fun and glamorous as producing new functionality or stomping out bugs; but it’s the boring, responsible, professional, and trustworthy thing to do. Once Blaze 2 is proven to be feature compatible with Blaze 1, then lets start adding new features in Blaze 2.1 and later.


ps. Serkan concisely summarized my previous page of text with his simple breakdown… it’s all about the HTML. As fancy as JSX is, it’s simply not HTML.

pps. I vote for Inferno as the name of the project. Spark > Blaze > Inferno.

ppps. MDG is doing a great job of managing the front of the change curve; but as a startup hasn’t had to deal with managing the back of the change curve.


So, basically, you just officially said, that all apps with Blaze will need to be rewritten to Blaze 2, which will come no one knows when. All packages, using Blaze, need to be rewritten too. I don’t even try to think, what Atmosphere will soon look like. This reminds me the sad Angular story.


Seriously, don’t change the existing API if possible. Not right now. The API isn’t perfect, but that doesn’t matter. Use the existing API as a baseline; swap out the underlying functionality; and make sure it’s feature compatible. It’s a classic refactor. It’s not as fun and glamorous as producing new functionality or stomping out bugs; but it’s the boring, responsible, professional, and trustworthy thing to do. Once Blaze 2 is proven to be feature compatible with Blaze 1, then lets start adding new features in Blaze 2.1 and later.

^ +1


What if we don’t want to use React? At all?

Meteor moved in 1.2 to provide more optional packages allowing us to tailor our projects. I got the impression there that you were trying to be a less opinionated framework.

If you’re building Blaze ontop of React then you force us to use React so blaze basically becomes React. There’s no point using Blaze as you’ll presumably lose something with whatever is placed ontop of React. API/Implementation wise.

As other users have said they don’t want to use React. They want to use Vue/Polymer/Raw HTML/Backbone/Angular/Web Components/Whatever 2016 brings.

Whatever you do, don’t force us into React through lack of other available options.

It’s kind of a concerning topic. Please be careful.


Love the name.

I think a lot of people on this thread weren’t around when the Spark to Blaze migration happened, but as a package maintainer it was not fun. And as an app builder, we spent a ton of time waiting or helping upgrade a bunch of packages for 0.8 release. It took us 2 days to convert 1 small project, back then, once all the package issues were straightened out.

I’m not saying let’s stop forward progress, but let’s make sure we aren’t tossing out a bunch of work a ton of people have built because the ‘UI is hard to debug and maintain’. If we go down the path of adopting Webpack but then it becomes hard to debug and maintain, will we toss that out later?


100% agree and I’m in the same boat, I feel this might be a big problem with my clients. @gschmidt I also think this is the second time MDG is losing sight with the community the first time was with Galaxy which was back tracked into lower plans and now this at the same time would be really nice if we can get routing and project structure in core. Front end is working really great with 3 amazing options.


I completely agree with you. There are thousands of packages which are equally important like the core. It’s unfair to make this community packages deprecated. MDG should think wisely about the backward compatibility. And I think porting overhead is too costly. My personal opinion is that we should embrace the new technology keeping in mind with the backward compatibility as there are quite a few production apps.


I was just getting into package maintenance; but still had to deal with upgrading a dozen apps. Some got taken care of right away; but others took upwards of 6 months to finally upgrade. If there’s not an easy migration path, apps won’t get upgraded, and will just sit as abandonware.

Although, to MDG’s credit, I remember there being clear messages in the console logs that the rendered() and created() helpers were being deprecated for onRendered() and onCreated(), and various other messages that guided people through syntax changes. That was the best part of the 0.8 upgrade, as I recall. (or was it the 0.9 upgrade?).

1 Like

Love this.

Agree with @joshowens and @awatson1978 that focus should be on upgrade path. Inferno as a drop-in replacement for Blaze would be mind-blowing. If that’s impossible, a minimal upgrade path for people who want to port existing templates to Inferno, and allow Blaze and Inferno to coexist somehow like you’ve done with Blaze/React in 1.2.

Really excited about this thread and overjoyed to see @evanyou putting his considerable talents into it. Blaze is a sensitive topic and you’ll never be able to satisfy everybody, but you’ll make a whole lot of people happy when you deliver.


Spot on as far as I’m concerned. Having meteor packages with React compatible views will be awesome. The React community itself is also enormous and for meteor devs to be able to leverage their components out of the box should outweigh the annoyance of upgrading current packages in the long run.

Also I haven’t heard of any developer with long term experience of React who would worry about it’s maintainability since it’s predictability and maintainability are it’s key features and design goals. Having used Embers and Meteors view layers a lot React seemed weird to me at first but now after almost a year of using it I would neither want not dare to use any other thing for big scale, high fidelity UI stuff.

Hi Geoff et al,

I’m Tim the author of the package Sideburns/Blaze React. I just want to reflect the reason why I created the package from the beginning. Basically I want to replace Drupal with Meteor some day, using only some packages to get the same features or maybe a set of packages (i.e. SpaceDrop, Universe or Orion). I want to do this because I’m so tired of the way we build CMSs today which I do every day, and they’re ages old now.

But to get there I first realized that in a CMS one has to render and load really quickly, because a regular user to a CMS is different from an app user in that they’re looking for information rather then a function, and doesn’t want to wait for anything to load, they want to access the acclaimed information kept in the page, and nothing more than that.

And to really get to this I realized one needs to render Blaze on the server and maybe incrementally load all its templates. So I started looking for solutions, first by actually rendering blaze on the server together with fast render and a custom package replacing spiderable. At that time I realized how tightly Blaze/spacebars was coupled with the client and to have all templates and code render anywhere I really had many fights to overcome.

Then one day @arunoda created a hacked together sample application, showing us how one could use react and a custom flow router to get fast page loads and server side rendering, it did all the things I needed. And I loved this approach, but I never really have come to love how jsx is written and I always have trouble getting an overview of the actual html output, I don’t even dare to show our designers jsx and that’s when I got the idea of parsing actual blaze templates, because blaze is awesome with the templates.

So starting on that idea, one had to create a plugin that parsed html, js or jsx files, but these extensions was claimed by meteor core packages already so I had to create my own extension which I never really liked. But thankfully with the release of 1.2, it was possible to overcome, except for js files which doesn’t even allow for me to read what’s in them to parse event maps which needs to be added before the transpiling is done.

Some quick things one could really gain with a new template system, and here’s what we should do:

  • templates that can be overriden only by re-implementing them as is.
  • helpers that use this instead of Template.instance or Template.parentData to get access to the instance.
  • event handlers that also use this and now takes the context as first argument and the event as last argument.
  • both events and helpers can also be overridden if re-implemented as is.
  • and let’s stop using the global scope for anything and implement import and export using modules/packages for each file or folder or whatever.

I really like the idea of incrementally loading parts of your app, so let’s get add modules and webpack into core, and have people get used to the fact that they have to include something if they want to use it or override it.

Feel free to fork/use the regex I’ve written in blaze-react, I believe using regex is way faster than any other methods of parsing templates!

And as a final note, I love that you finally have messaged your thoughts to us in the community, I was starting to dislike the whole project due to the lack of personality in your public posts and missing information of your actual stand in these critical maters. And I don’t think the current format of public emails is very well done, compared to when you wrote all of them yourself from a more personal point of view, I miss that, and especially the – in the end. Anyhow, I do love what you’re doing! And I think @joshowens does so as well!

// Tim


The fact that “UI (built with Blaze) becomes hard to debug and maintain” is a cause of the API design; if we leave the API exactly the same and just swap the underlying implementation, then we simply cannot make any improvement on the dev experience / maintainability front.

Of course, we will try anything we can to provide a clear migration path for the new solution. Sideburns has already shown that it’s possible to translate Blaze/Spacebars Templates into React Components, so there is a good correspondence between the concepts here, and it’s even possible to make the migration process progressive. It may very well be easier than you think!

Another thing I want to make clear is that the decision of going with React is not made lightly. The hypothesis of “will MDG switch to something else if React is no longer hot” simply doesn’t hold because we did not pick React due to its “hotness”; we picked React because we’ve found it to provide an API that is designed to be more scalable, a much more active ecosystem with many great components/libraries, and a solid, dedicated team at Facebook maintaining it. If anything, Facebook itself runs on React. It’s not going away any time soon when a 300 billion market cap company’s business depends on it.


Excited to see this decision being made!

What do you like about Spacebars’ syntax?

Personally, I always liked how quickly and easy it is to split parts of HTML into templates. The ease of connecting small pieces of logic (like #ifs or #eachs) with the data model felt quick, easy and light-weight.

What do you not like about Spacebars’ syntax?

The sub-expressions syntax was very lacking for a long time. Having to create a helper for any trivial or complicated operation felt unnecessary. Also data context was a very confusing concept. Often times templates relied too much on what data context should look like and the templates became less reusable as the shape of the data was defined in how template is using the data context.

What do you like about JSX?

The expressiveness of JS for logic that is more complicated than if/each. Being able to assign variables, iterate over objects, use helper functions from other JS libraries w/o special integration.

What do you not like about JSX?

It is easy to abuse the expressiveness of JS and make the render function look less like a template and more like a JS function with some constants in XML.


What is the point of reinventing something, based on React? Why just don’t use React and add easy npm support, so that we will be able to use React packages and also create new ones and share with the world outside Meteor?


We are not re-inventing anything. It’s more like an thin interop layer to ease the migration/learning curve to React. It’s going to be optional, you can of course go with raw React if you want. In terms of easy npm and module support - that’s exactly what we are going to do! (@benjamn is on it)