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.
ā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).
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.
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.
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.
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
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.
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.
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
Their financials show it hasnāt made much money, an Ad Agency will remain that no matter which way you dice it.
