It always comes down profit margins. MDG is a corporation with VC backers that want a ROI. MDG couldn’t figure out a way to make the ROI attractive enough to their VCs with the Meteor classic strategy.
Enter Apollo and the new business strategy around it. Part of the new Apollo strategy is to leverage existing Meteor classic “potential” customers, hence Meteor classic is being transformed into an integration point for Apollo.
Corporations corse correct, drop products, change strategies all the time. It just so happens that MDG had a good product in 1.0 and was growing their install base rapidly, but like many startups, profits were an afterthought. This caused its own problems, for just a couple of examples,
``> MDG is in a position where they’re having to do damage control with their existing install base,
``> MDG is having continue investing resources in their original “abandoned” business strategy (aka Meteor classic).
In an alternative universe, if MDG was making sufficient profits and growing their install base with their Meteor classic/Galaxy strategy – we’d have an army of MDG devs working away improving Meteor classic as we speak.
I think this is an accurate description of the situation.
That would have been great! Meteor classic was really unique in terms of developer productivity, I’ve seen many frameworks and technologies in the past and it was really a breath of fresh air, it just worked…
What is interesting about Meteor classic is that it opened the floor for many entrepreneurs and non-technical people to start building apps with little programming background and I think there is a long-tail of potential developers that perhaps could have been monetized…
But echoing what @bsbechtel said above, I also think that advanced users tend to be more vocal, active and demanding and might resulted in blind bias toward them…
I too was a new developer when I started developing with Meteor and the simplicity of getting started was a huge benefit. As @aadams mentions though the the pivot away from that simplicity model was for two reasons AFAIK: 1) the monetization approach is through hosting and you just can’t make much money hosting beginner apps 2) making things that simple in some cases lead to tech choice limitations and scaling issues, so presumptive developers of higher use apps were hesitant to go all in on Meteor
For me the talk of 2.0 is a lot about re-aligning Meteor with the perspective and philosophy that led to Apollo. Its been said many times over by MDG members that moving away from developing a walled garden to developing stuff that has a wider applicability is critical. So the march of 1.3, 1.4 and beyond is to start de-coupling some of the pieces. Make more of them stand on their own. The problem with that is though is that many of them will not stand on their own or its unlikely that MDG will want to commit enough resources to make them stand on their own.
Will the build tool ever stand on its own, or otherwise be competitive to Webpack? If it won’t why put more time into it? From a legacy app perspective, give me an relatively straightforward migration path to using Webpack in my Meteor app an I’m happy to do the work.
For new apps, I personally want Meteor to be a collection of loosely coupled widely adopted packages with just a little bit of MDG magic sprinkled on top. They can stay focus their extra polish on Apollo and maybe even Useraccounts. Make it easy for me to deploy that app to Galaxy and I’m happy as a clam.
Or maybe Saturn is Meteor 2.0 and nobody wants to say it too loudly yet.
I have a hunch that you’re spot on there. That’s totally okay with me, Meteor is pretty stable and mature at this point (despite all the bickering and complaining on these forums). My only issue with Meteor is scaling with pub/sub and db-heavy apps, and Apollo should help solve that by letting you use whatever db solution meets your needs. Saturn appears to be taking the Meteor ideology of making setting up an app and it’s main features stupid simple, and applying it to the more broad and open JS ecosystem instead of entirely in-house solutions. That sounds perfect to me.
But wait, according to one of the Transmission podcasts (I’ll go back to find it eventually), Saturn is NOT Meteor 2.0, was for internal use, and (I can’t remember exactly) will be discarded?
@SkinnyGeek1010, do you have some inside-baseball about Saturn?
any chance you’ve got a link to that podcast? I haven’t kept up with Transmission since the first few, that was just the impression I got from awhile back
Saturn was an experiment on how to setup a javascript project that has a fairly complete non-Meteor stack. Webpack config, SSR, server framework, test infrastructure, babel, hot module reload, etc…
Giving it a formal name of “Saturn” probably gave the illusion that it is more important than it is.
For now its going to stay internal:
Not complete enough for people expecting a Meteor like experience
Too magical for people who want to set stuff up themselves
Aware that it probably does not make sense to make the build tool a feature for feature WebPack competitor.
This seems right - just make a new name, and new product. Keep Meteor more or less Meteor in a backward compatible way, while still iterating forward where you can. I think this is exactly what MDG is doing, and that’s great.
At the same time, new products are great! Company != product. It’s good for a company to have more than one product, and products change all the time (imagine if the iPhone 7 was just like the original iPhone).
I don’t think anyone is suggesting otherwise. I myself have said this much in another thread some days back. But one thing, I’d change your condition somewhat, to this: MostForProfitCompanies ==Product(s).
What I think says a lot is the fact that MDG post a comment like this – which is fine – but then does not squash talk of Saturn one day replacing Meteor at the helm.
Agreed. At first (when I first created this thread) I was thinking a 2.0 would be a better solution… thinking about it further, a new product name would be a better alternative than a 2.0. Not only for backwards compat. but the other stack puts you in quite a different mindset when building (functional + declarative).
I can’t tell you how happy that makes me and how much confidence that gives me in Meteor.
That’s awesome, and thanks for the reassurance.
Maybe the marketing team should push out a message and let the community know that Meteor isn’t just a side project and it can and should be used for serious applications. I think a lot of potential developers have doubts about future support and development nowadays. (similar to how Blaze went under)
I feel like you are trying too hard to read more meaning into everything I say. But if it helps, there are exactly zero plans to have Saturn replace Meteor.
We’re working on this - in my opinion, the strongest endorsement we can provide is to explain how we use Meteor for our own production apps. Expect to see more very soon–right now we are focusing a lot on improving the build tool by working with production users that have big apps, and helping the Blaze transition happen smoothly.
People in the community are using it, and I think Tom uses it to test some Apollo SSR stuff. Either way, we can’t be accountable for every commit and repository out there.
