Maintainers Needed


#1

I’ve published quite a few Meteor packages that people still use, but I haven’t used Meteor in over a year so I’m in no position to answer questions or review PRs. If these packages are to live on, they will need a people to step up and maintain them. Please let me know if you are interested in maintaining any of these:


Some of you may be wondering why I don’t use Meteor anymore. Meteor is awesome, particularly for beginners, but it’s too easy to outgrow.

  • If you want to use a database other than MongoDb, that’s just not an option (although Apollo will eventually answer that).
  • If you want to build a social network application, there’s no infrastructure in place to stream posts into users’ feeds in a scalable efficient way.
  • If you want to build a scaleable chat application, oplog tailing is going to hold you back.
  • If you want to build a React Native app, you need to learn a new set of tools and hack together a way of speaking to Meteor’s backend. There are packages to help with this, but why isn’t it all integrated into the Meteor CLI tool to make everything easy?
  • If you have a large application that you want to split into multiple entry points and asynchronously load source code on the client, you can’t do that.
  • If you want 200ms rebuild times and hot module replacement, you don’t get that either.
  • If you want to build a continuous integration pipeline with git hooks, unit tests, functional/integration tests, and automated deployments, you’ll have to figure that out yourself.

Granted, there are solutions to some of these points, and MDG has been doing a good job integrating NPM packages and ES6 modules. But Meteor is not growing at the speed that technology is growing. I learned how to program 3 years ago just by playing around with Meteor – I am very grateful for Meteor and major kudos for MDG – but I went from zero to beyond Meteor’s capabilities in less than 2 years!

But I also really miss Meteor because it was so easy to build something. When I had a few hours to spare and wanted to mess around with an idea, I could get something deployed and live in no time – it was glorious! But now, I have to juggle the options, choose a hosting solution, and this stuff squanders my creativity. So I do wish the best for Meteor, and maybe someday we will reunite.

So what am I using now? FeathersJS is awesome. There’s more to learn and figure out, but its the right way to structure a Meteor-like application. You can use any database and get reactivity, everything is structured as a microservice by default, and you can scale this architecture in whatever way you need to meet the needs of your application. However Serverless looks really awesome, but its really hard to get started unless you’re already intimately familiar with AWS services. And on the frontend, I use create-react-app.

At the end of the day, these are no replacement for Meteor in terms of convenience and getting your creative ideas onscreen, but if you want to build a social app or a chat application, Meteor just isn’t a good choice.

Cheers,

Chet


#2

It’s a really good thing the world doesn’t need more social apps or chat apps … :slight_smile:


#3

@hwillson unnecessarily sarcastic as always.


#4

Haha - in this case I actually wasn’t trying to be sarcastic - maybe a bit tongue-in-cheek. I have to use Slack, HipChat and Yammer for client work, so I’m probably just suffering from social/chat app overdose …


#5

I think he has a really valuable perspective.


#6

I do too, that’s one reason it was unnecessary.


#7

Hi @ccorcos , you missed a lot since the past year. I was very close to quitting Meteor myself, however they pulled their things togheter: NPM + Modular approach. And now with 1.4.2 rebuild times are within 1.5s - 2.5s (for relatively big app ~300+ react components).

We now have packages for deep linking collections in MongoDB.
http://grapher.cultofcoders.com :smiley:

When comparing it to feathers, you almost say like with Meteor you cannot connect it with any database, or you cannot scale the architecture the way you need.

Regarding deployment: It takes you 10-20 minutes, get a digital ocean instance, configure mup quickly, far from “squandering” your creativity. Does it take you less with other frameworks ?

I always keep an eye on what’s new and what’s not. And currently, Meteor is the winner. Not because it’s the best, but because it’s the friendliest. This will always win in the long-run.


#8

@diaconutheodor first, let me give you some context – when I was learning how to build websites, I was getting a PhD in robotics. So my experiences with Meteor were strictly for fun and creativity.

So when a new XYZ came out, I wanted to play with it! So it was really annoying having to lag behind, and I ended up learning other tools just so I could play with these new things.


#9

I think a lot of us are that way. You kind of have to be if you want your knowledge to remain relevant in the JavaScript community.

Similar to you, I’ve grown a lot from doing things without Meteor. And yeah, I’ll say it: I love working without Meteor. But… I also love even more working with Meteor. And still, I love even more being able to work with both Meteor and non-meteor applications.

Choice is a beautiful thing.


#10

@mz103 I think we’ve gotten quite distracted… would you like to maintain any of the aforementioned meteor packages?


#11

@ccorcos Did you move away from phoenix ?


#12

I never used phoenix, you’re thinking of my brother:

https://learnphoenix.io


#13

I’d like to see something like this for Feathersjs (which I have heard great things about).


#14

Got it. It’s very cool to have programming as a hobby. However, I’ve been focused on Meteor for the past year, business wise I made a tremendous risk to shift everything to Meteor from PHP. I learned so many things I am daily learning things about Meteor and I must say this: It’s absolutely gorgeous on the outside and on the inside.

However, when you say I just want to play with and craft things for fun, why are you thinking about the large-scale aspect ?

Ofcourse, Meteor is not the right choice for a chat app that you expect, 10,000+ concurrent users. Well you could do it, but the infrastructure will have huge costs. For that, go Erlang, Go, there are many other tools.


#15

I’m using https://github.com/thereactivestack/meteor-webpack to get 200ms builds and HMR, but it’s indeed sad that we don’t have this included in Meteor core


#16

Hi ccorcos,

I’m volunteering to take on https://github.com/ccorcos/meteor-subs-cache. My github handle is “cesargalindo”.

-Cesar


#17

Ok, I added you as a collaborator on github, but I’m not sure how to give
you publishing privileges for Meteor’s package registry.


#18

Sounds good, I’ll start looking into some of this as I get time a bit over the next few weeks.


#19

I can understand that you may feel this way. But at the same time, I think you should keep an open mind to the conversation taking place here. When you’re both looking for help to maintain packages you brought into the world, and slinging opinion at the same time, than you’re the one who brought it up, no?

If you’re going to make comments about Meteor not being a good choice, I don’t think it’s fair to discourage conversation to the contrary - just because it disagrees with your choice to leave the community.

Remember, the rest of us who are choosing to stay for various reasons still care very deeply about the community.

Thank you for sharing your hard-earned research about those other platforms. It’s nice to see what other options are out there.

Wish you luck in finding maintainers, and in your new directions in hobbyist programming!