Is Meteor Dying? State of the Meteor Ecosystem

Apollo and GraphQL are specifically targeted at solving the problems people experience with REST.

3 Likes

GraphQL is a query language with schemas, batching and is supposed be used with a single endpoint, very different from REST

MDG has been specifically hell-bent on NOT duplicating work, that’s why the stack is changing so much

1 Like

I think if you looked at Feathers’ solution more, it’d make sense. REST isn’t the problem, beyond the fact that it’s not realtime. REST been well-accepted for some time, especially since you don’t always need a realtime connection. Use realtime when you want to (e.g., make a socket connection) and use HTTP when it’s more appropriate for the use case.

The service abstraction leaves the transport as an implementation detail. You really aren’t even aware which you’re using when you’re querying in the client (beyond instantiating the client, which you do specify the transport in 1-2 lines of code). I probably should have clarified that, with feathers + websockets, you can subscribe and receive realtime changes to any of your services, and update the UI accordingly.

Comparing feathers client querying interface, it seems to be reminiscent of the old Meteor.collection API, while also achieving the level of functionality. You have to say, the apollo client looks a little more complex when compared to the old interface and there are already other frameworks achieving Apollo’s purpose. But there’s nothing really wrong with that, I suppose. Angular 2 is still a thing and I don’t see why they’re bothering (a little late to market). It’s probably just not the most efficient use of resources, especially if you’re going to build on top of React anyways, why not also build on top of feathers.

very well said…

thanks for reminding us that as long as it work for our needs then why worry about the future =)

“I don’t think you’re doing your job as a programmer.” not sure this kind of comment has a place in this forum… “criticize ideas, not people.”. I’ll let your read the forum rules again and think about the way you engage people here. I don’t remember attacking personally anyone.

As for the rest I started writing a long, thoughtful reply which I ended up deleting halfway. Meh why even bother at this point

Hi @taken, Sorry, you’re right, I was more abrasive than I needed to be. When I say “you” I mean “any person in general”. We view a software application a kind of machine, and we use packages when building our machines if it looks like it would save us some time. But often the package is only an 80% solution, and to get the machine we want we need to write code to address those shortcomings or to workaround undesired behaviors. That’s all I meant. Ultimately we have a machine to build, and we’re going to build it—with or without someone else’s packages.

So please, do continue with your post. Maybe we can assuage your fears because, as I mentioned, we’ve been running on Meteor since version 0.6 and have worked through a lot of issues, and on the whole it’s worked out pretty well for us.

If a package gets abandoned, yes, there’s a chance that your app might break when you update Meteor i.e. from version 1.0 to 1.1, or whatever. That’s happened to us many times. But there are several ways to deal with it. Often the problem affects other developers too, so someone else in the community may fix it with a pull request or else publish what you need to do to patch it yourself. Changes between Meteor versions are well-documented, so often you can research the error and find out exactly what needs to be changed i.e. a deprecated function was finally removed, so you need to make a change to use it’s replacement. Or it could be a syntax change in a mongodb query.

But I understand that not everyone has the same tolerance for these kinds of disruptions and uncertainties. So it’s always possible that some more stable framework is a better choice for your particular style. We’ve been operating in this environment for so long that the churn-rate feels normal. Web application development is like drinking from a fire hose.

2 Likes

Break things and move fast.

I think MeteorJS is moving fast, and also actively & positively embracing the ecosystem, integrating with webpack, react (native), npm & many other very great tools.

Meteor is evolving towards the right direction and in a fast pace with a community of high talents, I believe Meteor has a bright future.

1 Like

Hi…i am new user here. As per my experience with Meteor, the ground is still shifting beneath my feet it has to be, to some extent, if I want my stack to evolve. However, instead of having to sort through a dozen different options when a core piece of the system changes, full-time curator/integrators and an awesome community. Who are smarter than me and/or care more about the specific aspects of the system are keeping abreast of the broader changes, making concrete recommendations, and providing solutions that work out of the box. And everybody who is using Meteor is trusting them to do a
great job of it.

I have just started out the other month and this is my (rather inexperienced) take on Meteor so far.

I am designing a LOB application with a Micro Service architecture in mind. Not being a JavaScript/Node.js guru, Meteor seemed to be a good fit to quickly learn and build what I needed. The benefits I saw as a newbie were in particular DDP, the accounts packages and the easy build process plus I really liked the responsive community.

As I read through tutorials and github repos I learned about libraries that seem to replace one by one the USPs of the Meteor stack or which could be used along, e.g. Webpack, Passport.js, React, React-Router, Redux or recently Apollo.

I have built an example app incorporating the above mentioned libs on top of a fresh Meteor application and now I wonder what exactly I need Meteor for in that mix in the first place.

What I am trying to figure out, without meaning to open Pandora’s box, is, whether the JavaScript community has caught up with what made Meteor unique like say two years ago.

I understand that Meteor can still get you off the ground very quickly of course but with all those new libraries and a complex application on the todo-list, I am not sure if it is the right choice in the long-term. Welcoming your thoughts.

-act

1 Like

curious as well, what does meteor still do?

Helps you build an awesome app, through isomorphic JavaScript, fast Websocket server-client communication, and by eliminating a mountain and a half of boilerplate and callbacks that you’d typically have to write.

2 Likes

No offence to anyones thinking or more accurately feelings but I personally think there is a lot of FUD in this form. My personal experience with the framework thus far is that:

  • Meteor delivers: clients are happy because we can deliver fast, real clients don’t care about React.JS or the underlying stack, they want results! we’re not Facebook, I personally don’t need complex re-usable components or the most flexible GraphQL API (larger project and enterprises will need that), we need something simple that allows us to focus on client needs and Meteor does exactly that.

  • Meteor is a pioneer: reactivity, real-time, optimistic rendering things that client use with joy coming out of the box 4 years ago…things end-user will appreciate, try to explain the value of React.js to an end user which is in my opinion an overly hyped technology that is being sold as the solution for everything. Facebook solution to web problems is to work around them… DOM is slow? create a virtual DOM in memory (which is a bad strategy for mobile web apps due to memory consumption), and what was their solution to slow mobile web apps? abandon the web all together and compile to native…instead of embracing the web standards and helping to evolve it they work around it and/or abandon it…yes bypassing the web short term would work, but longer term the web platforms catches up and those workarounds fades away…

  • Meteor has a great community: it’s really amazing to see how people stepped in to support Blaze because it is a solid well design technology that many found useful and built businesses around.

It is obvious that the Node ecosystem is maturing now and it’s different than what it was 4 years ago, Meteor is aligning it self with the future and they’re doing that incrementally, MDG has lot of experience in their disposal since they started why ahead of the rest of the community to build real-time connected clients and I hope they keep an eye on [Progressive Web Apps] (https://developers.google.com/web/progressive-web-apps/) that I think will deliver more benefit to the end users then the overly hyped React ecosystem. I also hope that MDG leaderships provide some sort of announcement in the the near future that would ease some of the fears and uncertainty behind post like these…

Just sharing my opinion, alright back to work :slight_smile:

7 Likes

agreed, but that’s the ‘old’ version , what will the future versipn bring (don’t take Apollo into account).

genuinly curious.

The future is with apollo, you cannot ignore that. And it will bring a lot:

  • easier data handling in component driven apps
  • support for multiple databases and -sources
  • in general more security and stability, because it is more easy to reason about what data is used in any component, so less bugs and security-flaws
  • better interoperation with other services that exposes REST or similar.
  • better maintainability

If you do not need any of these, you will be fine using the classic meteor way that has also it’s benefits.

1 Like

Didn’t mean to ignore it, but just that Apollo is ‘clear’. Meaning, I get that part. Great stuff and makes sense. But I believe it has been discussed before in other threads, but I’m guessing more people like me are asking themselves what will “Meteor” be. If we take out Blaze, DDP, Collections, Tracker, Packages, etc… What is actually “meteor” then. The build tool?

I’m not trying to trash Meteor in any way here, genuine question. Changes are coming fast and it’s hard to keep up with all the different things going on in Meteor at the moment. It’s true that ‘classic’ will work (for now). But for me that’s bad advise. It’s end of life. No reason to start using it for new projects anymore.

2 Likes

yes, you’re right, i did not follow everything here :wink:

I asked myself the same question. Meteor is a platform, where you run your app. It provides a build-tool and a server. The server part is not to be ignored, that’s still a lot of work. But you are right, it seems to do less than it did before.

By the way, packages are just replaced by npm. Isomorphic packages (client and server) are still possible on npm, so i think there will be meteor-specifc isomorphic packages on npm, just like on atmosphere before.

Really? I’d like to see an example of one of these. Not being facetious … I’d actually like to see how the repo is structured. I’ve got a bunch of packages on atmosphere that use isomorphic code and I haven’t yet seen an easy way to achieve and maintain the same sort of thing on NPM.

Check featherjs. They use that intensivly if I remember correctly

Hey all, I think this topic has been exhausted. Please open new threads about particular issues or ideas you have so we can keep to one topic per thread!