@batist Yea! I actually did that right before I switched to React, it works rather well.
The main difference between Blaze and React is that in React it’s highly recommended to compose components like this and in the Blaze community it’s not, preferring the least amount of work.
Personally that pattern has saved me hours when updating a site with several hundred inputs (by changing all the behavior in one place).
I really do think Blaze (as-is) is capable of much more maintainable templates that what we normally see but there isn’t a lot of examples like yours in the wild
In fact, re-reading Geoff post again and again, i’m not 100% sure i understand what their plans are.
If they want to concentrate on React, that’s their choice.
If they want to stop adding features to Blaze 1, that’s their choice.
But please don’t deprecate Blaze 1, don’t force us to rewrite everything. I’m ok to start new projects with react (i have been doing so since this summer), but i don’t want to have to rewrite my main (big!) app, that would be far too costly for me.
Making Blaze 2 backward compatible would just give us the same thing with it’s problems but a different implementation, so that doesn’t make sense at all.
As MDG have suggested, a similar, but improved syntax on top of React, seems to be the right thing.
- Stop future development on Blaze - Pick React for the main view layer to leverage time/resources/value - Build a thin wrapper around it so that you can have sep. templates and script files - Allow Blaze-1 to include new Blaze-2 packages and vice versa - Blaze-1 will still work just like it does today
Building the thin wrapper around it allows them to get great performace and move on to other more important things that Meteor needs (like oplog, ES6 modules, webpack build).
No, that’s not good for anyone. If a team wants to use React (and they don’t have to) then there is a tradeoff that has to be made. Designers will need a bit of ramp up time but we’re not asking them to write lisp… it’s slightly different than a handlebars template (they can get gnarley with context/if-else/custom blocks as well).
A week or less of training and they should be more than ready to open up a jsx file, scroll to the render bit (at the bottom by convention) and then tweak the HTML as needed. Typically they’re just adding in classes and divs.
Going a step further and adding a loop is not much different than Blaze… I don’t expect they’re writing these for you and the frontend team can convert the static tab into a map/each block
If ones React components are radically more complex than this than one is probably doing it wrong (I did when I first started, everything was mashed into one or two components).
Here’s the same thing in Blaze… not terribly different.
If it was marketing that MDG drives, they would have chosen to treat installed base, Blaze and a router, testing choice, as priority. React, Angular and all the other next great things would be community add-on / overrides. Marketing is about being consistent.
It’s taken me 3 days to read this entire thread, so I feel I have to add my 2 cents.
What I like about Blaze is that the template is basically HTML and the JS is responsible for data providing/event handling is separate. This keeps things clearer in my view and easier to manage and maintain.
However it does have a lot of things missing that I would like and have been exploring things like @manuel’s ViewModel to achieve these. The lack of state and managing the data context is the worst part of blaze right now for me, I work daily with Ember and constantly miss having proper models in Meteor, but on a daily basis I have pain points going from Meteor > Ember also
With regards to React I have no real application experience with it as every time I look at it JSX just seems like the wrong approach to writing templates to me. While I do understand the power of React, JSX is one of the major things stopping me exploring it in Meteor.
If the suggestion, as it appears to be, is to add blaze like templates on top of React then I can see the benefits of that.
But I also like I lot of what @faceyspacey has been saying about his work on sideburn and blaze-react (and as said earlier ViewModel) so I’m hoping a lot of those ideas will be part of what appears as an end result of whatever Blaze 2 becomes.
I think the original post probably muddied the waters too much and later clarifying post by @gschmidt did help me understand their intentions better.
Finally I’d like to add my voice to the many like @joshowens who feel that fragmentation of the eco system should not be underestimated here.
Yes, that’s exactly my main concern. Let alone all the incompatibilities arising from these splits. Plus those arising from breaking changes in new Meteor releases. I’m still on Meteor 1.1 and now faced with packages that only support 1.2 onwards. Hey, 1.2 was a minor (!) release… In my opinion, this should not break anything at all (at least, if it is avoidable). But maybe I’m too corporate-minded after having worked with large enterprises for such a long time
To get fully reactive React components one could take a head start by forking Mobservable, which adds Tracker inspired reactiveness and sideways loading to React components without compromising readability:
import React, {Component} from 'react';
import {observer} from 'mobservable-react';
@observer
export class ArrowView extends Component {
// renders whenever the arrow,
// or the coordinates of one of the associated boxes change
render() {
const {fromBox, toBox} = this.props.arrow;
const [x1, y1, x2, y2] = [
fromBox.x + fromBox.width / 2,
fromBox.y + 30,
toBox.x + toBox.width / 2,
toBox.y + 30
]
return <path className="arrow"
d={`M${x1} ${y1} L${x2} ${y2}`}
/>
}
}
Spent over $30k on Blaze software, using today’s features, not expecting or waiting for the future.
Blaze today’s features are working. I bet that Blaze bugs will continue to be opened and closed. Just not features, not anymore.
So, why complain about what was created and is working? Which money was spent that was wasted?
It makes all the sense if you’re only concern is to improve the framework in a bubble. If you have a few clients or major projects using Blaze, to hear that “you’re issues will never be addressed nor will we ever improve it, switch to React now or wait a year or so while we hash out Blaze 2, a complete incompatible system”
Perhaps the message should be: “We’ll continue to support Blaze while we have it render to React. Then will create another rendering engine better than Blaze. Once that is ready, all your new projects start with Super Blaze as we will then slowly peel away Blaze from Meteor.” Interestingly, projects like Meteor Components and ViewModel can potentially act as a wrapper around Blaze and Super Blaze.
From what I can see, Meteor is looking at this from a commercial standpoint. They want to embrace their “competitors”, React and Angular, to attract more consumers for their cloud compute solution.
I didn’t come to Meteor for React or Angular. I came for Blaze.
You keep talking about a technical opportunity, but here the problem is to put customers first. That’s what 20 years in IT consulting business taught me.
The community is your your customer, people who believed in Meteorjs potential and, as @joshowens previously stated, bet their reputation and money on that. Alongside those people there are others like me who invested the last year building a product using Blaze, and now you told us we need to start all over again. That’s a damage in the hundreds of thousand of dollars. Who pay for that? That’s simply not fair. How can we trust you in the future? How can we use meteor to create our customers applications?
Meteor is a great software framework, but at this point we need stability more than innovation.
Who knows how many others React will we meet along the way?
Can we trust you about meteorjs backward compatibility in the long run?
