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.
One of the great things of React is that HTML and JS are combined for each component. Trying to separate them again via templates makes no sense to me.
I’m not sure why everyone in this thread isn’t seeing that something is being done about all these Blaze-related problems right now. You guys just blurting things out without reading what everyone else is writing? Whats the point in that.
…I’m working on making this transition 100% seamless, and it’s looking very good. I’m currently working my way backwards by making React feel more Blaze-like, and then back to completing Sideburns to render Blaze 1.
Here’s the thread you guys should be following:
And the package you should be trying today with React:
you can try the demo app with 3 commands:
git clone https://github.com/ultimatejs/tracker-react-todos-example.git
cd tracker-react-todos-example
meteor```
I guess I’d be less inclined to “blurt things out” if your efforts were officially supported / going to be adopted by the MDG. (Although I see @sashko did like your post!)
yea, well this is how you do it. MDG is very conservative. We gotta show them exactly what we want here. They have integrated plenty of community things into core. Hell, they hired the guy who made the phonegap stuff.
