What if Meteor Was Created in 2025?

[mvogt22]

Re-Inventing Meteor: Modernizing a Timeless Framework

Meteor remains my favorite framework for building applications. In 2022, I wrote a blog post explaining why I continue to choose Meteor for new projects, and that reasoning holds strong in 2025. Its strength lies in letting developers focus on business logic without wrestling with the “core components” every app needs—authentication, routing, bundling, deployment, and more.

A Pivotal Moment: Meteor 3.0 and the End of Fibers

Meteor 3.0’s removal of Fibers is a game-changer. Fibers shaped Meteor’s architecture and philosophy, but they also tied us to legacy components. With Fibers gone, we have a unique opportunity to modernize the framework’s core while preserving its essence. The challenge? Addressing the elephant in the room: scalability.

What Made Meteor Great?

Meteor’s magic came from its opinionated, “batteries-included” approach. You could start coding your idea immediately, with real-time capabilities baked in. Developers fell in love with the seamless real-time experience—until apps moved from local machines to production servers. The “magic” faded when scalability issues surfaced.

Real-time applications thrive today, and they scale. So why can’t Meteor? I believe the answer lies in technical debt and outdated implementations. Meteor 3.0 is our chance to return to the basics and reimagine how we’d achieve Meteor’s original goals in 2025.

Tackling Scalability: A Modern DDP

The first hurdle is scalability, and the legacy DDP (Distributed Data Protocol) implementation is a bottleneck. I’m working on a new ddp-server and ddp-client to replace Meteor’s outdated SockJS-based solution. Here’s my rationale:

• WebSockets/WebTransport: WebSockets are battle-tested for real-time apps, and WebTransport is on the horizon. Using a WebSocket emulator like SockJS no longer makes sense.
• CBOR over eJSON: CBOR is a lightweight, efficient message serialization format that reduces bandwidth compared to eJSON.
• TypeScript: Improves maintainability and developer experience.
• Redis: Redis has long been discussed as a solution to Meteor’s scalability woes. My implementation uses Redis to manage connections, enabling better horizontal scalability and potentially opening the door to serverless Meteor apps.

Try It Out

I’ve published an experimental package to test these ideas. Check it out and share your thoughts!

Starting the Server

1. Clone the ddp-server repo.
2. Install dependencies: npm install.
3. Run node ./tests/run.js to start the test server.

Starting the Client

1. Clone the ddp-client repo.
2. Install dependencies: npm install.
3. Start your Meteor app and watch real-time subscriptions in action.

Let’s Discuss

Meteor’s core goals—simplicity, real-time magic, and developer productivity—are as relevant today as ever. With modern tools like WebSockets, CBOR, TypeScript, and Redis, we can rebuild Meteor to scale without losing its soul. What do you think? How would you modernize Meteor in 2025?

My Meteor 2025 Goals

• ddp-server in 2025
• ddp-client in 2025
• ChangeStream Support

[pmogollon]

I like this Idea, i was thinking last year of doing something similar for my grapher-nova package to support real time data using redis, but you took it 10 steps further. Awesome.

There is an issue with sockets, and is that is not stateless as an http call. And most parts of an application don’t require a socket connection, only certain pages might require it.

Having both http and sockets options for data fetching will be also great for scalability.

Awesome PoC, I’ll give it a try this weekend.

[pmogollon]

I think another thing is that meteor doesn’t have a common pattern for caching DB queries. I know we can implement one ourselves, but having a caching system might help with giving a sense that meteor framework is built for scaling.

[jam]

First of all, I applaud your effort here and agree with many of your points. I’ve been thinking about your core question quite a bit as well. I think there are a couple other points to consider in tackling the scalability issue:

1. Meteor must get rid of oplog tailing.
2. I think managing subscription state should be reconsidered now that the landscape has shifted quite dramatically from when Meteor was first created. More thoughts on that here: Rethinking Meteor – managing subscription state

I think your proposed changes can be done completely under-the-hood so there are no changes to the current Meteor public APIs or at least that should be the goal imo.

Regarding your specific points:

@mvogt22

Using a WebSocket emulator like SockJS no longer makes sense.

100% agree. There was a GitHub discussion some time ago on making the move to something else.

@mvogt22

CBOR over eJSON

Interesting. I don’t know much about CBOR but benchmarks would be interesting to evaluate.

@mvogt22

TypeScript: Improves maintainability and developer experience.

Meh. I think Meteor should use JSDoc for all the same reasons that Svelte migrated from TS to JSDoc. Functions exported from Meteor core can and should still have all the same benefits of TS that you’re used to (typechecking, intellisense, inline documentation etc).

My position is, types are fantastic, TypeScript is a bit of a pain … as soon as you use a .ts file, then you have to have the tooling to support that … there’s all of these points of friction when you use a non-standard language like TypeScript that I have come to believe makes it not worth it. So instead, we have put all our types in JSDoc annotations, and we get all of the type safety, but none of the drawbacks, because it is just JavaScript, everything is in comments, you can just run the code. This is what we do in the Sveltekit codebase and it has worked out fantastically so for Svelte 4.0, we’re going to do the same for Svelte because it’s going to enable us to move much more quickly.
– Rich Harris

Let application developers use TS if they’d like. My other belief is that in time TS will phase out much like Coffeescript. I expect that JS will eventually adopt the types as comments proposal. We’ll see though.

@mvogt22

Redis has long been discussed as a solution to Meteor’s scalability woes

I think this is one possible solution and maybe a really good one. I think it’s also possibly worth exploring something similar to ElectricSQL – essentially a service that sits between your Meteor app and MongoDB and uses change streams. It could even be used as a caching layer so that MongoDB is hit relatively infrequently and be written in another language that is built for scalability and concurrency, e.g. Elixir. Perhaps this is similar to radekmie’s DDP Router but I’m not really sure since details were limited. My hypothesis is that jam:pub-sub could get most apps relatively far where they wouldn’t need to reach for either Redis or an Electric SQL equivalent, both of which bring in more complexity and I believe would only truly be needed at large scale.

[mvogt22]

@jam

Meh. I think Meteor should use JSDoc for all the same reasons that Svelte migrated from TS to JSDoc. Functions exported from Meteor core can and should still have all the same benefits of TS that you’re used to (typechecking, intellisense, inline documentation etc).

You know what, I actually agree with this take. I only used TypeScript for this module as it seems Meteor Core team has been favoring TypeScript for their new features.

Modern IDEs provide the same context with JSDoc as TypeScript. The only benefit is CI tests.

[radekmie]

@mvogt22

Using a WebSocket emulator like SockJS no longer makes sense.

You can already do that with DISABLE_SOCKJS env var. We do that for performance and bandwidth reasons. (However, I know that there are some projects where supporting pre-WebSocket browsers is still a thing.)

@mvogt22

CBOR over eJSON: CBOR is a lightweight, efficient message serialization format that reduces bandwidth compared to eJSON.

You could do that by overriding DDPCommon.parseDDP and DDPCommon.stringifyDDP.

@mvogt22

My implementation uses Redis to manage connections, enabling better horizontal scalability and potentially opening the door to serverless Meteor apps.

Can you explain how do you plan to do so? I checked the code, and I see that the active subscriptions are stored in Redis, but I couldn’t find any place actually making use of it (I guess it’d be here, but it’s not).

[harry97]

Lots of articles attempting to overhaul the Meteor system all at once chill guys!

Rethinking Meteor – managing subscription state

If Meteor were built from scratch today, would it still opt to keep all client subscription state on the server and use merge box to process diffs? When Meteor was created, relying on stateful servers for subscriptions was possibly the only solution that made sense, but this decision came with two serious tradeoffs: Limitations on scaling. There are two big factors that place limits on scaling Meteor — oplog tailing and merge box. Oplog tailing should be replaced with change streams, which h…

RFC: Modernizing Meteor creation of methods and publications

Hey! I’ve made this discussion on github, and I would love some thoughts from the community there! I plan to update the OP there as we go/I have more ideas but the foundation of my idea is there.

I’d like to cut up the changes you’re considering into two categories.

• WebSockets/WebTransport: WebSockets are battle-tested for real-time apps, and WebTransport is on the horizon. Using a WebSocket emulator like SockJS no longer makes sense.
• CBOR over eJSON: CBOR is a lightweight, efficient message serialization format that reduces bandwidth compared to eJSON.

These changes are pretty tame in my opinion and if done correctly shouldn’t impact the backwards compatibility. Convention-over-configuration is a must but also having sharp knives. Meteor should allow you to swap out the underlying websockets library; currently it’s hard-wired to sockjs. Though @radekmie’s comment makes it seem like it’s already possible??! I’m not sure.

• TypeScript: Improves maintainability and developer experience.
• Redis: Redis has long been discussed as a solution to Meteor’s scalability woes. My implementation uses Redis to manage connections, enabling better horizontal scalability and potentially opening the door to serverless Meteor apps.

This second part, I’m a bit on edge about due to @jam’s comments and other consideration. Since these changes would take definitely longer and are of a much greater size. I’m not putting them down but saying need a greater discussion while the first two things you suggested I think should be done already.

[ceigey]

I think some thing that set Meteor apart from frameworks like Next and Nuxt is that they are too focused on rendering React and Vue respectively. And things that set Meteor apart from stacks like T3 (see: https://create.t3.gg/) are:

• It’s actually a cohesive framework, not a stack
• Accounts and Roles (more critically) and other convenience packages hiding a lot of config complexity like Email (less critically)
• Writing apps looks mostly the same - major architectural changes have occurred (e.g. the removal of fibers, RIP the promise of JS coroutines (slides)), but apart from meticulously sprinkling some async/await across our codebases and some edge cases with reactivity in method stubs some have found, the logic’s largely the same.
• Hasn’t needed to compete on the bleeding edge. Of course there have been Coffeescript, fibers, Apollo GraphQL that side hustle from MDG, ES6-style imports in function bodies etc, but ultimately the community’s been around long enough to actually adapt and learn from that, which is hard to say when you look at other frameworks in the JS world.

The things that have made me consider moving from Meteor over time (and some resolutions to them) have been things like:

• Build system & build times (and deployment times, I’ve been spoilt by Vercel, I need instant gratification now dammit! )
  • I believe this is all being actively addressed, either adopting SWC (current) or looking into a future adoption of Vite (rumour or planned?)
  • Technically jorgenvatle:vite addresses this too, but some extra courage is required
• Incompatiblities with things like Node ESM exports (thanks Hono…)
  • Increasingly an issue, has to be solved with the build system, I believe that’s happening?
• Getting stuck on Vue 2 and and fourseven:scss during the Apple Silicon transition and just before Meteor 3
  • Vite addresses this
• the NPM-Atmosphere duality that’s resulted in workarounds like @meteor-vite/react-meteor-data
  • I guess this can be addressed by carefully reducing coupling between Meteor components?
• Sometimes too much tribal knowledge that seems tangential to the rest of the JS ecosystem
  • Replacing some of the community best practices that used to be in the old v1/v2 Meteor Guides in a Meteor v3 guide
• Hesitancy over Meteor’s pub-sub scalability and the operational complexity you have to undertake longer-term (e.g. redis oplog) vs just using REST (or pseudo-REST) APIs and something like TanStack
  • jam:pub-sub’s work with change streams and Method-based publishing essentially address this
• Serving API endpoints (you have to glue a few things together to make use of the excellent Accounts ecosystem)
  • We would have to address this with the Accounts and Webapp packages I guess otherwise everyone will do their own thing (see: tribal knowledge)
• I gotta admit, those hybrid incremental SSR rendering systems are very attractive

If I had to say goodbye to Meteor, and make my own stack, I’d be leaning towards…

• TanStack Start for a solid fullstack SPA+SSR basis?
• TanStack Query to functionally but not spiritually replace Minimongo and pub-sub
• BetterAuth (or start using Kinde, maybe)
• I would have said Turso for the database but they don’t support ap-southeast-2 while Atlas and Galaxy do, so… if not those, maybe Neon Postgres?
• React with Chakra-UI, or Solid with Ark UI (or Park UI)? Or their shadcn equivalents…
• And nodemailer etc.

But nothing is as quick to get up and running, and now instead of pointing someone to maybe 3x sites (Meteor, Frontend framework site, UI components site) to figure out how everything runs, it’s about 5, 6, 7 or so? It’s a lot of fragmented knowledge.

Or I’d just give up and go make an MPA with Adonis maybe…

Somewhat related: The doc site’s down at the moment, but @leonardoventurini was working on a Meteor-like fullstack RPC framework called Helene:

GitHub - leonardoventurini/helene: Real-time Web Apps for Node.js

That might be of interest if you want to explore a sort of “Meteor from scratch” approach to things not needing SockJS.

Edit: I forgot, a new buzzword for webdev is sync engines, which you can see on Hackernews (original article).

In the comments, you can see some references to Meteor, although perceptions towards it are a bit pessimistic.

But hey, maybe we can “revive” it just by releasing our own “sync engine”. Maybe we can take over an obscure Meteor package and rename it “syncengine”? /s

More seriously, one project that comes up is electric SQL, which looks like a possible Postgres equivalent to Meteor’s minimongo? But I just don’t see the same ease of use.

[mvogt22]

@radekmie

You can already do that with DISABLE_SOCKJS env var. We do that for performance and bandwidth reasons. (However, I know that there are some projects where supporting pre-WebSocket browsers is still a thing.)

I think at this point disabling SockJS for the client should be the default behavior.

@radekmie

You could do that by overriding DDPCommon.parseDDP and DDPCommon.stringifyDDP.

I was not aware of that. Could be as simple as implementing a package to override the DDPCommon methods if I am understanding what you’re saying.

I think more content or discussion on the underlying core of Meteor would be really helpful for community members such as myself who want to contribute to core packages.

I love seeing all the discussion around this. I think it is time to re-evaluate the “out-of-the-box” experience, especially to make it welcoming for new developers to the Meteor ecosystem. I don’t think they should have to dig through all the documentation and history of Meteor’s evolution to figure out which environment variables to set to achieve a “modern” implementation of Meteor.

@jam

My hypothesis is that jam:pub-sub could get most apps relatively far where they wouldn’t need to reach for either Redis or an Electric SQL equivalent, both of which bring in more complexity and I believe would only truly be needed at large scale.

I also think the work @jam is amazing.

[vikr00001]

@ceigey

Edit: I forgot, a new buzzword for webdev is sync engines, which you can see on Hackernews (original article).

There are forum threads about this:

X Thread Advocating for Sync Engines (a la Meteor Live Data)

Here’s a link that was featured in the Syntax newsletter today: Most apps should use a sync engine instead of doing RPC. It’s more clear to me now than ever before: This will become the new default for future app development. Gets rid of massive amounts of complexity and empowers frontend developers The OP defines sync engines like this later in the thread: An end-to-end system that syncs data directly into clients (often into a client-side database) instead of the client having to manu…

New Article Advocating for Sync Engines (a la Meteor Live Data)

Linked today on HackerNews: “Sync Engines are the Future” …getting data is a continuous process: data changes over time and becomes stale, requests fail, updates arrive later than you might’ve wanted, or out of order. Errors will happen. Occasional if (!response.ok) will not get you very far. fetch(new Request('/user/update', { method: 'POST' })).then((response) => { if (!response.ok) { // Do what? Pretend it never happened? // Stop the entire application? // Retry? What if user…

[a4xrbj1]

@jam

Meh. I think Meteor should use JSDoc for all the same reasons that Svelte migrated from TS to JSDoc. Functions exported from Meteor core can and should still have all the same benefits of TS that you’re used to (typechecking, intellisense, inline documentation etc).

Amen to that. Can’t agree more. JSDoc and check() is enough for us.

[storyteller]

@radekmie

You can already do that with DISABLE_SOCKJS env var. We do that for performance and bandwidth reasons.

Wait, so setting DISABLE_SOCKJS will lead to using native web sockets? Why is that not the default already for modern browser bundles?

@ceigey

BetterAuth (or start using Kinde, maybe)

This looks amazing, I think we really need to look closely at this and add a lot new features. We are starting to fall behind. First passkeys and then advance on other things. I think we should look closely on the organizations, my goal is to get as much as possible from Enterprise Ready to be out of the box in Meteor.

On the sync stuff, I have been hearing a bit lately about Apache Kafka, will have to look more deeply into that.

[ceigey]

@storyteller

my goal is to get as much as possible from Enterprise Ready to be out of the box in Meteor.

Oh nice, this will be a good complement to The Twelve-Factor App for me at work!

[radekmie]

@storyteller

Wait, so setting DISABLE_SOCKJS will lead to using native web sockets? Why is that not the default already for modern browser bundles?

SockJS uses the native WebSockets, don’t worry. But there’s some additional logic on top (e.g., fallback to XHR) and slightly different encoding (you can see something more than “just” JSON in the messages).

[jam]

It would be nice if sockjs wasn’t included in the client bundle when disabled. Related discussion: Reducing client bundle size · meteor/meteor · Discussion #13229 · GitHub

[storyteller]

@radekmie

SockJS uses the native WebSockets, don’t worry. But there’s some additional logic on top (e.g., fallback to XHR) and slightly different encoding (you can see something more than “just” JSON in the messages).

Is that extra stuff really needed today?

[radekmie]

Not really. I guess there may be some edge cases, but we’ve been running with DISABLE_SOCKJS in production for a long time now without issues.

[italojs]

I agree with many of the points raised here, but I’d like to bring a perspective focused on what has always been, to me, the core of Meteor: a real-time framework built with productivity in mind.

Meteor has never been just a reactive stack — its mission has always been to help developers get applications into production quickly, with minimal friction. That’s still incredibly valuable today, especially when validating ideas, launching MVPs, or enabling small teams to consistently deliver value.

That’s why I believe there are two pillars that need to evolve together if we’re imagining a “Meteor 2025”:

1. Real-time with a modern architecture

@pmogollon

There is an issue with sockets, and is that is not stateless as an http call. And most parts of an application don’t require a socket connection, only certain pages might require it.

Meteor is inherently a real-time fullstack framework. Shifting to an HTTP-only model might seem attractive for its simplicity, but it doesn’t make much sense in this context — unless we’re talking about long-polling, which is already a fallback approach. The ideal path remains WebSockets, or other persistent connection methods, backed by a well-managed back-end that scales simply and efficiently.

@jam

Meteor must get rid of oplog tailing.

More importantly, I believe it’s time to rethink the link between reactivity and the database. Meteor is still tightly coupled to MongoDB, using oplog tailing or change streams . But the real leap forward would be to make the framework agnostic about the data source — allowing real-time data to come from any place: queue system (zmq, Redis Streams, Kafka…), external APIs, or even internal application events(it opwn the dor for a new world for meteor) — without requiring that data to be stored in the database first.

This decoupling would make Meteor much more flexible for modern, event-driven architectures and apps that need reactivity without being bound to a specific persistence model.

1.1 DDP layer

@mvogt22

Redis: Redis has long been discussed as a solution to Meteor’s scalability woes. My implementation uses Redis to manage connections, enabling better horizontal scalability and potentially opening the door to serverless Meteor apps.

• Following the idea above, Redis won’t be a discussion anymore.
• The websocket improvements and CBOR over eJSON are great steps in the right direction for the modernization of the DDP layer.

2. Productivity through opinionated features

It’s not related to “creating Meteor from scratch,” as this thread’s main purpose suggests, but I think this is the right place to talk about it: Beyond the technical foundation, we can’t forget two things what has always set Meteor apart from other stacks: its opinionated philosophy aimed at fast delivery.

accounts-ui is a great example — it’s not just an authentication library, it’s a ready-made solution that can save days (sometimes weeks) of work. A modern version of Meteor should continue to invest in these kinds of tools: opinionated, well-integrated features that “just work” — such as component scaffolding, simplified deployment, and integrations with common APIs.

The goal is not to constrain developers, but to give them a solid starting point that allows them to go from zero to functional app in record time, without needing to make hundreds of low-level decisions. And still, provide the freedom to customize or replace those defaults as needed.

As Roles package, we could bring many others useful packages to the core.