Next steps on Blaze and the view layer

[slava]

So we’re de facto pushing people towards React, which then makes me question why we need Blaze 2 at all…?

So for me the whole point is to make it very easy to migrate from Blaze 1 to Blaze 2, to the degree where it will still make sense to use Blaze 1 up to Blaze 2’s eventual launch. As long as we keep that in mind I’m very excited for the future!

besides this, the point is to keep the default front-end approachable and keep the things people like, or as Geoff put it:

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!)

[sacha]

besides this, the point is to keep the default front-end approachable and keep the things people like

Oh don’t get me wrong, I think those are great things. But they strike me as nice-to-haves compared to the big problem of knowing what to use now, and having a clear upgrade path.

Put another way, I would rather switch to React just to ensure I don’t need to rewrite a huge chunk of my codebase 6 months down the road, even if it means saying goodbye to approachability, templates, and all the other things I love about Blaze.

[tmeasday]

@benja

There will always be new and better libraries/frameworks for development

This is my point though. I don’t think what’s happening here is “oh, wow, React is so cool, we must have it!”, but rather “Blaze needs X, Y, Z. What’s the best way to get that?”.

You could argue that we wouldn’t be talking about X, Y, Z if it wasn’t for React, and maybe there’s some truth to that, but as you can see in the video I posted above, a lot of this stuff has been on people’s minds even before React.

[joshowens]

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!

That is awesome, and I really appreciate you keeping all that in mind!

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.

I never implied that, I think… If anything, I think React is a smart long term move, hence I am switching Crater’s wider focus & my training materials over to React soon. Blaze could never compete with a team of people that care about things like Instragam and Facebook in the long term. Frankly, they are building apps with their tech and MDG isn’t at this point (aside from the Galaxy UI, which is nice), so I would never expect MDG to.

Embracing the ecosystem is a core tenet of the platform and I will reiterate that I am glad to see it happen.

And I think @joshowens does so as well!

Indeed I agree! And well said @timbrandin, I am all for more of these types of posts.

[tmeasday]

So we’re de facto pushing people towards React, which then makes me question why we need Blaze 2 at all…?

Having written large apps in both Blaze and Meteor+React, I honestly think that if we get it right, “Blaze 2” will be a lot more like Blaze than React.

The real challenge in porting an app from Blaze->React is not syntax changes, it’s a change in mental model in the way reactivity works – you have to pre-prepare all your reactive dependencies in .getMeteorData(), and then be non-reactive elsewhere in your component. This is a huge difference to Blaze where you can pepper your template with calls to reactive helpers.

So, if “Blaze 2” means you don’t have to make that mental shift, I honestly thing the upgrade path should be relatively mechanical. Of course I don’t even know what the syntax of “Blaze 2” looks like yet so I am talking at a very abstract level here!

[p4bloch]

It’s exciting to see this roadmap for Blaze… thank you for sharing this with the community!

What are your thoughts on Flux and Redux and the whole immutable point of view that react’s community is pushing forward? Do you plan to integrate some of this mindset into Meteor’s reactivity? I’d love to hear what you guys think about this.

Thanks

[benja]

I agree and React may be the right way to get those things. I was just presenting what I think are legitimate fears of a lot of developers including myself.

At the end of the day I am really optimistic for the future of Meteor. How can you not be when you see a community who is this passionate about Meteors future?

[ralpheiligan]

“you’ll never be able to satisfy everybody, but you’ll make a whole lot of people happy when you deliver.”

I love this line…

[matb33]

There is way too much focus on the pains of migration in this thread. Prior releases have always been careful to maintain backwards compatibility. I’d expect no less from MDG than the following:

• Upon updating an existing project, I’d get a blaze-legacy-templating package automatically added.
• Upon starting a new project, I’d instead get the blaze2-templating package.

My existing blaze-based app would continue to function as if nothing changed. All good, no time investment lost. I’d also expect MDG to maintain this blaze-legacy-templating package as part of their commitment to going 1.0.0.

I trust MDG would make whatever plumbing changes are necessary to make this possible (if this isn’t already done). At the end of the day, Meteor is (or should be) a build system for apps. That’s it.

It launched with some cool packages for templating, data on the wire, latency compensation, and so much more – cutting edge stuff, even today. But Meteor needs to account for the future possibility of an alternative for any of its core features. We’re seeing this today with templating. But tomorrow, it needs to be the database. Then perhaps latency compensation. Then pub/sub. And so on. MDG is slowly going in that direction, carefully prying apart hard-coded dependencies so that the Meteor ecosystem is as pluggable as possible.

All that to say that I have every reason to believe that there is no need to panic – Blaze 2 won’t replace Blaze 1, it will simply be another templating package.

[jeremy_s]

The real challenge in porting an app from Blaze->React is not syntax changes, it’s a change in mental model in the way reactivity works – you have to pre-prepare all your reactive dependencies in .getMeteorData(), and then be non-reactive elsewhere in your component. This is a huge difference to Blaze where you can pepper your template with calls to reactive helpers.

This is a key point, and echoes Geoff’s original point above that “What’s missing from React (as a Blaze upgrade) is templates and the tight integration with Tracker.”

Tracker integration in Blaze is as fundamental to its ease of use as templating is. Template helpers were designed to (drumroll) help you, by wiring up autoruns in a way that’s targeted and transparent. .getMeteorData() seems like a temporary bridge you’d want abstracted into something more friendly, like a helper. I’m hoping Blaze 2 is fundamentally a React + Tracker marriage, which seems consistent with MDG’s original focus on dev happiness. Secondarily, I see the justifications for a templating shell over it as well.

[SkinnyGeek1010]

I agree with you, utilizing other technology to gain some wins seems smart to me. My worry again comes from living through Spark -> Blaze and the crud left over on atmosphere afterwards.

That was painful! I’m thinking that it should be fairly easy for both Blaze 1 and 2 to co-exist.

In theory a new meteor app running Blaze 2 by default could render a blaze 1.0 package/template. I’m doing this with regular React components with no issues. It just drops right in with a shim component.

Also Blaze 1 should be able to render Blaze 2 components without any issue. This is currently possible with Blaze and regular React components. React-ive Meteor is an example of this co-existence.

I’m willing to bet that MDGs Blaze 2 wrapper will interop fairly seamlessly in this regard. You should be able to use either version fairly painlessly. As with React migrating from the leaf nodes upward is the easiest path.

@tmeasday @evanyou do you have any public ideas for this yet?

[tmeasday]

I’m hoping Blaze 2 is fundamentally a React + Tracker marriage,

I actually believe the React + Tracker project will be orthogonal to the React + Templates project, and so potentially we’ll be able to offer a lot of the same dev happiness benefits even if you are happy with vanilla JSX/React. We’ll see

[tmeasday]

I’m willing to bet that MDGs Blaze 2 wrapper will interop fairly seamlessly in this regard. You should be able to use either version fairly painlessly. As with React migrating from the leaf nodes upward is the easiest path.

@tmeasday @evanyou do you have any public ideas for this yet?

I don’t think we are at that point yet, but as you say, technically it seems very feasible. If a Blaze 2 component is just a React component + sugar, then if React can embed Blaze 1, then Blaze 2 can. What it looks like (say in terms of template inclusion) is very much dependent on what the exact syntax of Blaze 2 is.

[generalledger]

Can’t you do this?

render () {
 return (
    <div>
       <h1>Click to vote</h1>
       <button onClick={this.onclickHandler}  {this.state.isOk ? null : "disabled"}>Click Me</button>
    </div>
 )
}

Edit: And, to keep this on topic and not just about React syntax, I’ll add this. I have zero vested interest in Blaze. I am all aboard the React train, but I still think @awatson1978 has some excellent points. It is going to be important for there to be a graceful deprecation of Blaze and introduction of Inferno (great name btw!). It’s just good business to not leave Blaze users up a creek.

I think MGD has made some great decisions from both tech and business standpoints, and they’ve got some pretty darn smart people working over there. I expect that whatever they elect to do will be technologically elegant and a smart business decision.

[sergiotapia]

I’m new enough to both React and Blaze, that I’m just happy there’s now a clear path forward.

Point blank MDG has just said “Use React. That is the way forward for Meteor.”

Perfect, now people joining Meteor has a clear progress path and know where to go, which has always been a problem I feel for Meteor. Too many options and the core team never backed one in particular. Awesome stuff guys!

[kamal]

I think Blaze is awesome and the Blaze model should be preserved as best as possible perhaps as it exists in Sideburns. It is a great model for smaller projects and for people just starting out with Meteor. If the barrier to entry is raised then a lot of people might miss out in the power and beauty of Meteor.

My three cents.

[aaronjudd]

I might be repeating what others have said, but I think it would useful to hear more information about the plans for testing, even if that is perhaps a much less Meteor specific solution than Velocity. Good code coverage would make migration to the next hot thing a lot easier. I’d like to give some feedback in meteor/guide but haven’t quite been able to take the time to get involved. I’ve been watching (lurking) trying get a sense of the future though, and the details still seem pretty fuzzy to me. If it’s just too early, that’d be great to know as well.

[msavin]

I’m going to rock the boat a little, and maybe repeat some astuff, to say and say that to me, backwards compatibility is not important, especially if it means trading off a proper design.

I know a lot of us are invested in Blaze 1, but I imagine that it could/would continue to work for those that do not see a big incentive to migrate to 2.0. Or, maybe they can use both and migrate a piece at a time, kind of like people are already doing with Blaze + React.

Regarding new frameworks popping up, even if Blaze has to be updated every 3 years or so I don’t think that would be terrible. Blaze 1 lasted us a long time, and this could also last a good number of years, and then we’ll figure out the next thing.

Also, +1 for the Inferno name, and if its a breaking change then maybe a rebrand is worth it. And then the community can fork Blaze if the need for improvements is that big.

[jagi]

Oh that would be nice

[hackim]

Now what should I use for my new project? Stick with Blaze?