Have you heard of Flash, Flex, CakePHP, I can think of 10 more.
It’s not about choosing the right tech but really understanding the vaule of Meteor + React over Node + React + Apollo
Another example is the mean stack which takes a bunch of components to do the same thing that meteor does.
Again it’s not about what’s better but really understanding the vaule of Meteor + React over Node + React + Apollo
Especially if you need to use Apollo anyways to connect to a different DB for example will my stack now be meteor + Apollo + react?
From a developer perspective and a personal business perspective I’m completely for the move to npm, focus on Apollo stack and several changing moves. To me, blaze was a simple stepping stone to pick up meteor when I first discovered it. Personally I run React now, but both at the same time could have been hard.
Only thing I’m a bit annoyed with sometimes is that every new version feels like Python 2.7 vs 3.x.
It kinda works, but it kinda doesn’t. Always a breaking change. I’d rather stay on a solid version for a while(Although I really needed 1.3 because reasons!!). But I think I’ll skip 1.4 until 1.5 is stable. But please, do convince me otherwise someone!
I like the fact that you’re slicing things up and modularizing the entire framework. Making each bit less dependant on the others. However, I don’t see it from your perspective. I’m loving it, but you’re doing the complete opposite of a lot of other software tools/framework companies. You’re making it easier to leave you by not locking in. Which is a fresh, but unexpected tactic. I’m just wondering why? To focus more on core things and have a smaller codebase to maintain? Was your main goal Apollo all this time and not really meteor? Is meteor simply an unusual stepping stone to running a large hosting company? I can see the move for getting new devs, as it’s becoming easier to convert an app to meteor. But I really don’t see the long game retention!
Since when has Flash been “good code”? 
A more security flawed framework has probably never existed in the history of computing. Besides maybe the PDF format…
The value of Meteor over vanilla Node Is simple. You don’t need to configure webpack or gulp or grunt. You get reactivity with Tracker or DPP. Later Apollo will also be included. All the build, packaging and deployment is handled by Meteor.
Now if you can do the above without Meteor than good for you. Go with plain vanilla JS.
The only thing really annoying about Meteor, is that using Meteor is still a take or leave decision because it’s not on npm without a path of incremental adoption.
Meteor is too big, too slow and too hard to integrate in existing workflows. If it stays like that much longer, we have a problem.
The long stated goal of bringing meteor to npm was recently delayed again to make meteor even larger by integrating the young Apollo project. Though I love Apollo, I think stated roadmap priorities got pretty screwed by now…
Let’s define Meteor ?
Is it the technology stack Blaze + Tracker + minimongo + pub/sub + mongo ? We all now ALL those technologies are gonna be deprecated in the not so far future.
Or is it just a build tool, designed to drive users toward MDG proprietary solutions ?
I have nothing against better/newer techs, but i don’t want to rewrite all my code every year because MDG is chasing the next tech which they think will bring them more (with deeper pockets) users.
Really? As far as I know, all software they make is open source.
You are not forced to update anything. You can just keep using the old stack if that’s what you want. I hear you think; yes, but security updates. Well… it’s open source, you can apply them yourself. Trust the community to do this, or pay someone so they can do this for you.
I don’t understand where all this hate is coming from. We have a wonderful stack called Meteor, and they make it for free. Or at least; I’ve never been charged for anything I use.
Thanks for being clear on that. I think there’s should be more openness on what being a VC-backed company changes because it would make some conversations easier with having everyone on the same page.
More precisely, can you share how this change things for feature prioritization ? I think earlier in this thread @dinos gave the example of how the move to npm has been delayed by Apollo which sounds like a good case where company growth has been prioritized over current userbase need (some might disagree 
)
And also, what are the risk that someday Meteor gots acquired/close shops because this is what happens to a bunch of VC-backed businesses? Would we be left with an open source code that is not actively maintained? Do you have legal company constraints again that happening?
Don’t get me wrong, I’m all in favor VC backed stuff. And I think developers who make important long term choice with Meteor would be happy to have more clarity on that front, and just want to reassured there’s no reason to leave Meteor/be suspicious of where the project is going.
Overheard recently at a MongoDB sales conference:
Larry: Brad, I think only crazy people using databases other than Mongo would agree with MDG putting priority on Apollo integration over the move to npm.
Brad: I hear you Larry; that tiny minority of crazy non-Mongo people really, really annoys me. Oh well, another Mai Tai?
Larry + Brad: High-fives.
Galaxy is open source ?
Apollo optics is open source ?
You are joking, right ?
“hate” is a little bit strong.
Distrust would be more appropriate, in my case.
For how long ?
@greblak, we programmed with Flash AS3 for a very long time and it was “great code”. You are probably judging from the days where people mixed AS2 and animations in the same file.
In fact, we had imports and classes long before JS did.
No, those services not. But you aren’t forced in any way to use them. See it as Cononical or Redhat, they make an open source product, but provide extra services so they can make a living to.
No I’m not. We don’t pay for Meteor as the platform. I’m not talking about services like Galaxy. Somehow people expect life time support but are not willing to pay for it.
So what part of “designed to drive users toward MDG proprietary solutions” don’t you agree with ?
Where have i talked about my willingness to pay or not pay for it ?
I regret that the framework i came for and which i liked will probably be abandonned in the future to be replaced by something else. MDG owe me nothing. But now contrary of what you said, i have to rewrite my whole app to something else, if i don’t want it be stuck with an abandoned framework. And it won’t be a tech depending on MDG.
The example you and @dinos raise is a good one and can be simply explained by the fact that we are a small company and not immune to resource tradeoffs/prioritizations that occur in any organization that builds software. Sometimes the decisions we make aren’t universally popular or even immediately useful as we don’t solely exist to build open source features for current Meteor users. Deciphering the constantly evolving world of software (esp JavaScript) alongside a multitude of other datapoints is what goes into our decisions; we read the market and build products so that we can continue to grow as a company and expand the Meteor community. Prioritizing Apollo directly addresses arguably the single biggest objection to Meteor today - the lack of SQL support. We’ve heard this objection daily for years from both current users who can only use Meteor for prototyping (but never production) and from users/companies who reject Meteor outright. It’s not surprising that the current community may not care or get value from Apollo if you’re able to use Mongo exclusively. But in order to really grow the size of the Meteor community, we as MDG need to address objections to Meteor to continually attract new developers that currently aren’t in this Forum. In the long run, the more developers that we can attract will make the open source project stronger; this also happens to align with our long-term company growth goals too (e.g. commercial revenue). I’d argue that because we’re a VC-backed company, our decisionmaking will be always be easier to predict as we’ll almost always behave in a way that aligns to future growth (open source adoption + commercial success). If these goals and outcomes make you suspicious, you have a number of options as others like @illustreets and @suhaila have listed. Again, reaction/adoption by current Meteor users is just one of many important datapoints that we consider when making decisions about where to allocate our limited engineering resources.
re: risk of MDG begin acquired or shutting down, yes it’s always a possibility in the world of startups - open source or not. Like all open source projects, there’s rarely any “legal” guarantee of continued maintenance other than the project still being available (and probably worked on) in the community regardless of the state of MDG the company. Even if there were commercial agreements in place (e.g. long-term open source support contracts), the continuation of those services are usually determined by the acquiring company.
I wish we had the magical foresight that you imply!
When MDG was founded, we never could have predicted the direction and rate of evolution in the software market and especially the JavaScript community. I’m glad you appreciate some of our decisions to modularize the framework as it reflects both a pragmatic view of where we think app dev is going plus a lot of work (esp by @benjamn) on our end to allow current developers to opt-in gradually. But I can assure you that although the MDG team has a lot of experience building distributed data systems, Apollo & GraphQL were not part of the MDG strategy in 2012. Like many of you on this Forum, we too are a small company; we make decisions with limited resources/information and try to quickly improve/iterate along the way.
I don’t feel nearly as worked up as some people about this topic if only because everything MDG has done has been pretty well done. Looking back @vjau comment particularly struck me though:
I would re-arrange and add to that to make it:
Blaze + Tracker/ReactiveVar-Dict + Minimongo + Pub/Sub/MergeBox + Methods + UserAccounts + Fibers + Mongo + MeteorBuildTool
I do think the core reason for some of the arm flailing is that people intuit that if MDG themselves were going to build a future-proof app much of this would not be used. Taking them 1 by 1:
I’m sure much of the MDG opinion on the future of these technologies has been said in talks, in forum posts, in chat logs, etc… but its hard to keep up and keep track of all of that. This is where I think at least of the frustration comes from. I for one would love to see a longer blog post from MDG that discusses the parts of Meteor and their outlook looking into the future.
@funkyeah yes! we will absolutely provide an updated future outlook in the context of the 1.5 release (and beyond) in the form of a detailed blog post and forum communications.
The presence of classes does not make it a good framework. Which it is. AS is a language. Flash is a framework.
Flash has a ton of security issues. It might have been good to develop IN, but that doesn’t make it good from an overall perspective. It just helps a little. Also. Java really isn’t the benchmark for OOP stuff if you wanna go down that route Single inheritance doesn’t count as proper OOP in my book.
Hello everyone,
While the title and question “Is it time to leave Meteor & MDG” is very strong I believe it’s an important community question with a goal for good. So please don’t make this into something very negative. Or a pitty fight (already starting to see this with the Flash aguagument).
So far the opinions have been great and both good and bad. I am personally really glad either way. Also Meteor / MDG have answered a lot of questions and have cleared some things up which is great.
If we can’t have an open discussions then what’s the point and I believe there is no such things as a bad or stupid question.
After reading everything my take away is pretty simple, first I have a development studio I believe in choosing the right tech for the job, that is pretty clear on my site. My last project was a native Android app in Java but at the sametime I have been pushing Meteor very heavily at the end most of my projects or the core are meteor projects which I believe in. I also have some apps hosted on Galaxy (2) and some are not.
I’m excited about Apollo as this opens up more opportunities, yes I have had clients want SQL so this is great. Regrading Blaze some of my apps will still use it but I have already moved onto React.
Finally I will be using Meteor but as time moves on I’m going to look to move more towards “native” options for example vanilla Node.JS with Apollo and React and then just host my stuff on AWS. I believe one its an easier sell. Especially since I’m moving more towards enterprise and away from startups.
But at the end just diversify my studio and experience and over time push the meteor framework less.
Hopefully meteor will be great and provide so much vaule as a developer framework that I will keep using but either way not taken chances and will have the best options in my hand.
Almog