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?
I’m as repulsed by jsx as many of you are, but I do understand the technical and common sense reasons for the MDG wanting to move over to React.
That said, I still find it depressing and demotivating. Blaze is a joy to use. meteor add lots-of packages that-depend on-blaze has made prototyping and developing stuff so easy.
With one large app in production and another half written (with Blaze), every line I type feels obsolete before its committed.
Meteor was the only thing that made me want to get up and code every morning. Not really feeling it anymore …
It’s not commercial to alienate your installed base so harshly. And to hair-split your supporting ecosystem into little fractions with each it’s own religion.
I was too at first, but actually-- it makes complete sense. Think about it. When you’re using blaze, typically you’ll have and myTemplate.html and myTemplate.js (for event hashes, helpers, etc). There’s a 1:1 mapping. The view and it’s ‘controller’ are tightly coupled. When I’m working on a template in my editor, 99% of the time I have the HTML file open side-by-side with the JavaScript. JSX acknowledges this fact that the two are inseparable. Unless you have large templates with complex helpers, event hashes, and DOM’s, then having the two in a single file shouldn’t be too much of an issue. From a software engineering perspective, I could see the ‘Separation of Concerns’ argument being made, but the two are so tightly coupled, that argument seems fairly weak.
From a commercial perspective, I could see MDG wanting React/Angular to attract enterprise clients-- from a business perspective, this is perfectly valid. We, the community, can only win if MDG wins, that way it can continue to support and strengthen Meteor core. MDG has to make Meteor as attractive as possible to the Enterprise.
I agree with this general sentiment, I already find it quite annoying when I come across example code in coffeescript.
Pick a language and stick to it (Hint: JavaScript) - if others want to enhance their own apps with nonstandard code that will go out of fashion in a few months that’s their call, but more emphasis should be put on standardisation. As others have mentioned up-thread, that’s kind of what makes meteor what it is - a standard set of core tools that all work seamlessly together.
With regard to the more specific conversation I probably don’t have enough experience with the various front-end frameworks to have a say - but I must say the uncertainty isn’t comforting. Choosing to ditch a bespoke solution for a proprietary third party solution (potentially engineered by Facebook no less - shudder) is a pretty major step backward IMO.
Historically speaking, javascript was the “proprietary third party solution” as the scripting language of a browser vendor.
Over it’s first 4 iterations, from Mocha, through LiveScript and ultimately to JavaScript it had Netscape (the originator), AOL, Microsoft, Yahoo, Macromedia and Google all, at one stage an another, trying to pull it in various directions.
We’re using it today because these behemoths lent their support to it.
Aggree on you with the standard code.
I’m starting to feel kind of silly when I suggest a view layer as Aurelia, as is the most unobtrusive, modern, flexible and standard base framework out there as far as know. I would really like to hear arguments against it, so I don’t sound like a parrot anymore
Just like with Blaze, it doesn’t have the backing that Angular and React have. As Evan You mentioned, the teams behind the latter two have teams probably larger than all of MDG. So, if the guy behind Aurelia decided to work on another project, you will go through this again.
And had Meteor been a PHP framework a decade ago and the makers suggested moving over to JavaScript, I’d probably feel the same
If Meteor had been built around React then I’d know no different. But it wasn’t, the package library, tutorials, examples, production sites etc. have largely been built around Blaze, the Meteor front-end, basically. A shift from that is a big change, even if you happen to already be using React (which I gather many Meteor developers are) - big changes in such a young framework can cause a lot of turbulence - and for me, a newbie who’s only halfway through an app, I don’t really know what to do - it’s put me in a state of limbo. I can’t afford for packages I rely on to lose support because they’re for a deprecated front-end, not in a framework that’s only just pushed past 1.0. The same thing stopped me going anywhere near Angular.
React does look interesting though, I’m sure if I’d never known blaze and it worked seamlessly with Meteor then I’d love it - I’ll wait and see what happens, I’ll keep reading what more experienced devs than me have to say.
To be fair, MDG has been an innovation company/business for the past three years; and is having some growing pains as they pivot to managing operations. (There’s a pager rotation nowdays, for example.) And they’ve put a lot of infrastructure into place to keep things backwards compatible. The question is whether the processes are all in place to use that infrastructure to keep things stable and backwards compatible. Not entirely. But it’s close.
It’s a bit of a damned-if-you-do-damned-if-you-don’t situation. They were constantly being criticized for not supporting Angular and React before.
Personally, I was on one project that had $100K of work done that was scrapped, and had Angular support been available, the team would have been much more on board and it probably wouldn’t have been scrapped. So there’s real value in what they’ve done. In some ways, I can totally see how it’s being responsive to what was happening back in 0.8 and 0.9 days. It’s just that the law of unintended consequences winds up opening up a new box of worms each time they upgrade.
As for fractions with different religions, distros would seem to be the way to go. RedHat, CentOS, Debian, SUSE, Ubuntu… there’s some great precedence on how to run separate distros of open-source software to support different communities.
For what it’s worth, I was pretty frustrated for a while also, for the same reasons. Starting our own distro/release branch has gotten a lot of the joy back.
Can you imagine using a long-term-release distro, where you wouldn’t feel everything is immediately obsolete? Like getting started with Ubuntu, but then realizing that using CentOS will get the long term support and production devops you were looking for? My hunch is that the overall Meteor ecosystem is heading towards that kind of solution (whether people realize it or not). It’s certainly what we’re betting on.
Most of the people worried about stability and backwards compatibility are precisely those people who have invested large amounts of time and money into building large templates with complex helpers, event hashes, and DOMs.
As far as having multiple files open, another approach is to hack our editors and utilities to manage bundles of files at a time. Which is exactly what we’re doing with Atom and StarryNight. Right click on a directory, and refactor the whole thing. Custom GUI panels to edit CSS; ala VisualStudio; etc.
Quote
"Libraries like Angular, Polymer and React are neither official products of their associated companies nor is any official support or commitment to the library by the company guaranteed. However, Aurelia is an official product of Durandal Inc., has commercial and enterprise support available and we are committed to it over the long haul. If your are building core technology for your business, you want to know that your technology provider is as committed as you are. Aurelia is a clear choice."
And by following lately all the intermediaries surrounding that statement, it appears to be a valid one.
What is obvious is the power of community that supports any tech.
Web landscape, in recent, has massively shifted for the better…
Facebook/Google have billions of dollars - Angular and React are probably being expensed without notice. Though they are not ‘official products’, they have organizations set up around them and I don’t think the big companies would dare the backlash of dropping support for them - plus they are probably great recruitment tools. From what I can gather, Durandal attempted to raise 95k through crowdfunding but came short at 36k. I am not able to find any other data to see if they have revenue/backing.
