Life after Meteor

Hi all

Some might remember me, I used to be quite active here until about 2016… Meteorpedia, meteor-messageformat, meteor-famous, meteor-hmr and many others. Anyways, I left when it became clear that MDG had stopped investing in Meteor in the same way, and I wanted to post my experiences since. I don’t know if anyone else is still around from my “era” but I’d love to hear what others have been up to.

This was originally a longer post but I’m going to sum things up as follows. With Meteor, building apps was a joy. I did loads of weekend projects, it was simple, easy, effortless. Outside of Meteor, initially I loved access to the entire npm ecosystem. But ultimately it became quite painful. Overwhelmed by choices, and every simple thing became a chore. I could build an amazing single app that kept getting bigger and better, but I’d often start side hobby projects only to abandon from the time it kept to build and maintain then.

Probably what I hate the most is data. I haven’t enjoyed GraphQL. I see the problems it solves but I’ve found it a big extra hassle and a worse fit for things like PWAs. This is my personal experience. I know there are a lot of good solutions out there. I wrote an app with Amazon AppSync. I haven’t touched it in over a year and it still runs flawlessly. But I haven’t worked on it in a year also because it became exhausting. I didn’t try Hasura yet, or Prisma, which looks very interesting. I see there are new frameworks now like Blitz, Redwood, Bison which all have potential.

I started my own project to have a Meteor data experience outside of Meteor. I keep alternating between working on it and deciding I’m suffering from “Not Invented Here” syndrome, switch to something industry level, but ultimately go back to working on it. I didn’t succeed in generating much interest around it but I’ve enjoyed building something privately for a change, and this is what I intend to use for my next project.

Would love to hear from others who have left and what your experiences have been since. Preferably if you’ve been using other tech for at least a year, and if your impressions remained the same after this time. Hope any discussion will be constructive, and maybe give some guidance for future Meteor development too.

Gadi

9 Likes

Lastly, to be honest, I’m not doing anywhere near the same kind of dev hours that I used to, so it’s possible I didn’t give some things enough of a chance. But developing apps has definitely become a lot less enjoyable for me since.

Are you considering a comeback after Tiny acquisition?

6 Likes

we switched to next.js with apollo-server, nexus-schema and prisma (2) with typescript. (i created a demo some time ago, but is not fully up to date: https://github.com/panter/manul-stack)

The only drawback is, that you don’t have live-updates, but tbh. that was seldom an issue.

What you get is something that is 100% sound and typesafe (you can generate prisma schema --> nexus --> graphql-schema --> typescript types for frontend) and scales better, because it is much simpler.

There is more to setup when you combine everything, but a pure next.js app is as simple to setup as meteor. Then you can add piece by piece what you really need and you can replace everything

1 Like

Was indeed excited to hear about this. I wouldn’t go back to Meteor v1 though. Is there any discussion anywhere about what a v2 might look like? For me personally, a big draw card would be a Meteor-like system built over polar well-maintained norms (npm, webpack, react, nextjs?). I really miss how the Meteor stack was structured and how easy meteor add some-package was because of it.

Thanks… this is the general feedback I heard from a lot of others. What kind of things are you building? Although I haven’t played with Prisma yet, I was concerned this was a less good fit for an offline-first PWA. I need to try it, but I wonder how apollo-cache-persist (i.e. a query-cache) compares to a full client-side database.

I guess most of us here are happy with life with Meteor, so you might not get the perspective you are looking for.

I personally tried the stack you and macro explored, and I did a couple of projects with NextJS and some with pure Webpack/Express, and I found myself redoing a lot of leg work that is not business-related and that didn’t add any value to my clients, that was not fun, so I kept going with Meteor whenever we can, it was way more pleasant to work with.

Meteor is getting a lot of momentum now, so I think you should reconsider it and try using with it with more NPM packages and one of the dominant view layers (React, Vue or Svelte.) especially now that the serverless and GraphQL hype are slowing down. We are building a lot of PWAs with Meteor and they’re really fun to create and folks are creating more libraries to make creating PWAs easier with Meteor.

Also, make sure to attend the upcoming Meteor Impact there are several workshops pertaining to PWAs :slight_smile:

online shops, mobile apps. in general custom projects for customers, so a lot of different products. So my focus was on a simple, flexible stack where we could swap team members easily, so it was important to keep things simpel and easy to understand.

so nextjs was a good fit, because we could swap the backend easily; some projects might need a backend, some don’t and others might use a third-party backend.

graphql was a good fit, because you can basically look the schema and understand the app’s domain model.

and prisma was a good choice because it

  • has also a schema that defines the database
  • with nexus-plugin-prisma you can create type-safe graphql resolvers based on your db schema, you can even auto-generate all crud resolvers with pagination, sorting and filtering, that can be consumed by something like react-admin

in general i like that it keeps me sane by providing nearly 100% type safety and transparency, makes a lot of fun to develop.

the only drawback so far is still a too basic migration system, but its about to get better.

also authentification and authorization is something that you maybe have to add to the mix and you can do mistakes there.

Yes, there are few actually

  1. Thingking about Meteor 2.0 🤔
  2. Stuff to be removed in Meteor 2.0
  3. Does It Make Sense to Start a Meteor 2.0 to Retain "Classic Meteor"?

@filipenevola

1 Like

Meteor v2 (currently in development) will include HMR and related improvements for sure. Don’t expect much beyond that.

1 Like

Loved meteor

I’m now using

  • node
  • mongoose
  • apollo server
  • apollo client
  • create react app
  • accountsjs
  • mongodb.com
  • dataloader

on most projects. My big thing with meteor were the accounts and accountsjs is the perfect substitute… i wish the project got some more financial backing from a big player that uses it.

5 Likes