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
What I meant was this: FB is not in the platform business. But it makes sense for someone to leverage their technology and become that platform / hosting provider. I don’t see MDG becoming an acquisition for FB as it is out of scope of their core business (monetizing users and their information).
Google on the other hand is trying to also be a platform (AppEngine etc.) – in addition to making cars and sunglasses Their financials show it hasn’t made much money, an Ad Agency will remain that no matter which way you dice it.
Right. Also, from the Meteor’s next big move:
“The $20M Series B round signals MDG is working on something big. The Series A round was used to build out the open source Meteor API, which is now a Top Starred repo on Github. MDG is now focused on working closely with the teams at Google to port and maintain Kubernetes support for AWS. Being able to harness the power of Docker containerization, with the orchestration capabilities of Kubernetes along with the largest, most advanced cloud infrastructure, AWS would be game-changing.”
No, we’ve identified that there are some crucial packages like useraccounts and autoform that we’ll need to figure out replacements for before building an app with React is a smooth experience. The space of React best practices in Meteor is also not very well explored yet, so we’re going with Blaze as a safer option.
However, we’re carefully recommending Blaze patterns that involve a decoupled, componentized approach, so if you want to switch to React later it will be easy to do it one component at a time.
Our business and technical goals are to build the best platform we can, with the resources we have. React and Angular 2 are, in our opinion, the best bets on view technology for the next few years. GraphQL is similar to what we would have to build anyway to support multiple databases in future versions of Meteor (it has a very convenient syntax for specifying joins that we would need for SQL support).
6 Likes
so you are writing a guide using a deprecated library for examples? Isn’t this crazy?
Do you plan to rewrite it soon?
1 Like
I’m not even kidding - this is great IMO 
1 Like
I wouldn’t called it deprecated yet - It still works a lot better than React in the Meteor stack IMO. I’ve tried to have it place nicely with Tracker, but I just can’t get the full rerenders to play nicely with fine grained reactivity.
1 Like
[quote=“goatic, post:25, topic:15827”]
I’m not even kidding - this is great IMO
[/quote] @goatic I think you misunderstood 
1 Like
What I understand is that 1.3 Meteor guide will be written (loosely) around Blaze. Correct? Because, that’s what I’m applauding, as I don’t feel strongly for using React beyond sandboxing.
1 Like
This is great news! Thank you.
Blaze remains a great templating tool and so much is built on top (including important packages on Atmosphere). My honest recommendation is to let the community figure it out. MDG did a great job with the first iterations and things are working quite well (at least for most of us).
Angular and React may be the ‘best bets’ for the future, but will you be able to support 3 (including Blaze) ?!
I think there are three main motivations that make it OK and also desirable to write the first version of the Meteor Guide for Blaze:
- There has never been an official Blaze guide before. For people who are already building apps with Blaze, it will be useful to have a record of how we intend it to be used. This will also serve as a great starting point for any transitional materials to React.
- Blaze is currently the best understood and smoothest way to build an app in Meteor. We can look at what we have for Blaze, and figure out how to make React and Angular feel just as smooth.
- Only about 20% of the guide is Blaze-specific. All of the other suggestions can be followed regardless of the view technology involved, and this has caused us to be extra careful about decoupling the business logic from the view rendering, which is probably good in itself!
We definitely spent lots and lots of time thinking about this decision, I hope people see the value here.
15 Likes
Jup, i really do. But personally, it’s hard to take anything it says for granted because of all the hush-hush on the platform’s future. I have no idea what still is relevant in 2 months. And it doesn’t help creating a clear picture of what Meteor is, if one innitiative is telling “A”, while at the same time other parts of MDG are telling “B” somewhere else.
That said, it’s still a great innitiative and should help anybody still doing it the “current” way. Thanks!
Based on that, it seems future core developments will either split or more likely be purely react focused after a while once nobody cries about Blaze anymore. Does that mean if I want to use anything else than React, I should consider moving away from Meteor? The current developments really sound like “Ok, we’re going full React stack, if you want to use another view layer, good luck” Is this perception correct?
Right, there are some serious communication mishaps. Personally, I think we need a clear separation of:
-
Future of Meteor platform in itself – with the hope of REALLY involving the community, not making decisions on their behalf (here is an example: Oracle’s approach with MySQL resulted in a fork with MariaDB, which experts I trust have claimed is better in many aspects, including performance in some cases). A community-driven fork of Meteor is the last thing MDG would want now.
-
Future of MDG - i.e. how it plans to make money and how that relates to Meteor. There are many successful freemiums out there - e.g. paid analytics, not just hostings – anyone seen the Twitter messages encouraging a switch from Modulus to Galaxy :), or open-source code vs. paid SaaS
It could be that unleashing Meteor to the community and letting it start to improve it is the way to go, rather than ‘We did not take this decision lightly’ … kind of message. Who is the ‘We’ … the community or the company 
1 Like
#Strategy 6 “Use Blaze.”
As meteor packages will become NPM packages, Blaze program can also call them as well.
So if all packages/components can grow up and work how could glue code died?
It is a hyper that Blaze can not be applied to build a big application. Isn’t Telescope a big app?
It is a hyper that React will dominate everything in JavaScript. React is only a tech path.
It is a hyper that Nobody will use MongoDB. The data showed that MongoDB was the fastest growing database.
Blaze+Package+MongoDB is a very powerful and simple tool to solve many hard problems.
BTW. Meteor Guide is a nice guide. Actually it is also a nice Blaze Guide.
7 Likes
Does that mean if I want to use anything else than React, I should consider moving away from Meteor
No, they are also giving angular first class support as well. Once NPM also works, you should be able to use any view layer you want. You (or the community) might, however, have to do some work yourself to get the same kind of integration as angular and react.
2 Likes
Another critical layer in this stack is the presentation layer. Using Angular / React / Blaze in this case becomes a moot point as using a presentation layer such as Bootstrap or Material is another moving part which should remain more or less the same. In this way the Meteor engine along with data layer and control layer could all change, however the presentation layer should just “keep working” .
What I’m suggesting is a stronger focus should be made towards being able to maintain a single presentation layer regardless of what the other moving parts are comprised of. Personally I’m looking at using Material components, but everywhere I turn there is a different approach to their use in Blaze, React, Angular . . An effort should be made to enable devs to build their content using a chosen presentation layer, then be able to use that same layer in meteor regardless of its internals. I’d still like to use Material components the same way, whether I use Blaze, Angular or React
1 Like