Why not Meteor in 2020?

[hypo]

I’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.

My biggest personal concerns right now (YMMV):

• MongoDB’s focus shifted towards closing its ecosystem and having a lot of shiny vendor-locked-in features, while killing its competition. There is no drop-in DB replacement that I could host myself on-premise if necessary. Some DBs begin to offer MongoDB-compatible APIs, but don’t support the MongoDB geo APIs that I currently use.
• when starting to grow more products with Meteor, I put a bet on Postgres for Meteor to come into existence at some point so I could migrate when my app grew bigger. It did grow bigger, and now MongoDB is simply not performant enough for my case anymore. The project to support Postgres with pub/sub has been abandoned. Anyone else who’d be interested in reviving it?
• IMO, accounts needs a built-in way to function as a server for external (non-Meteor) apps. This would allow to deploy more performant components where Meteor is no good fit, but that still need authentication. I know there is accounts.js, but I think authenticating external clients should be a core part of Meteor.
• Everyone and their parent will have their own k8s at some point. How does Meteor integrate there? What about better support for Dockerfile builds? What about built-in integration with things like Prometheus and OpenTelemetry so you can collect method/sub stats in other APM solutions? Or a bring-your-own-cluster license model to run Galaxy on-premise? What about integration for k8s API and a Meteor.js-based k8s operator boilerplate, for example?
• Atmosphere packages begin to crumble slowly, packages are not maintained. This is an issue because many of them have (native) dependencies, they won’t survive an npm install anymore with the coming node updates. For meteor projects to stay alive longer, the documentation should replace Atmosphere package usages with npm-based solutions (if possible without native dependencies) where possible.

Looking elsewhere, I really liked these random ideas:

• the speed and ecosystem of Postgres, which thanks to Zalando can easily run automatically on your own k8s. It’s really a thing.
• the speed of queries in Postgraphile (not so much its account system security, it’s complete Postgres-based dev flow + per-core on-premise pricing)
• the TypeScript API + Admin UI of Prisma
• Airtable. How about a Meteor.js-based community-developed minimal Airtable clone…? This could be crazy good for the whole ecosystem.
• the apparent Semantic Web lift off. An ‘official’ triple store integrations for lowering impedance between Meteor apps and the Semantic Web could be a huge win for the web as a whole.

[macrozone]

@hypo

the TypeScript API + Admin UI of Prisma

prisma is indeed very nice, we are currently building a stak based on

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

this gives you a bottom-up, fully typerscripted full-stack framework, where everything is replaceable and customizable. Only thing lacking compare to meteor is live-updates (still possible to add of course)

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

[jkuester]

@hypo

IMO, accounts needs a built-in way to function as a server for external (non-Meteor) apps. This would allow to deploy more performant components where Meteor is no good fit, but that still need authentication. I know there is accounts.js, but I think authenticating external clients should be a core part of Meteor.

I have extended the rocketchat:oauth2-server to work with the latest node-oauth2 package: https://github.com/leaonline/oauth2-server

Based on this plus some extras I am currently building a full authentication server, that is used by our resource servers. Of course authentication is part of this: https://github.com/leaonline/leaonline-accounts

It is currently still strongly bound to the project it servers but the goal is to make it generic enough, so we can use it in the future as a full oauth2 server for any project.

[macrozone]

your statements here about nexjs and prisma are overly simplified and show a lack of understanding, but its probably not the right place to discuss that here. I just wanted to show some alternatives here, that are in my opinion more flexible and future proof for bigger apps/projects than meteor.

[alawi]

Perhaps I used NextJS a bit, it is a very opinionated React framework, and I think I understand what it offers well but not Primsa (I think Prisma, pivoted from just GraphQL ORM, it seems like an abstraction layer on top of your data source, again I have not used it, so I don’t know it, but didn’t feel the need for it yet).

I have been building web apps for long time and I don’t find their offering appealing to me or much value to our users.

@macrozone, we have a React app with SEO, SSR for the initial page load, code splitting at the routes using dynamic imports, modern JS syntax for modern browsers (differential loading), with CDN on front, loads under 0.8s, with real-time, and it’s a very large app, so what exactly can NextJS offer more to our users? Can you please name one feature that our users might be missing and is offered uniquely by NextJS? I think it’s very relevant to the question in discussion.

I tend to trust my intuition not the marketing hype, but maybe I’m wrong and I’m being too harsh on them, you can keep me honest.

[hypo]

@jkuester

I have extended the rocketchat:oauth2-server to work with the latest node-oauth2 package: https://github.com/leaonline/oauth2-server

Thanks, this is exactly what I meant. Kudos to you!

[hypo]

@alawi

Where are you hosting your MongoDB?

Atlas, but my issue is not the hoster, but MongoDB itself. I do a lot of geo-related stuff where PostGIS is a better fit (but using PostGIS from the beginning would have meant a too-slow start for my apps).

@alawi

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

I missed the oauth package mentioned above. Neat!

@alawi

I have some docker containers running Meteor apps on DO, others on Galaxy. So what exactly am I missing here?

Kubernetes is not for everyone, but there are things that you don’t get outside of its ecosystem. postgres-operator, cert-manager, external-dns, tracing + APM solutions, GitOps, CI/CD, automatic feature branch deployments, just to name a few things… it helps to build systems like Netlify, Galaxy or with complex container-based parallel workflows, e.g. to move around bigger data. Here is why Galaxy announced that it uses it.. It comes at a price: It’s a time-sink + rabbit hole. Hosting on Galaxy is a good deal if you can’t afford the time to learn and set all this stuff up correctly, which is quite some work.

[alawi]

Thanks for the links! I will take a look at that ecosystem, it’s interesting.

[alawi]

@hypo I’m curious about what prompted you to manage/create your own cluster using kubernetes as oppose to letting a provider like Galaxy handle that?

[jonlachlan]

@hypo

when starting to grow more products with Meteor, I put a bet on Postgres for Meteor to come into existence at some point so I could migrate when my app grew bigger. It did grow bigger, and now MongoDB is simply not performant enough for my case anymore. The project to support Postgres with pub/sub has been abandoned. Anyone else who’d be interested in reviving it?

It’s hard to believe that Mongo performance was an unsolvable issue. Are you using oplog or change streams? Why haven’t you adopted Postgres? Have you considered ElasticSearch for geo searching?

What is k8s?

[dandv]

@vikr00001

@dandv, @alawi, these would be great articles on dev.to or Medium!

Definitely not on Medium for me!

@alawi

PS I didn’t know Firebase has this client performance hit. We didn’t use it to avoid vendor lock-in and to have more flexibility/control over the stack.

Can you expand on that? What kind of flexibility was desired (any of these)? I assume you’ve built your own auth solution, but was that worth the numerous pitfalls? Did you have the resources to run a proper security audit? (Not that I expect a negative answer on a public forum : )

Parcel is decent, I’ve been a fan. I did look at Passport.js and Accounts.js and as a solopreneur at the time, I preferred to outsource the security given then auth pitfalls I linked to above.

DB-wise, I’m totally fine with MongoDB and haven’t found compelling reasons yet to desire Postgres or a RDBMS instead. If you want to do joins, you can use $lookup in Mongo.

I haven’t seen anyone mention GraphQL though. I really like its clean and powerful API for clients, and Meteor seems to be agnostic of it, which is a shame considering that Vulcan.js marries Meteor with GraphQL and React.

On the other hand, I suppose I could just build the GraphQL server outside of Meteor, so after checking out the PWA solutions listed here, my next project might start with and stay with Meteor. How’s the Time to Interactive nowadays? Or do folks serve public pages separately?

[vikr00001]

@dandv

How’s the Time to Interactive nowadays?

My Meteor app uses Apollo and React. Here are my current Chrome audit stats, including Time to Interactive:

[alawi]

@dandv

Can you expand on that? What kind of flexibility was desired (any of these )? I assume you’ve built your own auth solution, but was that worth the numerous pitfalls ? Did you have the resources to run a proper security audit?

Regarding Firebase:

• When I checked, they were using some tree-based storage which was not appealing to me (I think they’ve changed that).
• It was not easy to customize the onboarding template and flow.
• There was no way to customize the admin panel (add features etc), so it meant we had to build our own
• But most importantly, I’ve used Google App Engine a decade ago and had many pain points when I wanted to migrate my data down the road, so I didn’t want to take that path again.

With that said, I do think Firebase has its market as a backend for mobile apps with simple CRUD logic.

With regards to the Auth, we use Meteor accounts. We did build our own auth using PassportJS at one point and it took around 5 weeks (one dev) including testing, I personally think it was not worth it, since the time could be have been spent to add features. The security checklist you shared is very informative, luckily we covered all of it except point 2.4 (secondary data verification).

@dandv

DB-wise, I’m totally fine with MongoDB and haven’t found compelling reasons yet to desire Postgres or a RDBMS instead. If you want to do joins, you can use $lookup in Mongo.

Same here.

With regards to Time to Interactive (TTI), it is around 2s, this is after code splitting and optimizing the bundle, React apps can easily get bloated with JS code if one is not careful, I like bundlephobia, and use it before adding any React library, there is also bundleWizard and Meteor built-in bundle visualizer. We also use SSR (with data hydration) to get fast first paint. I think this the area where I would give NextJS credit, since they’ve SSR best practices built-in and they made it easier to achieve that performance with React, but again it is not compelling enough of value proposition for us, it takes some effort and knowledge to get this right with Meteor, I think it can be made easier but it is not too hard to do once the optimization is desired, I’d rather have Accounts done by the framework as oppose to SSR, since it is more sensitive and difficult area as you’ve alluded to.

However, if you’re really keen on the very fast TTI, I personally would go with Svelte. The good thing about Meteor that it has differential bundling out-of-the-box, I don’t think other frameworks has it yet, which means you’re shipping modern code to modern browsers, thus speeding up the execution time.

I’m curious about your experience with Parcel (I find it very attractive as well), how do you compare it to something like Meteor?

P.S I checked your website from the medium link, I think it is impressive, you seem to be a very thoughtful person and I share a lot of your views, so keep it up .

[jonlachlan]

@dandv

I haven’t seen anyone mention GraphQL though. I really like its clean and powerful API for clients, and Meteor seems to be agnostic of it

GraphQL is great. According to surveys about half of its client usage is with library-free http calls. Apollo helps with React integration and optimistic updates. However subscriptions are not as powerful as Meteor pub/sub. The Meteor community has delivered useTracker react hook which should be praised.

[rijk]

@alawi

I’m curious about your experience with Parcel (I find it very attractive as well), how do you compare it to something like Meteor?

I posted about my experience with Parcel here. Back then you didn’t seem really attracted by the way

Summary: it’s really fast, just occasionally CPU gets really high or React components get messed up and you have to restart Parcel (which often still takes less time than a Meteor reload). It’s not perfect but it really made a difference. Not just the speed, but the hot reloading (keeping scroll position and component state) is a godsend for productivity, it really helps you stay in the flow. You have to experience it to understand what I mean.

[alawi]

@rijk

in Feb of last year

Yeah I recall that conversation! thanks for sharing that link, but let us also hear it from @dandv since he seems to have first-hand experience with it.

I personally like Parcel as a build-tool, but we ended up with webpack for a project last year since it was more flexible. However, I do find parcel intriguing, and I unfortunately didn’t have the opportunity to use it in any major project, and I probably won’t now that Deno is here with its own bundler and Rust. Deno for sure will be my new go-to for side projects/experiments.

[rijk]

@alawi

Deno for sure will be my new go-to for side projects/experiments.

Sidenote: I personally find it a little strange how you keep discarding things people recommend (like Next.js and Parcel before), but at the same time are eager to jump on/recommend new, unproven tech you often haven’t even tried yourself (Svelte, Deno, …).

[alawi]

@rijk

hot reloading (keeping scroll position and component state) is a godsend for productivity,

We do have hot reloading with large Meteor projects, we run webpack in parallel when doing front-end work, for medium React project, Meteor refresh is good enough. However, I’m willing to invest money to see HRM API first-class in Meteor as I mentioned here, I think it needs to be there and it is a limitation now especially with React Fast Refresh (the previous hot reload was not reliable most of the time).

@rijk

rejecting things people recommend (like Next.js

I’ve not rejected Parcel, I just didn’t have the opportunity to try it in a major production project. I’ve used NextJS, and I just didn’t find its value proposition compelling enough (at least for me) and I’ve mentioned my reasoning above several times, feel free to respond to my question about NextJS value here, perhaps I’m missing something. With Svelte, the benchmarks are very clear. I try to do my own research, try the tools with side projects, and form my opinion while trying my best to filter the hype.

However, I do think Deno has a lot of potential down the road as I explained in that thread.

[jonlachlan]

@dandv

I assume you’ve built your own auth solution, but was that worth the numerous pitfalls ? Did you have the resources to run a proper security audit? (Not that I expect a negative answer on a public forum : )

Really just a matter of setting a token with a cookie or localStorage.

I agree with you, few people want to own security.