What if Meteor Was Created in 2025?

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

[trusktr]

@italojs

Meteor has never been just a reactive stack

Its core Blaze has been alienated, and not replaced. React is far removed from Meteor’s original signals and effects paradigm, and not a suitable replacement.

@italojs

opinionated philosophy aimed at fast delivery.

The original tutorials and simplicity across the whole stack, including Blaze, made this more true then than it is now.

@italojs

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”

Yes!

I would love for a new Meteor to

• have an updated Signals (Tracker) API that catches up with all the work modern signals libs have done, aligned with TC39 Signals (maybe rename Tracker to Signals or similar)
• have a future forward UI layer that is aligned with web standards, built on custom elements and signals, with type checking and intellisense for all optional frameworks, using vanilla CSS and ShadowDOM,
• and a primary tutorial built with this new setup, with the React tutorial deprioritized to the bottom of the tutorial list, and Tailwind removed from tutorials, so that beginners will have a clear path to the best way to stay organized and have well-working apps.

The other stuff is only optimizations mostly. Like if sockjs can be removed, and DDP optimized, great, but those aren’t fundamental changes to the UX and DX of Meteor.

We want something that has a clear story like the early days (optimization as a nice bonus).

[harry97]

@italojs

Meteor has never been just a reactive stack

Like how did you come to that conclusion??

[italojs]

@harry97

Like how did you come to that conclusion??

what I meant is that Meteor is not just about reactivity. If it were only focused on that, we’d probably be talking mostly about backend concerns.

The truth is, Meteor has evolved into something much broader: it’s a productivity framework. It gives developers the tools to ship production-ready applications incredibly fast, and that’s one of its strongest value propositions today.

That’s why I think this discussion shouldn’t be purely technical. We also need to focus on product-level features like the suggestion I made about integrating curated community packages. These kinds of features are what make Meteor so approachable and practical, especially for teams that want to move quickly without sacrificing maintainability.

So yes, Meteor core is the reactivity since from day one but Meteor’s real power go beyond reactivity

[storyteller]

@trusktr

aligned with TC39 Signals

Yes, I think that will be a major thing for better integration into modern client libraries.

@trusktr

React is far removed from Meteor’s original signals and effects paradigm, and not a suitable replacement.

This is an issue that I’m running into a lot lately. I want to switch to Solid works better with Tracker, but the ecosystem doesn’t have the necessary things that I need (though I will probably have to switch to universe:i18n after some improvements and then I should be able to handle the rest).

On another note, another thing to keep in mind that I think we will need to upgrade at some time is minimongo.

[italojs]

@storyteller

On another note, another thing to keep in mind that I think we will need to upgrade at some time is minimongo.

Interesting point @storyteller. Why do you think we should upgrade Minimongo? Do you have any alternatives?
I believe we need to modify Minimongo to potentially support SQL databases like Postgres in the future or to make it database-agnostic.

[grubba]

@italojs

Why do you think we should upgrade Minimongo? Do you have any alternatives?

I personally, have never updated/seen our minimongo be updated(in the upgrade sense of the word).

We could make some effort to update it to be close to this minimongo—which I do not recall the history behind. Maybe @storyteller can enlighten us here on why we do not use it as an npm dependency.

Or we could try updating it to be more agnostic – supporting other dbs(SQL and Redis for example)

[storyteller]

@grubba

I personally, have never updated/seen our minimongo be updated(in the upgrade sense of the word).

Exactly, that is the problem. Minimongo hasn’t been touched in years. If we want to add any new Mongo functionality then it needs to be added to Minimongo as well. Not to mention new functionality offline, etc.
Given our current situation it might be too much to maintain so maybe switching up with the already mentioned minimongo or some other solution. This is for a more detailed solution and investigation, but it is something to keep in mind.

[awatson1978]

@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.)

Yes, exactly. DDP has been a websockets implementation for the past 10 years. It’s got some fallback support for pre-WebSocket browsers; but it’s websockets by default. Use DISABLE_SOCKJS if you don’t want the extra overhead of legacy browser support.

@mvogt22

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

Yes, seems an obvious inclusion.

@jam

Meteor must get rid of oplog tailing.

Having a unified JSON architecture from database to client is a major reason that Meteor is reactive and developers are productive. It’s not just oplog tailing… minimongo is a client-side replica set partition.

@a4xrbj1

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

JSDoc, sure. Swagger and OpenAPI should also be in core by default.

@italojs

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.

NodeOnFHIR has spent at least 5 years now, adding in an Express.js server and full support for both HTTP and DDP. It’s a great combination. HTTP allows external systems to write into the MongoDB with a well documented API. Once in the MongoDB, the replica set synchronizes with minimongo as a client-side replica set via websockets/DDP; and react auto renders. It’s beautiful, and solves all our problems with an elegant design.

@italojs

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.

Read this again: It’s not just oplog tailing and having a Mongo backend… minimongo acts as a client-side replica set partition . There have been experiments with having mini-sql in the browser; and it fails because it’s not native JSON. Instead of a collection of JSON objects on the server synchronizing with a collection of JSON objects on the client; you have a rubiks-cube of tables on the server synchronizing with a rubiks-cube of tables on the client. Uggg^n

You could maybe get some of the same success synchronizing minimongo with Postgres JSON columns; but Postgres doesn’t have half of the sorting/filtering/querying on the JSON column that Mongo has.

Think in terms of JSON from the client to the server to the database. Think in terms of synchronized V8/SpiderMonkey instances. If you’re trying to swap out the backend for something that’s not V8/SpiderMonkey and isn’t JSON native, you’re going to have troubles.

@trusktr

Its core Blaze has been alienated, and not replaced. React is far removed from Meteor’s original signals and effects paradigm, and not a suitable replacement.

This makes no sense to me. React has been more performant and productive across the board, due to re-usability and composability. Would never look back. Contrary to some misconceptions, React does export to ES6. And importantly, has the largest libraries of UI components; and the LLMs are well trained on it.

That being said, the magic happens with Functional Components (methods), not classic React Components (objects). It’s a classic object-oriented programming vs functional programming mismatch. Yeah, the life cycle on React Components is basically a mismatch for Meteor; but once a project converts to Functional Components, it’s functional programming from the server to the front-end UI, and it’s a thing of beauty.

@storyteller

Exactly, that is the problem. Minimongo hasn’t been touched in years. If we want to add any new Mongo functionality then it needs to be added to Minimongo as well. Not to mention new functionality offline, etc.
Given our current situation it might be too much to maintain so maybe switching up with the already mentioned minimongo or some other solution. This is for a more detailed solution and investigation, but it is something to keep in mind.

Mongo+DDP+minimongo is the crown jewel of the entire framework. Client-side replica sets for the win.

[awatson1978]

All the above being said, the most obvious 2025 hotness hasn’t been mentioned yet: Model Context Protocol (MCP) Server needs to go into core.

Model Context Protocol - Model Context Protocol

[jam]

@awatson1978

Having a unified JSON architecture from database to client is a major reason that Meteor is reactive and developers are productive. It’s not just oplog tailing… minimongo is a client-side replica set partition.

I agree with what you’re saying but I’m not sure how it relates to my statement of Meteor needing to ditch oplog tailing. Minimongo is a gem but is orthogonal to oplog tailing.

Reactivity can / should be preserved with an official, mongo-supported approach, e.g. change streams, and in a way that doesn’t preclude scaling horizontally.

Oplog tailing was originally a hack introduced long ago that mongo never officially support. It lived on because the MDG team got distracted by enterprise and graphql, after which there hasn’t been anyone on the core team dedicated to providing an alternative solution.

@trusktr

React is far removed from Meteor’s original signals and effects paradigm, and not a suitable replacement.

Fwiw, I agree. React is a legacy solution that doesn’t succeed based on technical merit but rather inertia. Sure you can make it work with Meteor but it isn’t an optimal pair.