Why not Meteor in 2020?

[alawi]

@hypo

’d put a +1 under almost everything written here. Accounts is just so much less pain than anything else from the JS ecosystem. Meteor is still a very solid choice for new projects, and MongoDB’s query syntax + not having to use an abstract ORM + query generator is a big plus.

Agreed, it seems you’ve a successful product, so congrats. Let me try to push back on the concerns a bit.

As of now Meteor is still coupled with MongoDB, so I’d say if you want to use SQL perhaps Meteor is not the best choice. (although I know there is a functional SQL driver and someone was using it for years with pub/sub).

I personally like MongoDB for web apps, I’ve used Postgres and MySQL with Java for more than a decade, and prefer Mongo syntax over SQL, although SQL is really powerful and had many years of optimization.

@hypo

It did grow bigger, and now MongoDB is simply not performant enough for my case anymore

Where are you hosting your MongoDB?

There are many providers for MongoDB and it serves most of our use cases, also financially they’ve been doing really well, it is a very competitive market with many established players so they must be doing something right. But I do understand the desire for Postgres integration.

accounts needs a built-in way to function as a server for external (non-Meteor) apps.

I think this is straight forward to do, we have several non-meteor apps authenticating with a Meteor server. Perhaps I’m missing something?

@hypo

Everyone and their parent will have their own k8s at some point.

I don’t use it, I don’t plan to use it in the near time. I’d rather have DevOps managed by Galaxy. For some apps, I have some docker containers running Meteor apps on DO, others on Galaxy. So what exactly am I missing here?

@hypo

Atmosphere packages begin to crumble slowly, packages are not maintained.

The advice here is to use npm packages directly and only use Atmosphere when requiring some features that can’t be done in NPM. Atmosphere can define client/server targets which can’t be done on NPM, but I mostly use NPM and only use Atmosphere for very specific packages.

@hypo

the apparent Semantic Web lift off

I was given a course about the semantic web at university 15 years ago, back then the professor said the exact same thing, he said Semantic Web is lifting off, instead we got Facebook. Maybe this time it’s better .

@macrozone

• nextjs
• prisma2 + nexus (can even run directly on nextjs to get a full-stack monolith)
• react-admin + ra-data-prisma for back-office

• NextJS: is a really confused famework, first they marketed as a SSR framework, then Static Sites framework, now they’re calling it a hybrid framework. It’s a framework that can’t make up its mind where to best render a page next, and which next hype to follow, so they called it NextJS. I personally think, it is an overly hyped framework and good for basic blogs and CMS only.
• React-admin: we built our own, not too hard to do with React/MUI and we prefer the flexibility.
• Prisma2: I like it, but it kinda reminds me of hibernate in Java. Generally, I’m not a big fan of ORM, I’d rather have less abstraction and only add middle layers when absolutely needed to avoid unnecessary defects/complexity.

It is not surprising that many entrepreneurs and even senior developers complain about JS fatigue. Just look at the list of tools mentioned in this thread alone and put yourself in the perspective of newcomers and you’ll have a good understanding of why Meteor is a solid choice for many. At the end of the day, many of us want to create value to our customers and generate profit not just fiddle with new tech.