Is it time to leave Meteor & MDG?

Planet Earth
4

Hey @almog,

Like many of us, I pondered this. And here is what I came up with.

  1. MDG makes money offering a hosting solution (Galaxy). My own math tells me it is not profitable enough for a solid return on investment for their investors. But, still making money.
  2. There is definitely a lack of communication skills – top of MDG seem much more skilled at development then communication and vision. You alluded to their mishandlings of messages and lack of proper outreach to the community (however, @sashko is simply amazing, and should be credited for keeping much of this alive despite these mishandlings).
  3. Meteor is shifting towards the general JS community. They are not just NOT developing Blaze, they are not developing UI period. React and Angular are not from MDG and much of what is out there is community-supported.
  4. MDG is rightly going towards community-supported development. Watch what is happening on Github right now, the transfer of Blaze (and soon more pieces) will take place.

I am now convinced Meteor continues to be a great platform, and will continue to do so. I have a feeling development is proceeding towards being part of the global JS ecosystem, which reduces all our risk.

Personally, I am struggling with the moral dilemma that we are not using Galaxy yet. For technical reasons, we can’t. I would love to give back to MDG by using their platform.

They did a great job!

Edit: We are using Blaze and will continue to do so in the near future. We are not trend chasers and see tremendous value in handlebars.

30 Likes
5

@ramez you’re not worried that the Meteor framework is a taking a second step after Apollo and it seems MDG is more focused on Apollo then Meteor.

Blaze is just a small part and not a big deal at the end there are other options. But what happens in Meteor is ditched towards Apollo?

6

I am not worried about Meteor for the following reasons. But I first need to say that this is the result of soul-searching not unlike what you are going through.

  1. First, the money trail for MDG is, so far, Meteor. This is done via Galaxy hosting. I haven’t yet figured out how you can make money on a middle layer like Apollo by itself. Maybe Apollo servers, if that is possible. More likely than not, the future is to make Meteor a complete platform for GraphQL via Apollo.
  2. GraphQL servers are now popping up everywhere, you can’t make money on GraphQL alone (at least that’s what I believe). It needs to be part of something bigger – see #1. In fact, FB already released their GraphQL client (maybe they’ll even release their server!)
  3. The community is now stepping in and slowly taking over pieces. The code is after all, open-source
  4. Development on Meteor is on-going, and recently moved towards merging the two (Meteor 1.5)

Finally

(5) I believe we are in this mess because of miscommunication.

2 Likes
7

Guys, haven’t we had this discussion a hundred times already by now?

Technology gets deprecated everyday in the JS world. At least with Meteor you get a somewhat reasonable lifecycle.

If you need to build a new app the question is: "What framework can help me the most in building what I want."
3 options:

  1. As of today it would be Meteor, just like it would have been 2 years ago. -> Use Meteor.
  2. 2 years ago it would be Meteor, but today not anymore. This is probably because of newer stuff in the larger JS community and that’s where Meteor tries to change to make itself relevant again for those users.
  3. Today it’s not Meteor and 2 years ago it wouldn’t have been Meteor. -> Use the other framework.

“Will Meteor still be here in another 2 years” is not a very useful question, since in the JS world there’s not really any other framework that gives you this guarantee. Maybe it’s a useful question if you’re comparing cross-technology ( with .Net, Ruby, …).

The only thing I hope is that MDG doesn’t forget about the people who choose Meteor for its reactivity. Some apps need “instant” reactivity across users and that’s not a high priority for Apollo. So I hope livequery keeps getting some love until there’s a viable alternative in Apollo.

18 Likes
8

Although such questions are rightfully warranted - you are investing in it after all - the answers, I believe, are simply in favor of Meteor and MDG’s vision.

Evolution and innovtion are inevitable and in a such high velocity realm like software development, it should even be considered absolutely necessary.

MDG does one better and goes to great lengths to be backwards compatible, while proposing carefully crafted upgrade/migration paths. Had it not been the case, most Meteor apps from 6 months ago would be breaking today. But I do find that my apps from 3-4 years ago still run just fine, albeit not exactly easily updatable due to third party dependencies lacking support. But I’ve had good mileage with all of them, in fact last week, while needing to demo a very old app, realizing it had been pre 1.0 and needed upgrade, it took me about 10 minutes to upgrade to 1.3.5, granted it was a rather small app with very minimal 3rd party dependencies.

Regarding deprecations of technologies, well that’s eventually going to happen. Mind you they still do support them, and they even agree to hand over governance to the community for those would be deprecated parts. But you should also understand that if they are deprecating something and advising the community to move on to some X stack, you probably should listen. I used to be a vocal member of the “we want blaze” camp until I decided to take an actual, willing and positive look at their suggestion, React and now it is my go to ui stack and I’m actually trying to see if it would be worth converting old Blaze apps to tap into what React has to offer for the future!

And it is all the same with GraphQL. I keep finding myself trying to tame reactivity, tearing down subscriptions to convert them to method calls or trying to mark them as non reactive, only to see that where I’m trying to architecturally head towards, MDG is already there with Apollo! There is a reason some very smart people decided to bet 20 million dollars on them some years ago when they did not even have any monetization strategy whatsoever! They’re even on the innovators quadrant of a Gartner report. For those who are not familiar with what Gartner is and what it means to be on one of their reports, let alone the magic quadrant, that’s h-u-g-e!

Anyhow, regarding their vision, I think they are spot on with their strategy on separating their core offering into

  • Data (Apollo)
  • Build Tool (Meteor)

Now, Apollo is arguably the most innovative GraphQL solution out there.

And I don’t know you guys, but if I wanted to develop a JavaScript app, build it for web, iOS, and Android, and possibly Electron and while at it for other targets such as a Chrome Extension, I know I can quite easily achive my build tool setup within a few hours on Meteor and a few packages.

On the other hand, trying to achieve the same using a host of build tools, getting them to play nice with each other, configuring endless files, digging up gotchas in documents and github issues would probably take at least a week or even more, for what, to be able to say “Hello World”.

I don’t know what MDG’s plans and intentions are in monetizing their innovations, but they are smart people and their investors must as well be as smart, given their track record on other investments they’ve made. If those investors have cast their vote of confidence on MDG, why should you care if Galaxy makes money or MDG may or may not be able to profit? How much revenue did Instagram generate before getting acquired for a sizeable $1B? 0! Z E R O that is, 0!

I think what we can do to pay back is to actually enjoy what we have and stop second guessing this every other day. Yes they do have notoriously bad communication skills, but hey, I’d rather have them giving me the next feature then explaining me why and why not!

So there you go, I believe you should grab tight on MDG’s vision, probably even be an early adopter as much as you can, and sleep sound knowing you’re in good company!

Oh and, where else did you ever see such a vibrant, selfless, helpful community? The worst case scenario, you will have made a lot of very smart friends here on the forums and should MDG ever tank - god forbid - you’ll have them caringly embrace and guide you towards a solution :wink:

43 Likes
9

As we’ve communicated over the past 6+ months, we’re investing heavily in Apollo to make Meteor better so it attracts a much larger community of professional developers to ensure it’s longevity. At the same time, we’re aligning Meteor (and Apollo) to the modern professional developer ecosystem vs. continuing to make it a closed, esoteric stack that may be easier-to-use for some but only for small slice of the app dev world. The world of developer tools and platforms has evolved since the early days of Meteor and MDG’s decisions in R&D and commercial efforts reflect where we think the future is heading. A cornerstone of the strategy of expanding to a larger market of professional developers also includes new commercial products and paid services which we’ve already begun delivering for GraphQL via Apollo while continuing work on Meteor & Galaxy too.

I recommend watching the various roadmap and strategy talks we’ve shared in recent months; we’ve been very transparent in our intentions and have generally delivered on what we’ve committed to (with a lot of help from the community!) and we’ve got a lot more coming this year!

“Meteor 1.4 and Beyond” - Matt DeBergalis

“Product Roadmap and Strategy” - Matt DeBergalis

“The Future of MDG” - Geoff Schmidt

30 Likes
11

This is great thanks.

I would ask the following question; MDG is focusing on Apollo as you said to attract more developers (“attracts a much larger community of professional developers”), basically scale. MDG needs bigger scale both for growth, marketing and as a company. And please don’t make this just about the community or “ensure it’s longevity” maybe to MDG longevity at the end of the day MDG has raised a lot of money and needs to show growth. Basically what Ruby on Rails or Java has done.

This makes sense and is great but can we expect the meteor framework to have the same amount of effort as Apollo? is MDG committed in keeping meteor alive? Yes there is the roadmap but we can we get an official statement that is very clear and straightforward.

When you think about Apollo it makes sense to use it with other stacks for example Node.JS and Apollo if that is the case why would we need meteor and wouldn’t MDG look at meteor the same was as it did with Blaze. IE we offer Apollo which is the core and then developers will choose their stack which has wider community support like Node.JS or RUby and for client React or Angular. How does meteor fit in this?

1 Like
12

I’m not sure what you mean by “can we get official statement that is very clear and straightforward”; between what we’ve communicated about our product strategy via official videos I’ve shared and actual open source work on the Meteor and Apollo projects, what specifically do you think is missing?

Our investment in Apollo helps accomplish two goals: make Meteor more usable by more developers + make Apollo/GraphQL a key part of all modern apps. The two open source projects intersect and our experience with building the data system for Meteor now informs Apollo R&D. Right now, building Apollo is the single best way for MDG to invest in Meteor. While Apollo enables better support for non-Mongo data sources for Meteor apps (1.5 release), Apollo is also usable in non-Meteor apps as well (e.g. Node, Ruby) - it would be foolish to only enable GraphQL support for Meteor. But don’t attempt to create controversy by oversimplifying the tradeoffs; they aren’t zero sum. If we weren’t investing in Meteor, why would we bother putting Apollo/GraphQL in the 1.5 release? Remember, we also have a set of commercial products and services for that depend on Meteor and Apollo adoption which gives us the ability to continue investing in both.

17 Likes
13

I think the absolute worst case scenario is they hand meteor over just like they (presumably will) hand blaze over.

I think that something like the below could be useful for blaze if not meteor. If people really are dependent on Blaze/Meteor, they should be okay with donating $10 a month to something like this… and maybe more “corporate” sponsors would donate more. It wouldn’t take much to provide the funding needed to keep Blaze/Meteor running:

https://opencollective.com/

Incentivizing Open Source Authors:

14

Hi,
First appreciate you and everyone else taking the time to clarify everything, the idea was to get real feedback as I do care for the platform but also have clients and decisions around the future on were things are heading. The best way to make clear, informed and a good decision is to ask hard and honest questions.

Saying that no one is trying to “create controversy” if you can’t take the hard and direct questions then maybe someone else should answer them. Also let’s be honest MDG did a bad (thats the nice version) with Blaze I can send you 2 / 3 threads were the entire community was pissed off about this not to mention MDG backtracking. So you can me and the community the benefit of the doubt.

To make things very simple and direct.
Apollo is great and we allow meteor applications to connect to different data sources like SQL and it will also let none meteor frameworks like Ruby, Node ect… enjoy real time this is amazing and I look forward to it.

The question is very simple if I can use Node + Apollo + React and it does what meteor does why should I use meteor? Will meteor last? Is MDG committed to provide vaule within meteor that is better then Node or Ruby. At the end the only thing that is really MDG is Apollo.

Also what I have seen MDG talks about meteor becoming a toolkit is that a full developer framework or the command line tools to deploy and host your application? Maybe I missed but that’s why I’m asking.

Finally yes do more were developers and it’s a community so you can always do more and be better. I don’t maybe hire a community manager

15

I guess part of the question is “For existing Meteor users who have chosen Mongo because of Meteor, are obviously not on rails/raw node and are very happy with the mongo syntax, why should they be happy to see MDG using part of its bandwidth focussing on Apollo/graphQL?”

This is like “For people very happy with Blaze, why should they want Meteor to spend time on other framework/focus less on improving what is already working for them” Maybe they have no reason to. Or you’ll have to convince them that having a larger community involved in a smaller set of common features is actually going to bring them some benefits, or that you’re making some changes that are better for their future. This is not obvious for all current Meteor users about Apollo.

It probably makes a lot of sense for Meteor as a company to look for scale (and $), but it’s not obvious for its users that this the first thing they need. We’d all like to be convinced that “building Apollo is the single best way for MDG to invest in Meteor”, but from my point of view with my Meteor product working fine, I’m not looking forward to a change in stack. I’m looking forward to having my stack work better.

2 Likes
16

As a consultant, you should always use the best technologies possible to deliver solutions to your clients. Period. It’d be fairly arrogant for us as an open source vendor to believe that only Meteor should be used for web and mobile development. As Meteor aligns with the larger JavaScript ecosystem and also supports GraphQL-based integrations/data sources, you’ll have more flexibility than ever to bring state-of-the-art tooling to your customers’ apps.

Will Meteor last? That isn’t a question that MDG can solely answer; it’s something that you and the Meteor community answers with your valuable time: time spent on contributions, time spent on content creation, time spent on professional app dev using Meteor. And I’m not sure what you mean when you ask “Is MDG committed to provide vaule within meteor that is better then Node or Ruby?” I also don’t understand “what I have seen MDG talks about meteor becoming a toolkit is that a full developer framework or the command line tools to deploy and host your application?”

2 Likes
17

Maybe it just me but it feels you’re avoiding the question by just saying “I don’t understand”

2 Likes
18

Can you please re-phrase the question(s) you want answered? Your words/grammar aren’t totally clear to me.

19

Will do once I get some sleep been up for like 48 hours, would you prefer email? Don’t want to keep going back and forth and create negative issues / comments

20

I think you’ve answered your own question: because MDG is a VC-backed startup vs. a non-profit foundation like Apache, we can’t exist only to serve our current set of open source users. As a result, our company sometimes (but not always) prioritizes decisions through the lens of delivering open source technologies that are useful to larger future populations of developers vs. a smaller current set. This is because some percentage of developer adoption eventually needs to yield revenue through commercial products/services if MDG is to stay in business. I understand that MDG’s strategic goals of growth may not easily translate into clear features that some of our open source users really want; but our community should understand that the more growth MDG achieves (both open source adoption and commercial revenue), the more likely MDG can continue to fund projects like Meteor with engineers, community programs, and infrastructure. We know (and really appreciate) that developers like you vote with your time through contributions and Meteor apps built; sometimes with your money if you use Galaxy hosting. So it requires constant prioritization for us at MDG to continue to earn your time/contributions/money through releases that are both immediately useful and/or also continue to grow the size of Meteor community.

14 Likes
21

No, we should keep discussing here as it’s important for the overall community to hear the discussion surrounding the controversial question you raised: “Is it time to leave Meteor & MDG?”

9 Likes
22

I think the fact that MDG is pivoting shows that they won’t die. If they continued on with Blaze and Pub/Sub subscriptions they would have made a great system for beginners and small apps… not medium businesses and enterprises

IMHO the best value add from MDG is to create a great abstraction over things.


  • If you compare Apollo server vs GraphQL.js, Apollo is far easier and more convenient to use.

  • Authentication can be hard and tricky to implement securely. MDG has made a great abstraction over that to provide a fairly seamless experience across quite a few authentication schemes. This also includes a password reset setup which emails out a reset link as well as binds a route to handle it.

  • Sending emails has been very easy. Their email package has worked out rather nicely

  • Fibers on the server has made my life easier for years. Today async await is just finally becoming an alternative, though it’s still not quite as nice as fibers.

  • Sending proper JSON responses takes some time and simple-rest provides a really really nice API to create JSON endpoints in a few lines of code (though not directly from MDG).

  • Deploys in vanilla Node are still non trivial. If you pay it you can meteor deploy in a few seconds and be up an running with no hassle. Their rates are comparable to other providers with similar services/conveniences. This is a huge win.


Historically there were some other great abstractions that… well… didn’t really work great. They work good but not exceptional for a lot of use cases.

I think in time we’ll see more abstractions over things like Redux and others to hide away the boilerplate (like Apollo does for GraphQL). I was hoping MDG would release an abstraction like create-react-app first but I understand the importance of backwards compatibility with tooling. I would expect them to have something similar in time (they know the build tool currently is not ideal).

IMHO Blaze was a great idea that didn’t really scale well (codebase wise) with global everything. Once you try to cover the last 20% the Blaze gets very complex and convoluted. Very few teams with large apps with multiple team members are glowingly happy. It becomes a game of whack-a-mole and don’t touch that piece or the whole app may break.

Publish/Subscribe works fairly well with simple resources and simple templates but once you layer on 10 more packages that start abusing the subscriptions it quickly becomes an issue with a decent load of concurrent users. Typically it just costs a lot more monthly, most of us don’t hit a bottleneck where horizontal scaling doesn’t work. I’ve worked on a lot of apps to speed up slow data responses. Cutting out pub/sub usually yields an order of magnitude or more of speed… just by cutting them out and switching to Meteor methods… which are almost 1:1 to a GraphQL mutation.



What’s nice is that if Blaze and Pub/Sub work for a project, we can still use it :slight_smile: I honestly think a community fork that is geared towards prototyping and beginners would be amazing. We could simplify Blaze to be as simple as it was in 2012, make more things automagic like autopublish since these apps (on this fork) are not geared towards heavy prod use.

31 Likes
23

I hope you don’t take offence, but i think your post and its title are downright counterproductive. Leave… what?

Pick anything that makes your job easier. Meteor and React today, jQuery, AJAX and REST tomorrow, Seneca and AMPQ the day after tomorrow. Next week come back and build something with Meteor and Blaze because, well, your next week’s job pertains to it. Or, to an extent, mash them all together to build services with different capabilities in your next distributed app. That’s how it works.

This is not a marriage, with MDG having signed a pre-nuptial contract with each one of us. You like what you get, you use it. No one leaves anything, unless the plan is to learn and know the one and only framework of a lifetime.

It is the way you write and structure your code and its components (modules, packages, services) that will make it future proof, not a particular framework being frozen.

Meteor is one of the smartest, if not THE smartest, paradigm to have surfaced from the huge and stormy JS world. Even at the most basic level, like HTTP calls, or Mongo queries, try a little bit anything that’s on npmjs.com and then you’ll se how quickly it gets hairy.

Apologies for the long rant, and again, I’m hoping that you don’t take offence. I think it is time that we, as a community, stop whining.

Rest assured, good code never dies.

22 Likes
24

OK my question would be what value does new meteor with Apollo bring over other nodejs stacks and frameworks? What is its wow factor? What is its uniqueness? You want more javascript developers - how are you going to “sell” them? (also you will need to sell again to your loyal customers after big changes) Why don’t they just use react, relay etc? How are you going to monetize it when there is such a strong competition of other free tools? If you can’t monetize even if meteor stack is better people might choose something else simply because of for example that it’s guaranteed that facebook will continue to support its tools without going out of business.
I think you are handling transition very well and I don’t really know if this pivot is a good or a bad thing but those are the questions I have about it. I believe “old” meteor could had all those answers and that’s why it got traction.

1 Like