Big Changes at Meteor Software: Our Next Chapter

[fredmaiaarantes]

A New Era, A New Identity

First things first! We’re introducing fresh new brands for both Meteor and Galaxy.

Our new Meteor brand represents our commitment to modern JavaScript. The redesigned Meteor website is ready and includes a cool interactive demo showcasing what Meteor can do.

Meanwhile, Galaxy’s new independent brand shows it’s growing beyond its Meteor-only roots into a robust, multi-stack cloud platform.

Meteor 3: Embracing the Node.js Ecosystem

After countless nights, we released Meteor 3.0 in July 2024 (now we’re at version 3.2). This release wasn’t just another version bump. It shows where we want to go in the future.

These changes help Meteor work better with other Node.js tools. This is important because we can use the best tools in the JavaScript ecosystem instead of maintaining our solutions for everything.

What’s Coming in 2025

Our 2025 roadmap shows where we’re heading.

Bundle Optimization: Our Current Priority

• Working with modern bundlers: We’re making it easy to use RSPack, ESBuild, and/or Rollup
• Faster builds: With our new tools added in version 3.2 and 3.3 beta
• Better development experience: Making changes to your code will show up more quickly

Upcoming Improvements

• Modernized RPC Methods and Publications: Adding self-documenting code, better validation, and more intuitive interfaces while maintaining backward compatibility
• MongoDB Change Streams: Using the official way to get real-time updates from MongoDB
• Better TypeScript support: Making it easier to use TypeScript with Meteor and its packages
• CapacitorJS for mobile apps: A better, newer way to build mobile apps
• Faster releases: Making our process quicker so you get updates sooner

Galaxy Expands Its Universe

Galaxy is evolving beyond its role as a Meteor-only hosting platform. The platform now supports Node.js and Python applications, including frameworks such as Express, Nest, Adonis, Flask, and Django.

Our promise is simple but powerful: We’ll provide the most user-friendly cloud platform and the most responsive support team.

Complete Platform with Database Solutions

In 2024, we enhanced Galaxy by adding MongoDB. We’re continuing this evolution in 2025 by expanding our database offerings to include PostgreSQL (coming soon), Redis, and FerretDB.

Galaxy now operates as an independent platform with its own dedicated website and distinct brand identity separate from Meteor.

Try It Today

I encourage you to upgrade to Meteor 3. You’ll feel the benefits of native async/await and modern Node.js features. Meteor 3.3, which is currently in beta, already brings faster builds.

For those working with Node.js, Python, and their popular frameworks, consider exploring Galaxy. Visit our new Galaxy website.

On our blog, you can read the full article.

[ceigey]

Looks great! Exciting to see the many changes to Meteor and Galaxy.

I had a question regarding bundling since I’m not 100% sure what direction that’s headed in (other than performance improvements) - are there any plans or ideas to officially support vite, or would that be left to the community for the meantime?

A lot of tooling, frameworks or libraries seem to assume we should be using vite by default, which isn’t the first time this has happened (Webpack used to enjoy this status after all) but it does mean for me that I will see myself using vite for the considerable future of my Meteor apps’ development.

But I can also imagine there’d be concerns on making vite the core bundler for Meteor, especially if it somehow experienced a major breaking version during the adoption of rolldown or something.

[jam]

Nice! Looking forward to all the upcoming improvements.

Also seeing jam:easy-schema on the meteor homepage is surreal and very cool. Thanks y’all!

[permb]

Can someone please share some details on the whole bundler story?

The meteor bundler and runtime is currently totally dependent on the little-understood “reify” package which violently repackages every single js file including those in npm packages into what becomes the .meteor/local/build/programs/server/app/app.js file for an app.

It is crucial for supporting top level await and meteor’s dynamic import, and maybe also HMR?

Is the plan to totally ditch reify since it can be considered a dead end built and understood only by long-gone engineers even if it works well today? Or is the plan to make reify support esm, tree-shaking and other long-awaited features?

If it is to be replaced, will we lose dynamic import (please no) and the deprecated block-level import (good riddance IMO)?

I haven’t seen any details so far so I am very curious to hear what the plan is - maybe I can even help out?

[nachocodoner]

Rather than focusing on specific tools, I prefer to talk about goals and how they benefit the Meteor ecosystem. Our priorities are:

• Faster rebuild times during development
• Preserving Meteor developer experience, including HMR
• Balancing bundler performance and features

We’ve tested several modern bundlers and learned about integration with Meteor’s rigid bundler. So far, some offer speed gains but struggle with full HMR, while others deliver developer experience features but miss performance targets.

We’re exploring multi-dev-server and HMR setups, testing middleware to combine strengths. These experiments focus on linking tools instead of rebuilding bundler features, which would add maintenance overhead for our community and future teams.

Regarding Vite, we experiment with it frequently due to its popularity. While it may not be the fastest when integrated with Meteor so far, it’s sometimes preferred by the community. The Meteor community already maintain meteor-vite, which combines dev server and HMR. We’re studying its setup to inspire the bundler integration.

We remain in an experimental phase and avoid setting specific tool expectations until we have a solution that meets all our priorities. We also like the new integration as flexible as possible, allowing easy adaptation to other bundlers at any time. We plan to open experimental PRs, as we did with SWC, to share our progress.

[nachocodoner]

We aim to keep Meteor’s core features while always offering a modern setup path. We don’t want Meteor projects blocked by updates, nor do we want to lag behind JS standards, popular tools and the wider ecosystem.

That’s why our approach to updating Meteor’s bundler is modern-first. Since we’ve recently experimented with SWC integration, here’s how it works:

1. Measure goals

• Automate issue detection so we quickly see if we meet our standards later.
• In Meteor 3.2 we added meteor profile for build-time and bundle-size checks and also tried CPU profiling.

2. Try modern tools

• Dedicate time to integrate existing, popular solutions rather than rewrite everything ourselves.
• In Meteor 3.3 we began swapping Babel for SWC to remove our biggest build slowdowns.

3. Validate results

• Rerun our measurements to check against standards.
• In Meteor 3.3, early tests showed SWC cutting build times significantly, so the process could continue.

4. Handle regressions and compatibility

• Address any Meteor-specific limitations in the integrated tool and offer flexible workarounds when possible. If a workaround isn’t feasible, hide the feature behind a configuration option. Leave more complex fixes open for us or the community to tackle later.
• In Meteor 3.3 we found that top-level await and HMR were broken initially. We preserved reify for solving those, since that was an easy fix. We couldn’t keep nested imports, because these aren’t standards for modern syntax tools, so we need an SWC plugin to parse import statements inside blocks; don’t confuse nested imports with standard dynamic imports, which SWC still supports its syntax.
  We also added configuration options to opt out of SWC transpilation and minification, and a fallback to Babel for backwards compatibility.

We stay in this process because re-implementing features modern tools already cover can stall our PR indefinitely and drain our motivation, community tools already solve these problems and maintain solutions over time.

Refer to the previous answer for the current status of the Moder Bundler solution integration.

Back to your question, we can’t yet specify exactly what will be preserved or discarded in a modern setup or package. We will continually develop opt-in/out options so each project can mix old and new as needed. The modern bundler will likely handle only your app code, with configurable exceptions, and Meteor-specific features will remain in Atmosphere packages. This still depends on what the experimentation phase shows us. If we can preserve features in modern setup, we will, just as we did with SWC, or we’ll find alternatives. Meteor 3.3 also focused on Meteor-specific optimizations. We could have started with a modern bundler integration, but we chose to improve existing projects and support those who prefer the Meteor bundler strictly. Modern bundler integration will also benefit from these optimizations.

We don’t plan to work on Reify unless we have time, know how, and once a modern component is integrated first. Standard JS features like dynamic imports will be supported, perhaps not exactly as Meteor does, but your project should notice no difference except that DDP won’t run behind the scenes. Preserving nested imports is harder, anyone can help add support in SWC. Meteor 3.3 detects nested imports automatically in your code using verbose mode so you can adopt standards easily if you prefer. We haven’t added a breaking change to your project but provided a Babel fallback so you can still benefit from improvements. This is our way forward with modern bundler integration as well.

[ceigey]

Thank you @nachocodoner for the response, I can see it’s a tricky thing to answer at this stage. In any case I look forward to the evolution of Meteor!

[harry97]

You deserve every bit of support. Also kudos to the meteor team. The new design is amazing. I really liked the chat demo with the code files

[vikr00001]

The new websites for Galaxy and Meteor look great - modern and polished.

[jkuester]

Actually, the whole reify integration was one of the greater blockers when I tried to understand the babel pipeline in Meteor.

[alimgafar]

I always thought that the three people working on MeteorJS that understood reify well were Ben Newman, Filipe Nevola, and Renan Castro. If reify is still being used this Fall, maybe we can get one of them to explain at Meteor Impact.

[harry97]

I’d really love that. Maybe @zodern or @nachocodoner can step up.