Angular, React, and Blaze

I appreciate the post, but all of this is still a blow in the wind without any insight into the roadmap, topic headcounts and ETAs. The exact reason why our tech advisory is not embracing meteor as a full stack => minimizing dependence on meteors unknown timeline.

Odd, but after this post, we are still sticking with NPM and do not recommend to depend on meteor packages. And as Abhi put it:

@gschmidt finally pull your community tech intelligence, such as @faceyspacey, into private conversations about easy wins for meteor


I’m a Javascript veteran and Meteor noob of 1 month. I tried Blaze at day one day and thought it was super easy. Switched to React using the tutorial and found it much harder. Then I saw the news about React being the future and stuck with it.

Now I’m in love with both Meteor and React.

Today’s news had me worried at first but now I’m like “this is awesome for all of Meteor. I’m going to stick to React and will even try to contribute some packages for it.”

Thanks for the update!


@faceyspacey The MDG engineering team is split very close to 50/50 between Meteor and Galaxy and have a lot planned on the Meteor side for 2016. To your first question, we have two people (Sashko and Justin Santa Barbara) working full time on data system advancements, including SQL and our GraphQL investigation. When they have something they’re ready to share (which, to start with, will probably be ideas for discussion, not code), you’ll hear about it here.

We’re working on a more detailed roadmap. More communication along those lines is a major priority for 2016. We made a lot of progress late last year in building good communication channels with our paying customers, and we want to continue to improve that and also provide more for the broader open source community.

Forum conversations can take a lot of bandwidth because the community is so large and diverse. The last post about view strategy got 568 replies. We are working to get better at this and I think we’ve made a lot of progress over the last few months.

By the way, the stats on growth and retention are great, but we understand that that’s something that we (as MDG and as a community) have to earn every day and that we have to continue delivering the best option for that growth to continue.


This is the best strategy for everybody. Blaze, React, Angular groups can grow in natural way without suddenly abort. Hope this is the long term strategy. MDG can do some other advanced projects like improve loading and building speed like webpack, add fiber support, .etc. Meteor needs to keep its own sole cores and grow its ecosystem.


Our organization is similarly concerned with the mixed messaging and lack of solid roadmap describing the future of Meteor. Out initial attraction to Meteor was that, as a well curated, integrated, and supported technology stack, it made living closer to the edge of modern web development a more tractable proposition. I can understand replacing a “never really official” technology like IronRouter with something official like FlowRouter, or enabling alternative choices like Angular 2 or React for those who need them while continuing to push Blaze forward, but replacing both IronRouter and Blaze wholesale along with meteor packages altogether in favor of NPM starts to look like corporate suicide.

My guess would be there are business folks making technical decisions because of some internal stress over monetization. I’m truly sorry if this is the situation you find yourselves in…I’ve been there, done that, and wore out the t-shirt so please know that my sympathy is sincere. How else can any logic be found in seemingly trying to maintain your relationship with the Blaze community until your flirtation with React can evolve into a divorce with the former. For what it’s worth, if your technical team needs to convince the business side of the equation that these changes are ruinous to Meteor’s initial value proposition I hope this response helps. If the decision has already been made to wind down Meteor in scope so that the technology can somehow survive within the larger Node/JS ecosystem it would probably be better to just be very open about this necessity and we’ll help you (as a community) to do it successfully.


I don’t want to speak for everyone, but I could not possibly disagree more with this premise. Personally, I’m in pursuit of the best development platform I can build and bring to the world, and sometimes that makes making hard decisions and tradeoffs, just like in any other engineering project. I’d also say that the business and engineering goals of the project are well-aligned - growing the developer community and keeping up to date with popular and well-supported technology from the wider community is a huge benefit to engineering. It’s very hard to do engineering inside a closed box, the best ideas come from an interchange of ideas and thoughts. To me this is like saying “we already wrote a bunch of science books saying the earth is at the center, and it basically works - why should we rewrite those books to allow for the sun being at the center?” and implying that the reason is to sell more books.


This is an absolutely fair point from someone (sashko) far more likely to be privy to the truth of the matter. That said, I’m not sure I want to be on board for a quixotic quest to achieve development nirvana in pursuit of a mythical “best development platform.”

Keeping up-to-date with the JS development community in near real time is certainly one approach Meteor can take. What I think the community was hoping for from Meteor, however, and at least what I was hoping for as a technology decision maker for my organization, is some sort of leadership that taps the breaks on technological churn in the JS/web-dev space. Leadership in this case would mean curating technologies constantly emerging and disappearing near the event horizon at the forefront of web development and driving their adoption by distilling the most promising technologies into a platform that can be easily developed (and planned) against by those with somewhat less tolerance than an “anything goes” approach.

If what I have described is not what Meteor intends to offer I’ll just have to live with that but I certainly feel that a lot of us were led to believe this was the Meteor value proposition to the community. From where I sit it looks less and less likely that Meteor will provide significant relief from the “Javascript Fatigue” (sorry for using the label du jour) a lot of the community is concerned about. This represents a missed opportunity IMHO.

Anyway, I definitely appreciate the willingness to engage on this issue. It’s a healthy sign that I’m still hopeful will ultimately result in positive final outcome for Meteor and its community.


This is getting a bit too confusing at this point. Soon after last year’s post, I switched to React to start a new project after all of the MDG recommendations that that was the best way forward. I still like Blaze better than React in terms of project building experience, but wanted to go with something that would be supported. At the end of the day, I really don’t care about which one is superior, because I haven’t seen any compelling case that one is that far ahead of the other.

With this post, is Blaze back as the recommended engine? Will it continue to be updated? Did I waste my time learning React?

I really just don’t know where to go at this point. As the year progresses, some view layers will be prioritized naturally by official and community packages. It is really impossible to continue to improve the Meteor platform while being view-layer agnostic. It would be really great to have a bit more of a clear scope as to what the future intentions are.


Yes, from my perspective this is the goal. It just happens that React/Angular2, GraphQL, and NPM are the “most promising technologies” you are referring to, according to the people at MDG, some production users of the platform, and some prominent community members like @arunoda, and in many cases in the wider industry. Consider how many technologies out there we didn’t jump at - gulp, webpack, flux/reflux/redux/rxjs, typescript, riot.js, bower, brunch, and countless others.

From my point of view we were holding the fort on stability until new users and production app developers were starting to leave because we weren’t integrating some key new technologies. I think anyone would agree, NPM is the place today to get JavaScript technology from the source.


Consider how many technologies out there we didn’t jump at - gulp, webpack, flux/reflux/redux/rxjs, typescript, riot.js, bower, brunch, and countless others.

This is true. But remember: Something as important as the view layer can’t be switched by a business on a whim though, so I hope you guys don’t flipflop again. Make a choice, stick with it, and us Meteor devs will be productive as all hell. There is nothing like Meteor out there, we are so empowered to build businesses with Meteor it’s a shame there’s only 24 hours in a day.

I made the jump to React based on your personal recommendation @sashko and my productivity is awesome now, and my code is cleaner for it. Just stick with it! :muscle:


For those that have switched to react or angular- this is ALL noise preventing you from going forward. If you have made the transition and like it, keep going with it. There will be meteor developers, like myself, contributing to the other ecosystems (angular and react). There are bugs in Blaze, which were not addressed in the post. So those that already decided to move towards the other view layers are in good hands.


There are bugs in React and Angular that are not being addressed. But it doesn’t matter, just use whatever you like and what is best to build your app. The only difference now is that people who choose Blaze can stop worrying that it won’t be supported anymore.


This announcement is a big win for people with large projects built in Blaze. I find it surprising, given the push towards NPM and away from Atmosphere.

React or Angular or Blaze are fairly useless without their community contributions. (You could use them, sure, but you’d never get to market quick enough without also complimenting community packages.) React-router, ui-router, and iron-router are classic examples of bread-and-butter contributions in each of these view technologies that begin to make them palatable for rapid development. Here I used routing as the concern, but other analogous view-layer concerns could be used as well (generating/validating forms, etc).

Blaze will always be dwarfed by React or Angular contributions due to limited use cases (e.g., exclusively with Meteor). Blaze does have great community contributions by excellent developers, but it will never fully complete in the greater JavaScript ecosystem. Blaze’s greater strength —full stack components— is arguably its greatest weakness. They tend to be painful to move away from, too. Like when I wanted to move from Blaze to React and I was using autoform. Full-stack components are not fun when you want to migrate off them. Speaking from my own development experiences, they’re kind of a big investment, and I learned that the hard way.


@gschmidt I’m gonna lay out a vision in a medium article for GraphQL and relay (influenced) stuff. There’s a lot you can get from us for free that you are paying employees for.

I would love to somehow engage in your internal conversation. Even other developers (@aadams @dinos) have mentioned they would love for MDG to respond to ideas I’ve put out. That said, this isn’t only about me–I’m just an example. I think in general, there is a lot of noise for sure and @sashko does his best to +1 ideas he supports. But he’s only one guy. You chiming in here is also a move in the right direction. But in general, most of the communication is 1-way communication.

What we need is simply: RESPONSE TO WELL THOUGHT-OUT IDEAS AND PUBLICATIONS BY YOUR COMMUNITY. How come @arunoda basically has to operate as a loan wolf monkey-patching you all the time. I rarely–if ever–see any comments/responses on his articles from MDG employees/partner. And that’s just using one guy as another example. So rather than more one-way communication–where in the past all we got was an occasional blog article–what we need is genuine listening to what we have to say.

There is great ideas coming from us that you’re missing and essentially paying people to find on their own. And with a lot more of us and some of us already passionately dedicated to certain areas (rather than just assigned to it), we may have a thing or two you haven’t thought of.

I don’t think you really listen to us at all. My perception is that you view most of us as a bunch of intermediate developers creating a lot of noise. Fine, but my recommendation is to sift through the noise and find the gems. Some of us might really have some insights about what’s best for the direction of Meteor. It’s a lot faster than waiting months for a few of your guys to research areas that community developers are already hyper aware about. At the very least, make sure as part of their research, they comment on such outside research. It shouldn’t just be limited to forum responses. In fact, the best stuff is likely coming out of Medium articles these days. Responses from core MDG developer precisely in that spot would–in my opinion–do the most to engage the community and flip our perception of MDG on it’s side.

For example, here’s several recent posts of mine you may be able to find such gems in:

I have an idea of how you’re working, and really like it, but I got some tweaks to it. Basically it seems the way you’re working is you’re sending out developers to do thorough foundation-first reports on various emerging technologies, basically as scouts. That’s smart. Your partner @dgreensp whose work I’ve been impressed by ever since he started appearing in Dev Shop videos wrote a great report on Webpack for example. That was extremely informative to me and basically did the trick of bringing me up to speed where most other material out there still left you putting pieces together on your own. So from what I understand you have @sashko and Justin Santa Barbara assigned to, what I’ll sum up as: ***“nextgen subscriptions”***. Right. Again, this is Relay and GraphQL inspired stuff, but with a reactive subscription-based focus like Meteor has always provided through LiveQuery. It’s my opinion that this is the absolute biggest area of evolution in the Javascript community right now. Your guys, me, etc aren’t the only ones doing lots of exploration in this area, but I’ll get back to that in just a second. …Basically, my recommendation is that you start Hackpads or similar from the start of these explorations, not after they are done; announce that you are starting them, and engage us from the beginning.

It’s always scary to address your constituents before you, yourself, have a voice. I get that. I’m not saying that @sashko shouldn’t do any preliminary research of his own. But basically do what you did with the Proposal for Blaze 2 Hackpad–just instead, actually apply what everyone came up with. That Hackpad really does seem to have been a success–the cream of the best ideas rose to the top. If Blaze 2 ended up being built, and the result was something that got a lot out of that Hackpad, it would have been a big win towards the aim of stronger community coordination.

I think currently with the Relay + GraphQL inspired stuff we have the best example of a “hackpad” sort of situation we can start now. And we should open up such a Hackpad. I’ll leave that up to you.

I’ll kick it off with my findings:

It’s my personal opinion that ClojureScript’s Om Next has absolutely nailed this (far and beyond what Relay currently supports) and you should use that as the basis for what Meteor is doing. In addition, unlike Relay and GraphQL, it isn’t just a specification/protocol. It’s concrete all the way down!

Here’s what is great about Om Next:

  • it combines what Redux and Relay offers into one
  • it allows you to configure multiple state atom’s as data sources (e.g. a client one for “UI state” [Redux] and a server one for “domain state” [GraphQL])
  • it has subscriptions out the box! Minus RethinkDB, which is just the DB portion, no open source product (reads: Firebase is excluded) ever really offered full stack subscriptions–none that picked up steam at least (reads: Derby?? what is that?).
  • it has full stack time traveling (not just client side time traveling like Redux)! This is thanks to the Datomic database, which keeps a record of every mutation ever mad, and which would be a challenge to replicate otherwise, but is definitely doable via snapshotting and the oplog for small development databases.
  • it simplifies the boilerplate needed to get the Relay-inspired stuff up and running. To be sure, it’s a major benefit that they aren’t trying to support multiple databases like GraphQL, but even then, it simplifies a lot that Relay requires you to do.
  • it uses Datomic, which has built-in support for subscriptions (for the most part) and is the closest thing to the database described in the famous Turning the Database Inside Out video. Om Next is “observables all the way down” now!

I think we should achieve that but using GraphQL and Relay so that you can take advantage of their ecosystems. From application developers’ perspectives, they would be dealing with a wrapper of GraphQL on the server and a wrapper of Relay on the container. But underneath MDG uses raw GraphQL and Relay to take advantage of efficiencies it provides. Specifically, on the server (GraphQL) it will allow you to use Rising Stack’s Mongoose and Graffiti and add additional DBs more easily and on the client I’m sure something will emerge that makes it a good decision to use Relay. But just to re-iterate, what application developers use is a condensed simplified opinionated version of such. I.e. a way smaller surface area. If you don’t provide such abstractions, there would be no value-add provided by Meteor, which would be a bad thing; there would be no reason to not just use NPM + raw React+Relay+GraphQL. So there needs to be a value add provided by Meteor in the form of a simplified abstraction. And, luckily, this isn’t just a solution to a problem that doesn’t exist, but is actually a problem needing solving–if we thought React required more boilerplate, Relay and GraphQL requires 2-3 orders of magnitude more boilerplate!

Here’s an example of how Om Next simplifies the Relay-inspired stuff (notice primarily the query function):

(defui Person
  static om/Ident
  (ident [this {:keys [name]}]
    [:person/by-name name])
  static om/IQuery
  (query [this]
    '[:name :points :age])
  (render [this]
    ;; ... bla bla ...

This is a complex topic and requires deep knowledge of GraphQL, Relay, React, Redux and what’s going on in our functional programming counterparts: Elm, Cycle, ClojureScript (Om Next and Re-Frame), etc. I think this will be a major win for us all to talk this one out together. I think we should all share our findings via various Medium articles and respond to each other there as well. I think this is the perfect opportunity for MDG to come out of its shell. And generally the perfect time for Meteor to come out of its shell.

My Final thought is: as the greater Javascript/NPM ecosystem acquires what Meteor has exclusively offered for years, we need to come up with new opinions. Meteor was opinionated in an area that is now more generally abstracted (or at least in the midst of completing its final stages of which). Meteor’s success relies on it being opinionated. Unfortunately (or fortunately, depending on how you look at it), we need a whole new round of opinions to offer a value proposition worth betting on instead of using “bare metal” NPM. It made sense that only MDG contributed to such opinions the first time around (since the community didn’t exist). Therefore, it’s the perfect time for not just MDG but the whole community to contribute to them. A hackpad would be the perfect place for us all to form them.



Not true. Blaze is built upon web themeing technology. Even if Blaze itself is a separate code set, the approach of direct replacement into HTML themes has been standard with websites way long before React saw the light of day. There are many themeing engines that use this approach. People are excited with React as it is made by Facebook. When that abates, it will be a framework like any other.

One of the challenges on this forum is that you have both fresh developers and veterans.

1 Like

As I found out from the Blaze 2 hackpad, it’s not always the best ideas that rise to the top. If you’re not careful, you just hear from people who post the most comments and speak the loudest.

How can we design metrics for how we can get input from the right people and seek those people out, vs. just going by what happens to be posted the most on a specific document or forum?


I disagree (to a degree). What we are looking at is an increased signal to noise ratio vs the 500 post thread case in point (among, at this point, many related threads). Sure, you gotta do some weeding out of the best ideas still, but we have increased “signal” by a vast degree. I surely was able to spot what I deemed to be the best ideas all living in the Blaze 2 Proposal Hackpad. It wasn’t like some discoveries weren’t made there. We just need to find a way to reduce the noise even more.

In short, I agree that a “republic” can be better than a full “democracy” at this point. An algorithmically-controlled Republic, if you will, is what we need.

There have been several platforms over the years that are strategically designed from the bottom up to rise the ideas with the most votes to the top as well as contributors with the most support to the top. We should simply find the best such platform of today and use it. Whatever that is, is likely the best we can do unless we wanna build it ourselves.

On a side note: i’m not opposed to building such things ourselves–I personally think it’s bad for marketing that we are using–as I recall–an Ember-based forum that totes realtime as soon as you first signup, but isn’t built with Meteor! Something is very wrong if our forum is all about realtime features–Meteor’s core value proposition–yet isnt built with Meteor. It’s things like this which we gotta correct about our culture. Believe me, I get it’s hard to do everything in software, but this could be the perfect opportunity to correct that along with making community contribution a first class priority. This might be the rare case where building our own custom solution is the perfect opportunity. I think MDG should have some internally-built applications that many of its developers are familiar with. If built with the community, would be a great exercise to say the least. Are there any “consumer applications” that MDG has built that we use? U know, like a blogging platform, forum platform, social network, etc. One criticism that I’ve heard in relation to this before is: MDG doesn’t have much actual experience building apps. If we do this right, we can correct that while hitting many other birds with the same stone.

Back to the main point of finding a system that most effectively rises the cream to the top…I don’t see this as an unsolveable problem. I’m glad you’re asking this question. It seems that this is the first time this is genuinely being asked (since you wouldn’t be asking a question that has ready-made answers for had it been previously deeply thought through). Rather, it’s finally being asked! So let’s just find that platform, and use it. Ben Kaufman, founder of Quirky (a crowd-sourced platform for physical products) started out with a product called Kluster like 5-7 years ago for crowd sourcing ideas more generally within companies. Off the top of my head, nothing new is coming to me, but there has to be like 100 such similar offerings now.


I believe you (MDG) should be able to handpick 5-10 smartest people from the community - I guess we all know more or less who they are - and prioritize their comments/opinions above others. Maybe even invite those to a more or less closed conversation (but readable by all) if hackpad or whatever forum does not support such prioritizing.

Not saying that you should not listen to others, but as you say, there probably will be vast amounts of noise and it will be time consuming to filter it out.


So from what I got…

On one hand we have MDG
who will put their effort into Galaxy in order to make some cash and when they have time for their open source projects they might make some update to meteor meanwhile the official view layer will be Blaze which they sell as a good solution for beginners and legacy packages that are hanging on Atmosphere.

On another hand we have KADIRA (mantra)
Embracing React and offering smart solution to keep building applications on top of Meteor making use of NPM and js. trends, but not only we get a React but we also get to choose which database to use… and wait they also maintain the new official router flow-router along many packages that contributed to make what meteor became.

What sadden me the most is that even thought KADIRA as a company has it’s own reason of developing Meteor, it’s sad to see they do deliver what MDG fails to deliver…

I would even say that MDG need a new leader for 2016 and that an active guy like @arunoda might be our guy.
If not… I don’t get why KADIRA doesn’t just fork Meteor because if they don’t… in the end… I don’t think KADIRA will get the a piece of the cake they deserve :wink:

Seeing how poorly the view layer issue has been addressed i’m starting to feel more confused and think that Meteor future is dark… because view layer was only one issue out of many…,

If there is nobody to make smart decision and not changing every month then I am worried about the future…
We won’t need to worry about changing the view layer again… but more like changing framework :wink:

One solution could be to get the good MDG members into KADIRA and let’s make Meteor reborn again …

I love Meteor and what you guys made but seems like time has come to change a few things ,

Happy new year ~
ps: @faceyspacey, @mordrax, I feel you guys ~

1 Like

Does this mean we’ll see some React components written for user accounts just as we have for Blaze? Is this something MDG will work on or is the community expected to do it? What about stuff like redux, flux, relay and graphql?