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.
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? 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.
Best,
Abigail
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.
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.