Suggestion: split Meteor in many npm packages

Meteor has the proposal to be able to write the same code that is used in the backend and frontend, but when I look at its organization, I think that the ideal would be if meteor was separate folders backend and frontend, with npm packages like mini mongo client and many others, letting the frontend side choosing between which bundler to use and which frontend technology to choose, but being able to use the same code by sharing a folder by symbolic link or npm package path reference

an example of what shows me that meteor would be even better if it were a series of npm packages is when I try to configure babel

That makes sense? Are there any plans for this?


the advantage i see in Meteor (frontend + backend) is nice use / integration with DDP.

Does any other frontend / backends support DDP besides Meteor? if so, then splitting might make sense.

Having Meteor just on backend without anyone using DDP wouldn’t make much sense. Also what would be the advantage of Meteor on client without Meteor backend?

Yep, you can use DDP with other frameworks: GitHub - Gregivy/simpleddp: An easy to use DDP client library

so what does Meteor frontend have that would make it usefull to be separated?
and what does Meteor backend have that would it usefull to be separated?

For me, separating Meteor as npm and between frontend and backend projects would allow us to customize projects more efficiently. I had a lot of headache to integrate Meteor with Svelte and ESLint, besides, I see that Meteor has a specific version of NodeJS, separating projects and packages would make us also have this control

the simpleddp package is interesting, but how to start the server in backend only mode? And it would be interesting if the mini mongo client was an npm package and so on

The authentication token is in localStorage, I don’t know if this is much discussed, but it would be interesting if the backend was separate and could also implement HTTP endpoints and finally put the authentication token in a secure cookie

If everything was split between npm packages, we could test them with Jest for example

it could also make the Meteor.js project simpler by taking integration tasks out of a project as a whole

1 Like

but how to start the server in backend only mode?

I have example projects in this tutorial: Meteor Microservices - YouTube
These are backend-only projects.

And it would be interesting if the mini mongo client was an npm package and so on

Minimongo actually exists as npm package but needs lots of code to run as you know it in Meteor client style: @meteorrn/minimongo - npm

Disclaimer - I updated the package to the latest state since all other npm minimongo packages are highly outdated


Really great stuff @jkuester

but needs lots of code to run as you know it in Meteor client style

That’s the spirit, I think if meteor was like this backend you showed in the video, plus a folder with the frontend using any bundler like webpack, vite or parcel and one more shared folder to be used by both the backend and the frontend


There are many great frameworks as you suggest. What will be the benefit to the community? I couldn’t understand what will differentiate Meteor from them.

Meteor is great because it’s a full stack. You do not need to maintain two code bases. You could but you don’t need it. You will get the optimistic UI for free. State management is incredibly easy. When async/await migration is completed as planned the future is bright for Meteor.


What will be the benefit to the community?

Making Meteor more customizable: frontend agnostic, node version agnostic, being able to customize frontend build

You do not need to maintain two code bases

That’s great, although how could we keep one single codebase working with react native for example? The ideia is to have many npm kind like we have in react native for now but still being able to share a common folder between a frontend project, a react native project and a webserver project, maybe with symbolic links

I had a lot of headache to integrate Meteor with Svelte and ESLint

That’s also an example of a big problem I’m trying to solve here

Isn’t this express.js? Customization means configuration and lots of headache for this kind of needs I’m using other frameworks for these needs.

I don’t know what was the issue with Svelte or ESLint. I’m not using Svelte on production but created an example project to learn it. Maybe we can check it together. examples/complex-todos-svelte at main · meteor/examples (

express.js is not proposed to have one single codebase

But I see the need to customize a Meteor project and it’s a bit difficult for what we have now

Great! Would you like trying adicionar ESLint and unit tests? This is the kind of customization it’s hard to find or to do so with Meteor.

A good question to think about is: how does Meteor integrate with these more established tools? The State of JS 2022: Libraries

I don’t quite understand why you’re suggesting changing Meteor to match lots of other frameworks out there? The whole point about Meteor’s original design was to be fullstack. That being said, over the years it has been redeveloped to work with a wide range of frontend systems. Blaze, React, Angular, Vue and Svelte all work. Some work better than others, but it would be impossible for the Meteor team to cater for absolutely every frontend framework available.

I appreciate that this tends to make Meteor come across as an all-or-nothing proposition, but that is its greatest strength. The more modular you make software, the harder it becomes to maintain, because the number of module combinations increases exponentially.

However, if you search these forums you can find examples of people’s projects that do only use Meteor as a backend, especially for mobile apps, so it is possible. :slight_smile:


I’m suggesting splitting Meteor.js into npm packages to allow other stacks that were evolving to integrate with Meteor.js

Meteor works fine with React, but if we would like to use Next.js it would be difficult again, so I would suggest having many npm packages so the integration would be possible and graceful

I understand. I guess the question I would ask is if you’ve decided to use Nextjs for the frontend of a project, why not choose a backend framework that already plays nicely with it? What is it about Meteor that makes you want to choose it as the backend over other frameworks, even though it doesn’t currently work well (or at all) with Nextjs?

Mainly the fact of being able to work with the backend and frontend together

But I believe that the best answer to your question is the fact that I could start a project without knowing the ideal direction and I believe that the credibility of Meteor.js can fall due to the fact that it compiles the frontend and backend together (ideally frontend and backend should be compiled separately in my opinion)

Today I took a look at the monorepo approach, in my opinion it would be the ideal future for Meteor

That’s the whole point. Why take Meteor’s uniqueness away? It will be rather detrimental to Meteor IMO.

This would continue, but split between packages to be able to adapt to more modern stacks or future stacks

And enabling to develop as a fullstack

I would also like to see something along these lines.
It doesn’t mean it can’t have the same out-of-box experience as it currently has. It definitely would be possible.

But the benefit I can see would be that for applications which find themselves having outgrown meteor, have a better way of breaking away parts of the application that don’t want to be meteor based anymore.

I think we are hitting this point at work, and the best way I found to break the ui out of meteor was to spend a couple of hours copying all the needed ddp/minimongo code out of meteor and get it everything building with webpack. We don’t want to replace everything ddp/minimongo all at once, but would rather do it slowly.

Personally I am not a fan of meteor using its own package manager (atmosphere), and would like to see more things moved to npm instead. In my experience using packages from npm is unavoidable, which results in there being two package managers in use. And because of this, any npm dependencies of atmosphere packages are installed separately to the rest, and can result in being duplicated.

And because of how meteor does things, trying to use a different test runner (eg jest) requires writing a ton of mocks (for anything builtin and from atmosphere). I have not been able to find a sufficient external package when I first tried to look. For some packages, (eg meteor/check) it was easier to copy the code from github to use for the mocks. Additionally other configuration is required to get fibers to work correctly.

So to me, going the way the rest of the javascript ecosystem is and using npm feels like a good choice that could actually make some things smoother.


Me neither

@julusian Great post! :heart:

I remember there was a big push to retire atmosphere and move everything to npm packages. Unfortunately, there’s some features of Meteor packages that are essential to the transparent isomorphism that defines Meteor.
Instead of extending package.json to support meteor features, they kept Meteor packages around. What I’m sure was the right decision at the time has held back the platform from the benefits of interoperability

1 Like