Is Meteor Dying? State of the Meteor Ecosystem

community
110

To add to @casperandersen 's great reply, a lot of times choosing a package for any framework (Rails, Django, Meteor), there are tradeoffs with technical debt vs an upfront speed increase.

Often the package has more features than your requirements. This means the surface area is much larger than it needs to be which can lead to complexity and additional bugs.

Most of the time I end up writing from scratch unless the package really helps me. For instance using check can be sufficient in some cases where SimpleSchema brings on more debt. However, in larger apps SimpleSchema saves time and reduces bugs by providing a battle tested solution.

TabularTables is another example. This has lots of Meteor specific functionality that is hard to write from scratch. The tradeoff is much better than other packages that do something that an NPM package would also do but has more life.

Traditionally most have shyed away from using NPM which is a shame. There are lots of libraries to solve your problem that have more users, more contributions, etc…

An example would be push notifications. Sure you could do a one liner and have push on the client and push servers but that’s a huge maintenance cost and harder to debug. Using an NPM package for APNS or GCM is a much better bet.

In fact good engineering calls for decoupling things that change and taking a standard library off of NPM and writing an adapter to make it reactive/Meteorized is an overall win.

The good news is we’re getting first class NPM support soon which makes it trivial to import great libraries! Having React as a view layer brings up a huge ecosystem of view components that can now easily be imported (React Parts).

5 Likes
111

No kidding, it gives the false impression that Meteor is losing popularity. Almost any other graph would have been nicer. Hindsight is 20/20 though, so hopefully the type of graph will change soon. :wink:

3 Likes
112

Based on this google trends search, the state of Meteor seems to be fine:

1054×375 21.4 KB

Search frequency on the terms “Meteor Javascript” is down a bit from a peak in Nov. 2015, but not by much.

2 Likes
113

To be recognized in 2016 the use of meteor appears to decrease

Choose prgramming as category on google trends.

https://www.google.com/trends/explore#cat=0-5-31&q=meteor&cmpt=q&tz=Etc%2FGMT-7

1366×643 30.7 KB

2 Likes
114

Lies, damn lies and statistics :slight_smile:

https://www.google.com/trends/explore#q=%2Fm%2F0t545zt

1 Like
115

Honestly Google Trends != science

5 Likes
117

I think you should choose programming as category on google trends.

118

You do realize Geoff used Google trends at I think it was the JavaScript state of the union to advertise Meteor’s traction with Google trends :stuck_out_tongue: ?

6 Likes
119

People tend to frame data in their favor when it means they’ll win, and argue against data when it means they’ll lose.

It’s human nature to want to come out on top.

I don’t think Sashko, or Geoff, or anybody is past that.

If I were MDG, I wouldn’t brush it off as “the data isn’t facts”. I would use it as fuel to push Meteor onto even better grounds.

Wake up MDG.

120

My $0.02 - yes Meteor is dying. I went to the keynote at Meteor Open Camp and the panel discussion afterward. It looks like MDG is trying to get Meteor off it’s plate so it can focus on a new approach called “Saturn” and also on something called Apollo. In addition, it seems that the long build times are just not feasible for a serious development environment – it makes remote pair programming practically impossible, for instance.

3 Likes
121

Long build times are not feasible?

You guys obviously never developed anything that needed an actual compilation step.

3 Likes
122

I don’t think MDG is necessarily trying to get Meteor off their plate; Meteor is currently helping sustain and grow the company. Up to this point, Meteor is why Galaxy exists (in its current state), and MDG isn’t going to throw that away. What they are trying to do though is become (remain?) profitable (this is a good thing!). They’ve learned a lot over the past few years from both developing Meteor and watching how individuals/customers/companies use Meteor. They’ve lived through the same pain points and areas of frustration we’ve all experienced, and have learned from it. Apollo is a perfect example of this, and MDG hopes it will help push the company forward. If you take a closer look at Apollo, you’ll quickly realize MDG is course correcting on a some of the technical decisions they made with Meteor. Painful in the short term I know, but this ultimately a good thing - instead of doubling down on past decisions, MDG is listening to its customers/community, is revamping its stack, and is charging full steam ahead.

As for Saturn, it’s a micro-framework that can be used to help develop Apollo apps. Since MDG is pushing Apollo separately from Meteor (ie. Apollo isn’t dependent on Meteor), it makes sense to help Apollo developers out with something like this. That being said it’s still considered an “internal to MDG project”; we don’t know what their plans are for its use (but I’m pretty sure it wasn’t just developed for GitHunt :slight_smile:).

7 Likes
123

Very discouraging to see topics like this on the first page & with by far the most amount of clicks… More people have viewed this post than have viewed the welcome to the forum…

But I do hope it catches MDG’s attention. I believe much of the community is worried about the direction of Meteor.

And rightfully so! I know I have that worry myself where I’m not sure if Meteor is even going to be in active development in 1 year. At least, not in the form we have known it in the past.

It doesn’t really seem like we’re simply “getting new features to improve Meteor”. The way this is being handled sends a much clearer message that Meteor’s kind of being pushed out of the way for Apollo and in order to mesh with the JavaScript world as a whole. This sacrifices everything Meteor was built on, and what we know Meteor as, in order to make a new product.

Yes, MDG may be trying to use what they learned towards Apollo. But as a Meteor user, why would I want to move to Apollo if it doesn’t even have the same values at Meteor?

TBH I’m a bit worried for the future, as my job has a major project with Meteor that will be ongoing for at least for the next 1.5-2 years. But no one can even say if in 1.5-2 years Meteor will still be supported, or if it will be given up completely in order to support Apollo, without a way to transfer our Meteor project to an Apollo project.

Sure, Apollo may push the company forward. But what about us users? There hasn’t been any indications that we will not be left behind, and 1.3 has started a trend of that.

So in the end, right now I can’t blame users for being worried about the future, concerned with the direction of Meteor, or for feeling a sense of abandonment.

2 Likes
124

We should wait. MDG is changing a lot because the current technology isn’t “state of the art” anymore. In the upcoming releases, we are able to use the database we want and this is an important feature. Yes, Apollo will replace DDP and Minimongo but this doesn’t mean that there will be no Meteor anymore. It’s normally that we have to deal with big changes every X years and now we are at a point where some big changes happen.

Maybe MDG will focus again on developer experience if the transition to Apollo/GraphQL has finished. But at the moment, MDG has to set it’s focus on the technology.

3 Likes
125

<Rant rant={this.state.rant}>

If you do google trends for backbone, angular, and ember you will see a trend: they all show up and reach their peak about two years in, then “die” off.

Backbone ~ sept 2010 - may 2012

Ember.js ~ nov 2011 - April 2013

Angularjs ~ march 2012 - august 2014

If somebody wants to get famous, you can write a blog post and coin something like the “2 year rule”.

My take is that javascript developers do this to themselves by chasing the “next big thing”, which actually is not a big thing at all, and is really just a marginally (read: negligible) improved version of the old thing…

why improve on backbone, ember, or angular when you can learn three different frameworks and three different ecosystems and all the different and changing “best practices” for using each? All so you can now have to learn react! All so you can build the same CRUD app you could have built with [insert trend].

“but it is more maintainable”

Okay. I think that is the same thing the [backbone, ember, angular] folks said 2 years ago, who are now re-writing their apps in react instead of maintaining them in the framework formerly known as more maintainable.

I’m afraid (and certain) that react will face the same demise as people realize it isn’t really any more maintainable than the next “more maintainable” framework, and that the shadow dom is impressive to devs and not end users. I have a huge grudge against react, but I would say the popularity is because it is a cult, rather than a superior solution.

</ Rant>

2 Likes
126

IMO there are only two options:

  1. Change rapidly to stay up to date with JavaScript, which will undoubtedly cause some discomfort for current Meteor developers who are used to the “classic” Meteor ways of doing stuff
  2. Keep the same components and style forever and only make small iterations, in which case it will be a similar outcome to angular/backbone/etc as @a.com noted above

I think option (1) is great because it means that rather than Meteor becoming totally irrelevant and then you have to rewrite your entire app, Meteor 1.2, 1.3, 1.4, and upcoming 1.5 are a relatively smooth ramp with an incredible amount of effort put into backcompat. Sure, the best practices are changing all the time and that can be confusing, but we’re doing our best to provide the Meteor Guide which records in great detail our intentions for how Meteor code should be written. Avoiding these changes will only make Meteor more irrelevant to new users over time, which I honestly think will be much worse for the current community than the current approach.

16 Likes
127

My only question is why not keep the principles Meteor was built upon while doing these things?

I mean most of the responses are indicating same as you have, that it would be good for Meteor to stay up to date, and that’s a great thing.

Staying up to date is not the issue causing this discomfort, though. It’s that the principles were basically thrown away while bringing Meteor up to date, so much that they were completely erased from the website. But the majority of people who loved Meteor did so because of those principles.

Meteor was always known for it’s amazing productivity, and that’s honestly all I am hoping to preserve in the transition.

I know a lot of ppl say Meteor’s stand out feature is the reactivity… but imo it isn’t the reactivity alone - there’s other options for that. What makes Meteor special is the combination of reactivity PLUS productivity. That’s what is special - that you could crank out a real time website in less time than it would take most people to make a static website.

That was the history of Meteor, so I just find it very alarming that MDG is removing their design direction of productivity from the website, and very hesitant to say that is Meteor’s future…

2 Likes
128

IMO, the greatest benefits provided by Meteor are:

  1. Unlike most (all?) stacks, it’s a fully encapsulated stack, where front-end integrates tightly with the back-end.
  2. And it’s all in a single language, reducing the need for developers to have to worry about separate languages for front/back.

That’s it. Other aspects of it are cool, such as reactivity or optimistic UI, but are not unique to Meteor. Because of the two points above, I feel like development time is greatly streamlined. And one of my highest priorities in building a SaaS is getting it out there ASAP, since I’m a one-man team.

2 Likes
129

Which principles are you referring to that are abandoned? The ones we removed (to bring it down to 4 from 7) were ones that turned out to not be true in the first place. For example, there was a principle about simplicity, which said something like “the easiest way to make something seem simple is to be simple”. But when we thought about it, it turned out that Meteor was anything but simple. It took incredible complexity inside to enable a simple developer experience, so I don’t think that principle was really ever true.

1 Like
130

In my opinion Meteor should be able to stay agnostic enough to allow for major code overhauls without upsetting everything if your code is shallow enough. Like not overhauling templating or coding paradigms even if background technology changes

http://stellarbuild.com/blog/article/is-meteor-dead-or-dying

1 Like