Next steps on Blaze and the view layer

core
1

Hi everyone,

For those of you I haven’t met, I’m Geoff Schmidt, one of the original Meteor core developers and CEO of MDG. With Galaxy in the field now and doing great, I’ve been able to clear out a big chunk of my schedule and you can expect to see me much more active on the forums.

As we start to approach the end of the year, MDG is taking a look at the Meteor stack from top to bottom and thinking about what’s next. We’re thinking about testing, routing, schemas, and more, and what should be a core package and what shouldn’t. I’m also super excited about the many new technologies in the JS ecosystem, from GraphQL to Webpack to ES7/ES2016, and how we can bring them to Meteor.

To start with, I want to talk about Blaze. Meteor 1.2 brought official Angular and React support in core. We think that React and Angular are great. We’d like to cooperate, rather than compete, with these projects, and get the full benefit of the thriving ecosystems around them. We originally built Blaze because the alternative was shipping Meteor against Backbone. That’s a very different situation from today.

There’s been talk for some time about Blaze 2 and components. When we took a look at what it would look like, it looked a lot like React. We think that React has the right component model and good APIs. And while there are differences in the DOM update algorithms used (React’s virtual DOM diffing versus Blaze’s fine grained reactivity), both approaches work.

What’s missing from React (as a Blaze upgrade) is templates and the tight integration with Tracker. We think the combination of the two is basically the core of what people like about Blaze (correct me if I’m wrong!) You can’t really get a comparable experience with Angular 1.0, React, or anything else I know of that’s a viable choice in production today. 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. And your porting effort will be richly rewarded with access to React’s in-browser debugger tools, vibrant component ecosystem, and more. Today’s Blaze will continue to work but MDG’s development efforts will be focused on the new React-based templating option, React JSX, and on Angular.

As excited as we are about React, we’re just as excited about Angular. Our intention is to support both of them equally as first class citizens, and deliver the best possible full-stack experience for each of them. Though this particular post has mostly been about React we are just as committed to Angular. We will be continuing to invest in Angular as well, especially with the advent of Angular 2.0.

We think that this is the path that makes the most sense for Meteor: working as closely as possible with the Angular and React teams to deliver an amazing full-stack JS app platform, rather than trying the duplicate the work of those communities. There’s an incredible opportunity in front of the whole JS community right now, to make app development faster and easier than it’s ever been before. We should all partner up and work together to make that happen.

So there you have it – our thinking at MDG on the future of Blaze. It’s an emotional moment for me. I wrote the first version of LiveRange, Blaze’s underlying DOM annotation technology, sitting in a tiny office years ago with a couple of friends. It’s still one of the technical contributions that I’m proudest of – even though it doesn’t hold a candle to the work that David Greenspan, Avital Oliver, and others subsequently did on Blaze. But I think that this is the right plan, and I feel good about the benefits that it will bring to Meteor.

Before we finalize this decision I want to hear what you think. And we also need your feedback on how best to do it – what does great reactive templating for React look like? what are the parts of the Blaze 1 experience that we need to keep, and what do we need to change? We’re starting work on it this week, so let me know what you think!

Thanks,
Geoff

93 Likes
2

So, what would that look like (from a coder’s POV)?

1 Like
3

You ain’t wrong :wink:

3 Likes
4

Yeah. That’s really good.
Hope you are know about this project sideburns: https://github.com/timbrandin/blaze-react

So, you are going to bring that to core or start from the scratch?

17 Likes
5

So what we’re planning to do is to build templating on top of React

As Rob asked, what whould that look like? (roughly of couse)

access to React’s in-browser debugger tools, vibrant component ecosystem, and more.

How would that work? Would you write your code in a Blaze-like way (for lack of a proper name) and then see the transpiled React code in the React tools?

6

This is fantastic! I was just discussing with a colleague about the direction our major project should take - wether it be plugging forward with Blaze or converting to React and refactoring our whole app. This should give us the direction we were looking forward to.

A few questions:
Will the syntax for writing Blaze templates still be HTML with Spacebars helpers, or will it be something a little bit more akin to React? Truth be told, I love the ease of Spacebars templating. It doesn’t take much for my brain to wrap around.
Will it be possible to use Blaze 1 templates alongside Blaze 2 or will every template in a project need to be ‘ported’?

1 Like
7

This plan is to destroy Blaze and make Meteor part of React and Angular. The future of Meteor will be melt into the React.

Today I can apply React components into Blaze templates so why not enhance Blaze as an integration framework to acquire React components? Why not select a natural way of integration of Meteor but to introduce an extra incompatible React as a master?

From business point if Meteor’s goal is to be acquired by Facebook or Google/Microsoft, I can understand the effort to make Meteor to become part of React or Angular. But big companies may just want to destroy a potential competitor in the future and not care of its technologies. It is very risk for Meteor to leave its core technologies away.

That Meteor does not focus to build and defense its own ecosystem but to enhance its intruder’s is completely violate common sense.

Tomorrow, who knows, I may use Swift 2 to develop Cloud applications. The world is full of selection.

32 Likes
8

“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.”

We use Blaze 1 extensively in our production application. If this move to Blaze 2 requires extensive work “porting our templates” then it will be a costly setback.

16 Likes
9

Starting a new app, looking forward, which would be the less time consuming upgrade path in anticipation if one were to target blaze 2:

  • blaze 1 to blaze 2

or

  • react to blaze 2

and of course while it is great that you are planning on kicking off this week, the more important date/timeframe is when you are expecting a sensibly usable (pre)release, so when would that be in terms of a ballpark estimate?

9 Likes
10

When we are working towards future and trends.
Are you going to rework minimongo into Redux-like immutable state atom to enable the main advantages Blaze had (detect if component should re-render) into React’s shouldComponentUpdate ?
With FlowRouter SSR and transfer of SSR computed atom state to client side (inspired by fast-render) it could become quite strong and performant framework.

11

I think Blaze 2 could be plugable as React or Angular and Blaze 1 could be still available to use (although unmaintained?) as a separate (old) view layer. So small apps (or too big for rewrite) could still use it without compatibility issues. Or maybe we need only templates for React as separate package without naming it Blaze 2?

3 Likes
12

Bringing in the best of the React and Angular ecosystems seems a very sensible move, at least in terms of MDG focusing on what makes Meteor special. People don’t use Meteor for the tempting language, they use it for the full stack.

The best parts of Blaze are how easy it is to get started with and how it gives you most everything you need to get the job done. Blaze lacks when it comes to handling local/internal state while React has this nailed down very, very well with props and composing nested component hierarchies, with data flowing from higher components to lower components. Blaze also lacks when it comes to namespacing templates: sprawling, huge projects can have well-scoped components using Packages but still find Templates exposed under the global Template.myTemplateName object. This global scoping is a major weakness of Blaze vs React.

My latest project is React-based, and is extremely well-scoped due to a package-based architecture coupled with how React handles declaring components. I can have IndexView be the de-facto view for my index route for each of my “controllers” (each is its own package), so my controller packages have the same layout, making it easy to create new controllers and onboard a developer - all the controllers look and function the same, all thanks to proper scoping.

For “Blaze 2” - I think React is in great shape as the next primary templating system, and the existing documentation and examples with FlowRouter and ReactLayout (Thanks @Arunoda!) made this a day or so of study and experimentation to learn. I would, of course, expect Meteor to be fully pluggable for any templating system. Even my current project is 99% React-based but uses a couple of packages that provide Blaze templates - and they “just work” right next to each other.

When it comes to having to update old applications to support the shiny, new developments in a framework like Meteor, that’s part of the cost of using any framework (See Angular 1 jumping to Angular 2, jumping between versions of Rails or Django or Yii or any other framework). Fortunately, React has the ecosystem and momentum that Blaze is likely to never achieve, meaning that over time the support for React will last far longer and better than what we could ever expect out of Blaze. It also frees up MDG to focus on the improvements they know the community needs (1st class database alternatives like SQL, Rethink, and Graph databases; OFFICIAL TESTING FRAMEWORK; Improvements to routing; Lower-cost hosting plans on Galaxy for personal projects).

This is exciting!

14 Likes
13

I cannot speak for React, but we’ve invested quite a bit of effort to combine the “one direction data flow” with Tracker capabilities of Blaze.

In a nutshell what we call a “component” is:

  • a template augmented by an interpreter.
  • on creation it sends a message asking parent template to bind its free reactive variables to the client app state.
  • on desctruction in sends a message asking parent template to unbind its free reactive variables.
  • During its living time, it may send a finit set of messages for the parent template to interpret.

We earn:

  • super late bindings that is crucial for complex app (> 40 templates)
  • fine grained tracks of what is happening by logging messages
  • very neat separation between the “source of truth” that comes from the DB and local states (ex: text in an input element in the DOM)
  • full exploitation of Tracker:
    – a = new ReactiveVar(...)
    – b = new ReactiveVar(...)
    – c = new ReactiveVar(...)
    – Tracker.autorun(() => c.set(a.get() + b.get()))

where a, b, c could be Mongo.Collection

It’s quite easy to split a component into sub-components and assembling them using the binding mechanism described above: this aspect is crucial when the app is expected to “grow” vs being planned.

Hope Blaze 2 will let us keep this pattern or give us a better one…

Anyway, loved the Meteor experience so far (apart the DB part so +1000 for GraphQL and the direction it takes with DB)

1 Like
14

I hope you will use blaze style templates (with if else, for or each) but in JS part you’ll do NOT use syntax of Blaze like react-blaze do:

 <template name="someName">
    <h1>Hello {{name}}</h1>
    {{# if isOK}}
      <button>Click me;</button>
    {{/if}}
 </template>

 Template.someName.onRendered(function() {}); 
 Template.someName.helpers({
    name: function () {},
    isOk: true,
 }); 
 Template.someName.events({
   'click button': function (event) {},
 });

but will something more close to original React and will move events into actions (onClick, onHover …) like is done in React and was proposed for Blaze2:

  <template name="someTemplate">
     <h1>Hello {name}</h1>
     {{# if isOK}}
         <button onClick={this.myclick}>Click me;</button>
     {{/if}}
  </template>
 
 class someComponent extends React.Component {
     static template = 'someTemplate';
     componentContext = {
         name: function () {},
         isOk: true,
     }
     componentDidMount () { 
     }
     myclick (event) {
     }
 }
2 Likes
15

I like the idea of Sideburns :smile:

2 Likes
16

which would be the less time consuming upgrade path in anticipation if one were to target blaze 2:
• blaze 1 to blaze 2
or
• react to blaze 2

I was going to ask the same question. I’m building a new app: should I use today’s Blaze or React? Or does it matter?

2 Likes
17

One thing I think is missing from Blaze and the entire front-end of Meteor is integration with NPM and modules. Module importing is one of the things that makes development in React and React Native so easy and clear and it is entirely missing / non-compatible with Blaze and the Meteor infrastructure. Yes, there is the meteor-hacks package but it’s just that - a hack. I think this is a huge shortcoming and missed opportunity.

4 Likes
18

Hi all,

For those of you who don’t know me, my name is Evan, core dev at MDG, and I’ll be working on this new “template on React” integration outlined in Geoff’s post.

We are well aware of community efforts like Sideburns. Sideburns is great in that it provides some of React’s benefits (primarily SSR) while retaining most of Spacebars’ template syntax and Blaze’s JavaScript API. In fact, a while ago I did an experimental branch compiling Blaze templates down to React components, which is very, very similar to what Sideburns does.

However, we’ve come to realize that while Blaze is super easy to pick up, there are some inherent design decisions that makes your UI harder to debug and maintain when the scale of your project grows. I think @brentjanderson has made some good points in his comment:

Blaze lacks when it comes to handling local/internal state while React has this nailed down very, very well with props and composing nested component hierarchies, with data flowing from higher components to lower components

So instead of keeping the old API and treating React as a low-level implementation detail, we want to embrace its strength (the component model and related JavaScript API) and providing on top of it what people like about Blaze (templating / reactivity).

The obvious next question is: how will the template syntax look like? In fact, I’d like to gather some feedback before committing to a design proposal. I would greatly appreciate if everyone can share their perspective regarding some of the following questions:

  1. What do you like about Spacebars’ syntax?
  2. What do you not like about Spacebars’ syntax?
  3. What do you like about JSX?
  4. What do you not like about JSX?

Finally, we don’t have an estimate for when this will be available yet, but we will try our best to keep the design/development process open and public so the community can get a good sense of progress.

24 Likes
19

In terms of modules, @benjamn is making some exciting progress on that front. If you are interested you can dig into his WIP pull request: https://github.com/meteor/meteor/pull/5475

4 Likes
20

I have mixed feelings about this, on one side I really like the idea of this direction even though I’m not the biggest fan of react but this makes sense and would be excited to see this. On the other hand I really like Blaze and how easy it is and I like the separation of html and JS with onRender, onCreated and so forth.

I think writing HTML tags in JavaScript is wrong, I don’t understand how this is accpeted

var ProfilePic = React.createClass({
  render: function() {
    return (
      <img src={'https://graph.facebook.com/' + this.props.username + '/picture'} />
    );
  }
});

I’m also worried about how I use Blaze 1 extensively in client projects and internal projects. If this move to Blaze 2 requires extensive work “porting our templates” then it will be a costly setback.

I also like the idea of having that separation were I or my client can choose the framwork for the job, maybe use Blaze for a simple web app, or use Angular Ionic for a mobile or react for a web app that requires a lot of components.

Having the option to chose and select different frameworks I believe is one of the things that makes meteor so strong and if a year from now something new comes to play meteor can support it.

Let’s be honest every year we have new client side frameworks

12 Likes