What if Meteor Was Created in 2025?

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