Is it time to leave Meteor & MDG?

Planet Earth
42

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:

  • Blaze - the options moving forward here are pretty well established… Blaze continues to be a good option if you are prototyping or making a fairly simple app. For more complex apps you have Angular or React.
  • Minimongo - kinda fits with Blaze in that its useful for prototyping and maybe even medium sized apps especially if Mongo is the DB for you but Redux is the Apollo store and has much of the developer momentum
  • Tracker/ReactiveVar-Dict - While tracker is a standalone component it seems that using Blaze is nearly a must to get a lot of value out of it - certainly it can come along for the Apollo ride as described briefly in an apollo issue, but I do think its generally unclear how to do a trade-off analysis today of when Tracker is a great fit
  • Pub/Sub/MergeBox - Apollo appears to targets the deprecation of this tech with laser precision. @sashko’s Medium article covers the updates to the GraphQL spec, of which I’m sure Apollo will be fast to integrate. Optionally being able to use stream, live, and subscribe adds more flexibility than pub/sub ever had or every will have as far as I understand.
  • Methods - methods are just a good RPC system. I’d be curious to hear if anyone thinks they have significant downsides and/or when to use them vs. other options
  • UserAccounts - ah good ol useraccounts, IMO one of the original pieces of Meteor that really gave a Eureka feeling. Unfortunately its seems to be a stranded island of functionality with the new Meteor direction. It is heavily dependent on the UI stack choice you make and it’s unclear to me what MDG’s support for it will look like moving forward. They show you how to wrap the Blaze component with React to add it to a React centric app but to me it feels a bit crazy that I would have Blaze in my project just to use a UserAccounts package that isn’t keeping up with the rest of Meteor. If anyone know of further info on this subject I’d love to get pointed in the right direction.
  • Fibers - I share the opinion of @SkinnyGeek1010 “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.”… I get the occasional headache when trying to integrate and wrap other NPM packages but otherwise I quite like Fibers… having said that I do think enforcing the use of Fibers is contrary to the new Meteor goal of being applicable to a wider swath of developers. They two don’t mesh but as far as I know I’ve never heard any thoughts or opinions on the Future of Meteor in this area from MDG
  • Mongo - mongo is as mongo does. If mongo is a good fit for you then there is no pretense of losing it, if not Apollo will be your savior
  • MeteorBuildTool - The Meteor build tool is a giant question mark to me. 1) It may get faster but doesn’t appear it’ll ever be as fast as some of the other build tools out there 2) It’s essentially 0-config is one of its major pluses and a huge benefit for beginners but Blaze didn’t survive on that strength alone either 3) If you can get past the setup other build tools are more featureful 4) It’s fundamentally incompatible with some other build tools - doing a react-native development or want to in the future? then the React-native packager is your build tool

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.

17 Likes
43

@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.

3 Likes
44

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 :stuck_out_tongue: Single inheritance doesn’t count as proper OOP in my book.

45

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

3 Likes
46

I think one of things underlying these concerns is that there are currently no real things on the road map for the longtime Meteor user. For many of us, Apollo won’t make too much of a difference in our app as we are already happy with the Mongo solution. For that group, none of the existing features seem to be being improved/built on. It seems that most things are just on the road to being replaced by tech built outside the Meteor community (i.e. React, GraphQL). Although I plan on sticking with Meteor, I am a bit concerned at the lack of new features coming in that build upon my existing code instead of making me refactor, and also the seeming lack of priority in improving Meteor-specific issues (i.e. build times). MDG could perhaps make some efforts to focus somewhat on existing users rather than solely finding new ones with future framework iterations.

I am sticking with Meteor because I feel like these things are probably coming, based on the posts of some of the employees, but have not yet been revealed.

4 Likes
47

Yea, you’re not exactly Oracle (yet) :smile:
Looking forward to 1.5, the future of Apollo and the future of MDG :slight_smile:

The JS community is a hard one to please. Those who whine the loudest are often those set in their ways or not willing to stay on top of a fast moving game. You glimpse for a second and you’re outdated. I’ve sweared for a few times for some breaking changes that you’ve made. But understood the reasoning behind it and ended up supporting 95%

I understand the outcries from larger companies or larger projects. But honestly. I don’t think meteor was anywhere near production ready before 1.3. Although I made a production app in 1.2 and paid some hours for it, I gladly changed folder structure etc etc.

As “The Pragmatic Programmer” (A book everyone should read once per year) states:

Learn at least one new language every year.

This can, and should be applied to frameworks and libraries as well.

Keep up the good work!
However, if you can get on the “hot reload takes forever, especially on windows”-bug soon I’ll order you guys a pizza from the nearest Domino’s or something. Killing my productivity!

2 Likes
48

Flash framework also includes Adobe AIR, which is a leading framework for mobile games. Very little development happens in-browser anymore (i.e. SWF). In that context, Adobe AIR is a solid framework. We know as we used it quite a bit (video engine, GPU optimizations etc.). Your vision of Flash is based on pre-mobile era. No one develops SWF anymore and that part is legacy and will continue to have its risks and little development going forward.

49

If you’re using angular/react then the only meteor features you are “tied” to are:

methods
pub/sub
any atmosphere packages you use

Once there is a path for transferring atmosphere packages to npm, you can “protect” against any downside even more. You just have to switch out your pub/sub for an rest api (or other pub/sub framework) and switch out your methods for some rest endpoints.

This is more a question than an assertion. Thoughts?

1 Like
50

This is IMO a pretty important, if not literally existential question, for the Meteor community.

My own, short, and very personal answer is no.

But I have to admit that I have had some concerns in the past few months. These are mostly subjective so they generally fall outside my data-driven comfort zone.

When you work in Silicon Valley you want to bet your money, but more importantly, your personal time and reputation, on something that looks like a hockey stick: up and to the right. When Geoff showed the chart of Meteor downloads over time at a meetup last year that gave everyone in the room a strong feeling that they were part of something big.

There were a lot of people in the room that day. In contrast, the last few meetups at MDG have been sparsely attended. My sense is that the elimination of the co-working hours that preceded dinner and the tech talks has removed a major reason for people to attend. The talks are still excellent, especially when guys like ClassCraft come in and show the great stuff they’ve been able to build with Meteor.

But another thing has changed at the MDG offices: the word “Meteor” is slowly being replaced by the word “Apollo.” Apollo is fascinating, interesting, complicated, and strategically very important. But it is different. Not many people are using it yet so the talks around it are mostly broadcasts from the MDG team rather than technical discussions with other fans. If Apollo has a broader community outside of MDG I’m not yet a part of it. That makes me feel like I don’t belong (yet). I hope that will change once I start using Apollo in earnest!

Meanwhile over on SO the pace of Meteor questions has slowed markedly. Maybe all the good Meteor questions have been asked and answered before but there’s a palpable and numerical loss of momentum. Another qualitative observation is that the Balkanization of the Meteor view layer into Blaze, React, and Angular factions has made it much harder for people to get answers to questions because there are fewer experts in each view-Meteor combination.

I think @marktrang has done a decent job of laying out the strategic and market imperatives for MDG in this thread. Being a venture-backed company in the golden age of magic unicorns comes with high expectations for growth. While Meteor has done a great job of attracting developers who are building new applications from scratch (so called greenfield projects), it has not been able to attack the center of mass of the market: existing applications that need to be improved, modernized, and mobilized (that’s a real word but I using it here to denote the migration of apps to mobile).

A long time ago in a galaxy far away, the big enterprise players tried to deal with their giant application hairballs with things like an “enterprise service bus (ESB)” and “Service Oriented Architecture (SOA).” These technologies made a few companies and thousands of consultants very wealthy.

In many ways Apollo feels like a new take on that problem - the integration of multiple disparate data sources into a cohesive, reactive whole that can be used to build truly modern mobile and web-based applications. Again, this is just a feeling; I don’t know if that’s how the MDG team or their investors think of it but as I’m feeling around in the dark, this is the kind of elephant that I think I’m being stepped on by. And it is an elephant of a market. Mulesoft is the most modern of the ESB companies and they are a fairly hot unicorn. Making Apollo successful could have a huge payoff.

By addressing the need to improve existing apps, Meteor + Apollo can be much, much bigger. The message that MDG can really pound on then, which I don’t think they’ve done enough yet, is mobile. There’s a huge demand for enterprise mobile applications and not nearly enough developers to build them all, especially natively. Xamarin managed to establish itself as a dominant brand in the cross-mobile development space and got a pretty decent exit when Microsoft acquired them. [Comparing Xamarin and MeteorJS on google trends is a bit eye opening] (https://www.google.com/trends/explore#q=xamarin%2C%20%2Fm%2F0t545zt&cmpt=q&tz=Etc%2FGMT%2B7) although Meteor is a bit hard to measure on Google trends because of, you know, actual meteors.

Monetization of Apollo and Meteor at scale will still need to be solved for MDG to succeed. Being a value-added reseller of AWS has its virtues but the price of cloud computing keeps getting driven down so it puts an even bigger impetus on growth and customer acquisition.

To my mind, the biggest assets that Meteor have are firstly its people, and secondly, a deep understanding of reactivity and what it takes to deliver it in an application framework. There isn’t anything else out there at the moment that lets you build reactive apps and deliver them across multiple platforms as quickly, as easily, or as pleasurably. Making mongodb reactive was a fantastic innovation. Bringing that to the databases that are already in production will (hopefully) be huge.

Bring on the uptick!

23 Likes
51

Great stuff I think you have nailed a number of good points. I guess my biggest concern or what I’m feeling is “But another thing has changed at the MDG offices: the word “Meteor” is slowly being replaced by the word “Apollo.””

I’m not sure long term this will pay off or work for meteor especially if on the way this loss the early adopters and community looking for enterprise. It’s possible for meteor to be like Flash.

52

I don’t think this is a question that can be answered generically. As has been pointed out, it really depends on your own circumstances based on a large set of local considerations. In fact, you could ask the same question about all the other frameworks out there really. It depends on what you are doing and what you want to achieve, short, medium and long term.

Sadly, it seems to me that the JS dev environment is a complex web of fast changing technologies - I can’t get my head around half of them. It’s fun but avoiding technical debt, even within a year’s time-frame, seems like an impossibility these days unless you’re just plain lucky. On this one point, the safest bet is to go where the big players are. And MDG is not a big player.

I think MDG have built an awesome product actually. I would say that 1.3 is it’s coming of age. My only beef is that MDG do push the ‘it’s so simple to build a web app with Meteor’ mantra. Producing any relatively data/functional rich web app (beyond a todo!) to quality standards ain’t simple. I’m building one now (my first serious project with Meteor) and the amount you have to get to grips with to do the job properly is scary. I’m up to 60 packages already. But I’m quite sure it would be the same for anything else and I’m finding the experience richly rewarding and I’m (almost) always pleasantly surprised by a) the magic of the Meteor core values and b) the quality of documentation that is out there.

MDG have a good chance to keep up with the game - may they thrive and prosper for it is well deserved. I think they have good credibility and can navigate these tricky waters. At the end of the day, you have your objectives and you make your choices. There are plenty of them and I think Meteor would be a good choice in many circumstances.

53

… a year later … good luck with updates :wink:

54

It’s a common problem when startups have companyName == productName: what to do when you introduce your 2nd product?

55

I’m just wondering what about the reactivity thing in Apollo? If I visit the Meteor start page, there is no word about reactivity. On the past website, there was a great animation what happens if you change or add a new document (the change is reflected on another devices).

1 Like
56

As someone who has worked with Meteor since the 0.5 days and has had experience writing about it, using it with clients, and working for companies based on it: Meteor is at its best point yet. Sure, things are changing and MDG is having to prioritize more business-level decisions now, but it’s not exactly falling to shambles. Perhaps the initial novelty/hype has worn off but I don’t exactly see Meteor dying.

Let’s pump the FUD brakes, folks.

24 Likes
57

Agreed. I love Meteor and have been really happy working with it.

Sure, there are Meteor packages that have been left by the wayside that aren’t maintained… but that’s not a problem unique to Meteor. That’s an open source problem.

Keep rockin’ MDG.

1 Like
58

Things are not as like what we had before with Meteor. (2 years back).
Now Meteor is moving to a open direction. And yes, MDG is moving to some other business as well. (AKA: Apollo).

So, it doesn’t means Meteor is dying. In the upcoming months, Meteor will be more open. (Isn’t that what we’ve asked for a long time).

And MDG will focus more on Apollo and they’ll lead the Meteor with the community. I know there are a lot of people in the community working on Meteor. For an example:

Check the number of open PRs: https://github.com/meteor/meteor/pulls

That’s small because, many of PRs has been merged or addressed.

So, here’s the my point (and a lot of others at the Meteor Camp NYC).

MDG will focus more on Apollo. But that doesn’t mean the end of Meteor. Community will(have to) do a major role in Meteor.

I keep asking this all the times.

Yes. Meteor (Livedata) is not hugely scalable. But, then I asked this question everyday.
Tell me a realtime data layer, which is stable and easy to use.

Still it’s Meteor. I don’t think it’s going to change soon.

30 Likes
59

Actually we kind of did!, although “released” would be a strong word :wink:

Ain’t it the truth! (Of course the same is true, more or less in any framework, I guess). I hope the guide has helped a little though? Is there more that could be in there?

3 Likes
60

I think the guide is brilliant actually, but yes there does need to be more of that ilk. I will feedback elsewhere further suggestions in due course. Fact is, with any flexible environment you can build an unholy mess very quickly. You need to establish standards and patterns quickly and stick to them. The guide helps you to do this, though it is still a little too open ended. It needs to be more assertive I think.

I have gone with pretty much all the recommendations. This includes packages that the guide seems to endorse - though how safe I am with these in the longer term, who knows.

On a more general point I think we have to commit our dev cycles to a new level of “refactoring”. Just as we have to continuously refactor our code to reflect changing functional requirements, we now have to continuously refactor our frameworks to reflect changing technical environments/opportunities. The more your dev sticks to one way of doing things and the more you build small, testable components in a clear hierarchy, the easier this cycle becomes. Meteor does not and cannot grant you immunity from this requirement. But I don’t think anyone can.

2 Likes
61