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’?
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.
“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.
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?
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.
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?
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).
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)
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:
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.
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:
What do you like about Spacebars’ syntax?
What do you not like about Spacebars’ syntax?
What do you like about JSX?
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.
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
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
To answer Evan’s questions: Spacebars are simple and intuitive, and its dead easy to work with them, especially with Tracker-based stuff and the easy helper’s syntax. With JSX, I think the points against it you drew out in your Vue comparisons are spot on ("[it] ends up looking more like a piece of program (which in fact it is) rather than a visual representation of the interface"). With Blaze 2, I think what many of us hope to gain is incremental loading and SSR.
I think a 100% foolproof way to go would be to start using React now. The “Blaze 2” thing is mostly for people who don’t want to deal with the details of React and its JSX syntax, but if it works for you then I’d say that’s the way to go.
I really think Meteor is all about the front-end experience. The build tool and the back-end kind of disappear. I find myself building front-ends first and then thinking back on how I want to wire the data to them. And with autopublish functionality, that just gets reinforced. If you guys need any feedback along the way, I’ll be the harshest critic
+1 for @serkandurusoy, and its not even HTML but “XML-like Syntax”
Some of us written apps in Blaze and they are pretty good with that. They wanna use cool features like SSR and so on without re-writing their templates.
Some of us like to use html templates. For an example, I had a chat with @sacha and one of the main reason he(Telescope) can’t jump into React is the lack of theming support in JSX. (Basically, he want to allow people with good HTML/CSS skills to theme Telescope rather asking them to learn JSX and React)
Some of us want more power to spacebars. That’s where BlazeComponents camp exists for.
Others are just afraid of JSX at first(like me) and after they get familiarized with JSX, stick with it.
