After discussing a lot about React, the future of Meteor, and answering a bunch of questions, I decided to write this post on medium.
I think it a useful article, and it also has a good deal of humor to lighten the mood 
6 Likes
A good guide is very important. It like this guide project. Good Job +1
Will the guide updated for the meteor 1.3 ?
Yes, right now it’s in a “preview” stage - the initial release will come out with Meteor 1.3, and will include recommendations about how to use all of the new features in that release.
4 Likes
Thanks @vonwao for this article, it’s spot on. I’ve been frustrated at the idea of choosing between Blaze, Angular and React. I like the idea of being able to sink my teeth into a stack that works well together, with minimal fuss (the original appeal of Meteor). I’d really rather get on with coding business logic, rather than having to re-learn the next new hotness. I’m not a full time developer, but like to code in my spare time. Committing to learning a new “framework” takes time, and I think people made an investment in Meteor, hoping that most of it will remain relevant in the years to come. Your article reminded me that it is, and I can just refactor when necessary. Deep breaths.
1 Like
Strategy number 0: understand the powers and limitations of Meteor itself (or any other tools) and try not to rely on Meteor to do everything (which is impossible). For the community, this kind of attitude is a much needed antidote to the poisonous idea that “Meteor is doomed because it can’t do X or it can’t do Y”, without thinking that maybe Meteor was never meant to do X or Y.
This great article states my view better and is definitely worth reading: Overcoming Intuition in Programming.
5 Likes
Thanks for linking to that blog post, @irrigator. It’s one of the best I’ve read for a long time!
Here is our strategy #1: Depend on Meteor internals as little as you can as Meteor will change dramatically over the next few months / years.
Not to start the Blaze / React flamewar again, but we decided to reduce our dependency on what MDG does. So we abstract Meteor internals with our classes, that we can then swap internally with other implementations. In the future, we will move to a pure node.js implementation as we are not comfortable with that MDG is doing. This is aided by the fact that NPM is getting native support. So we can go through a slow and controlled transition.
Our goal is to (1) develop things quickly AND (2) maintain for the long run. Objective #2 seems to be a challenge as we look at what veterans are complaining about when MDG breaks things. Objective #1 will dissipate as we need to learn React (which we are not interested in, as it is not an industry-standard) and other FB technologies. GraphQL is also not a standard and is another FB re-invention of already existing technology.
5 Likes
Curious which one?
Also, I’m surprised that people give so much weight to web standards. There are entire graveyards full of “standards” that are now long gone and deprecated, or worse never even made it to fruition - for example WebSQL: http://www.w3.org/TR/webdatabase/
I’d more likely trust a huge organization that is staking their profits on a technology (Facebook) than a standards committee.
5 Likes
I think he was referring to GraphQL, it looks like you cut off the first part of the quote.
I’m surprised you said this.
1 Like
Right, I was wondering which standard GraphQL is a reinvention of.
I guess I just hear people talking about web standards all the time, for example about web components. I would definitely not build an app today with web components, even though it is theoretically a standard that will be in browsers some day. The tools are just nowhere near what exists for other, non-standard, component platforms like Angular, React, Ember, Blaze even.
Hi @sashko,
We come from the Adobe AIR / Flash side, and client-server communication has been in use over a decade before HTML5 became the norm. For instance, there was AMF which allowed data serialization and manipulation. We also use basic JSON to get data we need via AJAX. Creating a whole new technology is fine for FB as they need to standardize. Not necessarily for the rest of us.
Note that I didn’t talk about GraphQL being a standard, I used the term technology. I don’t like React as it goes against standards – and not ones in the graveyard, but actual separation of display and scripting (e.g. Chrome Apps don’t like script tags in your main HTML for security). So JSX is going to be a challenge in the long run (i.e. mixing HTML and JS).
GraphQL isn’t about replacing AJAX, JSON, or any other data loading - it’s just a way to tell your API what data you want to get back, think of it as just a standard format for arguments to your AJAX endpoint.
Also if we’re getting into standards then DDP certainly isn’t one, but we’re all fine using it in Meteor!
2 Likes
Sure, matter of preference. My point is there is no need to jump on GraphQL bandwagon for us. But for FB there is such a need. Again, doesn’t mean we ALL have that need. Querying data via JSON, AMF or any other method has rarely been a problem for most of us.
Also, agreed on DDP, that’s what I foresee in the mid / far future where we would want to replace with REST as we move on beyond Meteor. It’s fine today – but there has to be a clear path for us for tomorrow.
Overall, FB technologies seem to be on the path to replace the whole Meteor stack. If you flush Blaze, Tracker, Pub / Sub and soon (in my opinion) DDP with another FB technology (writing on the wall), what are you left with?
(hint: FB technology stack)
I see Galaxy becoming the hosting portal for FB technology stack which FB is not going to be interested in getting into as they are focused on their B2C business.
2 Likes
Maybe MDG as an Talent and Tech acquisition target for FB then? 
Probably doesn’t hurt that Marc Andreessen is a MDG VC and FB investor.
Anecdotally, it might be interesting to read a little something about Meteor’s next big move.
From the article:
“… AH would invest most of the $11.2 million of Series A funds into a company called Meteor Development Group (MDG). At that point, MDG had ideas for a commercial product, but were 100% focused on building Meteor’s open source framework and community first. Fast forward to May 2015 and AH would again participate in MDG’s $20M Series B round. But this time, all the focus was on the commercial product in development: Galaxy.”
Definitely not - I don’t see why Facebook would be interested in building and maintaining a user-friendly development platform.
Talent and Tech acquisition?
If I wanted to work at Facebook, I’d just apply to work at Facebook. I’m at Meteor because my passion is to build the best and friendliest JavaScript platform that we can achieve. Facebook’s technology is often built for Facebook scale, and Facebook engineers. That stack by itself isn’t useful for most of the world, but they have some great ideas that I believe can be expanded and polished to make something much more streamlined and beautiful.
23 Likes
Will this transition include a swap from Blaze to React? I’m sorry if this is already answered elsewhere. Looking very much forward to having your guide along with a new release! I find exploring your new implementations into Meteor VERY fun to tinker with upon release, and really look forward to 1.3 now that I have the shiny guide along with new shiny stuff like modules
@sashko, will you speak to this? I mean, it seems likely that MDG is moving to a FB tech heavy focused distribution framework with the stated move to React and GraphQL and all this implies. Are we wrong? If MDG is, what’s the rational behind this move from a business and technical perspective?
2 Likes