Is Meteor Dying? State of the Meteor Ecosystem

[XTA]

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.

[a.com]

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

[sashko]

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.

[Spyridon]

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…

[ffxsam]

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.

[sashko]

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.

[msj121]

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

[vikr00001]

I’m having a great experience with Meteor and am very glad to see it evolving.

[Spyridon]

Well it was actually “Simplicity = Productivity”. Sure, Meteor had a lot of complexity internally, but it was productive to use in the end.

It may not have been true that it was technically not “complex”, but at the time it was true that the user experience was very focused on high productivity - hence all the positive comments about Meteor getting jobs done in so much less time, as well as being amazing to prototype with.

To give up that principle isn’t just saying “We were never complex in the first place”, but it’s also saying “productivity” isn’t a focus as much as it used to be. As it is right now, “productivity” is not anywhere within the principles.

Doesn’t it seem kind of silly that, if it was decided that “Meteor was always complex on the inside so we should remove that from the principles”, that the user experience was also given up on? Even if Meteor was always complex, you stated in your post that it enabled a simple user experience. If the complexity part wasn’t true, why throw away that user experience? In the end, the benefit was the user experience, not the statement about complexity. Why punish the user experience because a comment about complexity was not true?

From all indications from 1.3, it seems to be the case that productivity no longer matters. It’s not just heresay - It can’t really be argued that productivity didn’t go down a bit (especially in situations where you have a large existing project).

As mentioned last post, my feelings boil down to: Meteor’s history was high productivity - allowing real time websites in less time than static websites. I just hope that’s still going to be Meteor’s future, or else it really isn’t “Meteor” in my book anymore, nor is it “better” than it used to be. I personally would love new features, but not at the cost of trading-off anything that would lower productivity in the end. What use are new features if the cost for them is giving up Meteors (arguably) biggest strength?

(PS: That above article explains my feelings about backwards compatibility very well too. It’s very harsh on older projects that so much work needs to be done to bring it up to date, and I fear future updates for that reason.

I think if something isn’t done soon for maintaining the direction of Meteor, addressing lost productivity, and having to massively overhaul code… it will be a big regret of MDG in the future that could have given Meteor/Apollo quite a bit of momentum.)

[aaronkenz]

Please keep documentation up-to-date as it evolves, who is in charge of this? It’s annoying when links don’t work (i.e. http://useraccounts.meteorapp.com/ referenced at https://guide.meteor.com/accounts.html#useraccounts) and highly suggested packages are flagged as not working by the community (i.e. useraccounts:core, https://atmospherejs.com/useraccounts/core). If you are going to recommend a package, please have someone keep it up-to-date.

I still highly recommend Meteor for developing websites/apps.

[seba]

@Spyridon

As mentioned last post, my feelings boil down to: Meteor’s history was high productivity - allowing real time websites in less time than static websites

I think it was more like: “Meteor’s history was high productivity for the first MVP of your product.” Once your application grows in codebase and number of devs, Meteor becomes quite unmanageable.
Well, not just Meteor, most JS solutions seem to have this problem. That’s why the whole JS ecosystem seems to become more enterprisey as more enterprise-grade apps are being build on them. I don’t know if that’s a good thing or a bad thing. Some stuff makes working in larger teams easier, other stuff already seems to become overly verbose IMO. I hope we know when to stop before javascript turns into java EE madness. Ironically, at the same time most Java frameworks are trying to become more lightweight like javascript frameworks. As always, the solution lies somewhere in the middle I guess.

One example of something I find overly verbose is this postReply method from the angular-apollo docs:

 postReply({
    token,
    topicId,
    categoryId,
    raw
  }) {
    angularApollo.mutate({
      mutation: gql`
        mutation postReply(
          $token: String!
          $topic_id: ID!
          $category_id: ID!
          $raw: String!
        ) {
          createPost(
            token: $token
            topic_id: $topic_id
            category: $category_id
            raw: $raw
          ) {
            id
            cooked
          }
        }
      `,
      variables: {
        token: token,
        topic_id: topicId,
        category_id: categoryId,
        raw: raw,
      }
    }).then((graphQLResult) => {...});
}

Really?

Compared with our usual Posts.insert({...}) …

[Spyridon]

As the project grows I found Meteor more manageable than most other frameworks/platforms out there.

But the rest of your post, is exactly what I mean… 1.3 has become more verbose and less productive. 1.4 hopefully won’t be too bad based on change list but I haven’t looked in to it much until it’s a RC, but Apollo seems to be a completely different beast… and I’m worried about how it’s going to change Meteor in the end.

I don’t mind learning something new, but I DO mind the primary software I use becoming less productive and more verbose. Would most of us even be here if it wasn’t so productive…?

[orbyt]

@Spyridon

But the rest of your post, is exactly what I mean… 1.3 has become more verbose and less productive.

@Spyridon

I don’t mind learning something new, but I DO mind the primary software I use becoming less productive and more verbose. Would most of us even be here if it wasn’t so productive…?

I recently came back to Meteor after about a year and YES, why has it gotten so much more verbose? That was pretty much the reason I got into meteor in the first place, it was dead simple and productive.

[dcworldwide]

That is a great point. Graphql is verbose in this form, I hope we can see an abstraction that simplifies it.

[aadams]

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.

Why bother integrating Apollo into Meteor proper (thereby in a way deforming/mangling the stable-just-works-easy-to-use-not-verbose Meteor we use today)? Why not start over, start fresh, with Apollo and Saturn as a new stack (or even use in conjunction with Meteor)?

They seem to be making Meteor “less safe” with this strategy (or is that the idea)…

[robfallows]

Have you listened to Transmission #13?

From what @sashko said it sounds like Saturn is unlikely to become a “product”, and far from make Meteor “less safe”, Apollo’s making it more robust, scalable and more appealing to a wider audience. I have to say I got somewhat stoked!

[aadams]

@robfallows, I can’t tell to whom you’re addressing, so I’ll pick up your comment:

No, I haven’t heard the latest Transmission episode, but it seems plain to me… and others:

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.

… that they’re gutting the entire Meteor stack as we know it today in favor of Apollo and all the tech that will form the glue around it. Maybe you and others are excited about what all this will mean, but I simply don’t have the luxury of such indulgences when I have a full fledge production application running Meteor 1.1 on the market.

If it’s true that MDG is “corse correcting” as others has said/suggested (and I believe), why not leave Meteor as it is today to the community and start over with their new Apollo strategy on a clean slate? Why is MDG ever-so-slowly replacing the Meteor stack with the Apollo stack?

From what @sashko said it sounds like Saturn is unlikely to become a “product”

That’s almost like saying – YES, Saturn is to become the “Product”! (also, maybe this IS MDG wiping the slate clean after all in some respects).

far from make Meteor “less safe”

I just don’t agree with you on this. It has become “less safe” than it was 6 months ago. The future we’re told (for now) is SQL/Apollo/Redux or **Saturn/React (to replace Mongo/DDP/Tracker/Blaze). But wait, this new strategy is not fully baked, and based on roadmaps floating around we don’t know when this tech marriage will be ready for production apps.

Now start a real project today (one that you or your company will make money off of and will be client facing) with Meteor and tell me how safe you feel you made the right choice.

** The Saturn repo: “Saturn (at least initially) is heavily inspired by (/ outright copied from) the React Redux Universal Hot Example, and hjs-webpack.”

[robfallows]

I can’t tell to whom you’re addressing

That would be you - I clicked the wrong reply button

Maybe you and others are excited about what all this will mean

I’m excited, but that’s not to say I’m comfortable with all the new learning I need to do.

I have a full fledge production application running Meteor 1.1

We have an app at 1.2.1 - which we’ll upgrade to 1.3 - but retaining the traditional all-packages architecture. We’ll upgrade to 1.4 using the same strategy. Looking beyond 1.4 is less clear, but it seems unlikely that the rug will suddenly be pulled from under us. If it is, well at worst we’ll just continue to support the app using the highest level of Meteor which allows us to do the least work in upgrading. We may bite the bullet and rework to use all the latest “good stuff”. We did that for Blaze to React and it worked out well refactoring piecemeal over several sprints.

Let’s face it, if I wanted to, I could checkout the 0.6 branch of the Meteor repo and build myself an application with that. I honestly don’t see that we will lose the ability to pin our app to a particular point in Meteor’s evolution given that has always been a feature of Meteor.

Given @sashko’s comments on Transmission, it sounds like we’ll have a lot of easy-win (typical Meteor workflow) situations in 1.5. We’re already integrating data from MongoDb, MySQL, MSSQL and SAP HANA. That sounds like it should be a whole lot simpler with a tight Meteor/Apollo integration.

Of course, it’s all speculation on my part, but I’m optimistic.

[aadams]

Looking beyond 1.4 is less clear, but it seems unlikely that the rug will suddenly be pulled from under us. If it is, well at worst we’ll just continue to support the app using the highest level of Meteor which allows us to do the least work in upgrading.

Fair enough. I’m in the same boat, but unlike what you guys did, I’m waiting to see what that stable version looks like before updating. Besides, I made the mistake of using Autoform, instead of rolling my own, so I’ll have the added work of migrating off that tech.

We may bite the bullet and rework to use all the latest “good stuff”.

I’m so busy adding new features and improving the software I don’t have the cycles to rework then entire app – it could possibly take months of rework.

I honestly don’t see that we will lose the ability to pin our app to a particular point in Meteor’s evolution given that has always been a feature of Meteor.

Really, you don’t see what is lost by pinning our apps to a version ad infinitum?

[ramez]

Thank goodness for the community

As we start taking over Blaze, then Tracker then … we should be fine. Meteor can become fully supported by the community at some point.