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.
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.)
You could do that by overriding DDPCommon.parseDDP and DDPCommon.stringifyDDP.
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).
Lots of articles attempting to overhaul the Meteor system all at once 
chill guys!
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.
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:
Accounts and Roles (more critically) and other convenience packages hiding a lot of config complexity like Email (less critically)async/await across our codebases and some edge cases with reactivity in method stubs some have found, the logic’s largely the same.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…)
Vite addresses this the NPM-Atmosphere duality that’s resulted in workarounds like @meteor-vite/react-meteor-data
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 attractiveIf I had to say goodbye to Meteor, and make my own stack, I’d be leaning towards…
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:
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.
I think at this point disabling SockJS for the client should be the default behavior.
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.
I also think the work @jam is amazing.
There are forum threads about this:
Amen to that. Can’t agree more. JSDoc and check() is enough for us.
Wait, so setting DISABLE_SOCKJS will lead to using native web sockets? Why is that not the default already for modern browser bundles?
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.
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).
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
Is that extra stuff really needed today?
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.
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”:
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.
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.
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.
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.
The original tutorials and simplicity across the whole stack, including Blaze, made this more true then than it is now.
Yes! 
I would love for a new Meteor to
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).
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
Yes, I think that will be a major thing for better integration into modern client libraries.
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.
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.
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)