Meteor Phoenix: Rising from the Ashes to Spark New Developer Passion

community
1

I’ve been an avid Meteor user since its inception, and it’s no exaggeration to say Meteor has helped me build my businesses (like BlueHive and Ozwell.ai). For over a decade, I’ve also relied on it exclusively for personal projects. Needless to say, Meteor holds a special place in my dev-heart!

Meteor has evolved significantly, experiencing both growth and periods of uncertainty. As an organization, we’ve always encouraged our new interns and developers to dive into Meteor. But with the recent Meteor 3.0 release, we’ve noticed an uptick in confusion due to outdated docs, broken links, and general misinformation online.

Just recently, an intern asked: “Why push Meteor so hard? Everywhere I’m searching says people have left and it sucks…” Ouch!

Sadly, there’s truth to that experience. Common issues driving devs away from Meteor include:

  • Scaling & Performance Issues: Meteor’s default real‐time data sync (DDP + pub/sub) can strain apps at scale. Everything is realtime by default, which is overkill for many apps and makes scaling to many users difficult without careful optimization (Ask HN: Is Meteor.js dead? | Hacker News) (Ask HN: Is Meteor.js dead? | Hacker News). One developer noted Meteor “doesn’t scale well… great for proof-of-concept, but painful to scale,” due to DDP’s resource-heavy design (e.g. caching every client’s data) (Ask HN: Is Meteor.js dead? | Hacker News) (Ask HN: Is Meteor.js dead? | Hacker News). This led some early heavy users (e.g. community figure Arunoda) to move on, as Meteor was seen as hard to optimize for high concurrency.

  • Slow Build Times: As projects grow, Meteor’s rebuild times can become frustratingly slow. Developers have reported multi-minute rebuilds, which hurts productivity. In fact, Meteor maintainers acknowledged that “many people do complain about the build times and have stopped using Meteor because of this.” (Faster builds/rebuilds for development and production :zap: · meteor meteor · Discussion #11587 · GitHub) Long reload times (20–30+ seconds) disrupt development flow, especially compared to newer toolchains. Improving build performance is seen as crucial to winning back developers (Faster builds/rebuilds for development and production :zap: · meteor meteor · Discussion #11587 · GitHub).

  • Monolithic, “All-In” Architecture: Meteor has historically required going “all-in” on its stack (MongoDB, its build system, its realtime layer, etc.). This benefited rapid prototyping, but felt too inflexible for large projects. Developers worried that Meteor was “really monolithic” (The State of Meteor Part 1: What Went Wrong | Hacker News) – for example, swapping out parts was non-trivial. Early Meteor tied you to MongoDB; one commenter noted “with Meteor, it’s Mongo or nothing,” which deterred those who preferred SQL databases (The State of Meteor Part 1: What Went Wrong | Hacker News) (The State of Meteor Part 1: What Went Wrong | Hacker News). Before official SQL support, this hard MongoDB dependency was a deal-breaker for many, causing them to choose other solutions (The State of Meteor Part 1: What Went Wrong | Hacker News). Similarly, front-end was initially tied to Blaze (later alleviated by React/Vue integration). This tight coupling made some developers feel locked-in and wary of Meteor for long-term projects.

  • Complexity Beyond the Basics: Meteor is famously easy to get started with, but developers often hit a “learning cliff” as their app grows. Features like custom routing, fine-grained pub/sub management, pagination, server-side rendering, or handling complex data relations revealed steep complexity (Is React the Future of Meteor? - InfoQ). As one team put it, managing subscriptions and caching in Meteor took far more effort than expected, and “near the end of the project we realized none of us actually had a total mastery of what was going on under the hood…which was a terrifying realization.” (Is React the Future of Meteor? - InfoQ) In other words, Meteor’s magic can become a black box, making debugging and advanced use cases difficult without deep framework knowledge.

  • Stagnation and Community Concerns: Around 2016–2018, Meteor’s momentum seemed to falter, leading to a perception that it was “dying”. The core team (MDG) shifted focus to Apollo/GraphQL, leaving Meteor’s roadmap unclear. Users noticed key Meteor engineers and community leaders leaving and fewer updates. One long-time user returning in 2020 said “Meteor felt abandoned…the client side story was split (React vs Blaze), a bunch of the team moved on to Apollo, [and] all sorts of new frameworks…were getting popular.” (Why not Meteor in 2020? - Planet Earth - Meteor Forum) Missing modern essentials (like official service worker/PWA support) added to the feeling that Meteor was lagging (Why not Meteor in 2020? - Planet Earth - Meteor Forum). This uncertainty (fear Meteor might be deprecated) caused some to jump to more actively maintained stacks, despite fond memories of Meteor’s productivity. As a forum member noted, the lack of communication from MDG became “a constant source of FUD in the community.” (Some Exciting Meteor News - #79 by vlasky - announce - Meteor Forum)

  • Ecosystem & Tooling Gaps: In its early years, Meteor had a walled-garden ecosystem (Atmosphere packages, no npm support until Meteor 1.3). This meant popular npm libraries weren’t directly usable, which frustrated developers. Testing was another pain point: Meteor lacked good testing tooling for a long time, making it hard to adopt in enterprise scenarios. Some also critiqued Meteor’s use of global namespace and magic file loading, which could lead to tightly coupled code and difficulty modularizing (Is React the Future of Meteor? - InfoQ). While many of these issues improved over time (npm support, modules, etc.), the initial shortcomings left a negative impression on some developers.

Yet, despite these challenges, I still believe Meteor is one of the most powerful, productive, and delightful ways to build web apps—and I wouldn’t build without it. Also, many of these challenges either don’t exist, or have been improved in recent builds.

However, there’s still room for improvement. Two areas I’d love to see more focus on are:

1. Better Mobile & Desktop App Distribution:

One of the primary factors that drove me to develop in meteor is that it “works everywhere.” I was able to write my code ONCE and could deploy to web, desktop, and mobile without too much extra effort.

  • Mobile: Cordova has always been troublesome—any update or pause (like not working on an app for a few months…) usually breaks the build. Capacitor might be a modern alternative worth serious consideration. It has better maintenance, improved plugins, and easier workflows, making mobile app builds much less painful. Meteor’s roadmap already acknowledges potential Capacitor integration. I personally have not messed with Capacitor.

  • Desktop: Meteor-Desktop offers Electron-based builds but needs updating to catch up with modern Electron versions. Alternatively, exploring Capacitor’s Electron support or DIY Electron approaches might help keep Meteor relevant for desktop app distribution.

2. Versioning and Naming:

Numbers alone don’t tell the full story or generate excitement. Why not adopt a catchy naming strategy like Apple’s macOS big cats, Android’s dessert names, Ubuntu’s animal names, or WordPress’s jazz musicians?

Instead of “Meteor 3.0,” why not Meteor Phoenix - symbolizing Meteor’s powerful rebirth and resurgence. (just an example!)? Developers could easily Google “Meteor Phoenix Tutorial” or “Meteor Phoenix react tutorial.” It provides memorable, SEO-friendly identifiers that clearly communicate the excitement and evolution around new Meteor releases.

Main Series (Meteor 3.x):

  • Meteor Phoenix – symbolizing Meteor’s powerful rebirth and resurgence.

  • Meteor Comet – swift, powerful, leaving a lasting impact.

  • Meteor Aurora – highlighting the framework’s brightness and fresh appeal.

  • Meteor Nova – signifying explosive new features and major advancements.

  • Meteor Zenith – representing Meteor reaching a new peak of excellence.

  • 3.1 “Meteor Nebula” – emphasizing a foundation of new improvements and the “birthplace” of innovation.

  • 3.2 “Meteor Pulsar” – signifying performance improvements, reliability, and regular, rhythmic enhancements.

  • 3.3 “Meteor Eclipse” – focusing on major changes overshadowing past challenges.

  • 3.4 “Meteor Orbit” – highlighting stability, consistency, and smooth developer experience.

  • 3.5 “Meteor Gravity” – emphasizing simplicity and ease of use, pulling developers naturally toward the ecosystem.

This thematic approach is memorable, engaging, SEO-friendly, and clearly communicates the excitement and growth in Meteor’s development journey.

We could also actively work on clearing outdated or confusing documentation:

  • Audit old Stack Overflow posts and indicate clearly if issues were resolved in the latest Meteor release.
  • Use Google Search Console to de-prioritize or remove outdated docs from search results.
  • Consider server-side redirects on docs.meteor.com to guide visitors clearly to current documentation.

The goal is to give new developers an excellent first experience. If we solve their early confusion and show them how amazing modern Meteor is, they’ll likely become lifelong fans like myself.

What do you all think? I’d love community input and suggestions on how we can tackle these ideas and further support Meteor’s growth. Let’s help Meteor shine again!

-Will

p.s. Had AI help write some of this. I had little time to prepare but wanted to get this out to the world before heading to a work event next week. check out this ChatGPT 4.5 research on meteor… there is some gold hidden in there…

9 Likes
2

Hi @wreiske, nice to see you around! A lot to cover in this post, so I’ll share my thoughts as I read through it.

Bad experience:

  • Scaling & Performance Issues - yes, over the years this has been addressed with Apollo and recently with the amazing packages from @jam. General improvements are on the roadmap (moving from oplog to changestreams, etc.), but things will take a while.
  • Slow Build Times - current focus of the core team for the upcoming and next feature release. Most likely Meteor will move to Vite. Not much the team will be able to do on that front after all this is done.
  • Monolithic, “All-In” Architecture - can also be a benefit. If we make everything interchangeable you make the maintenance impossible and loose any point of Meteor. The more I look back the more I feel that allowing to more and more stuff into the platform was a mistake. It increased the maintenance costs and instead of more interest people just left. Maybe Meteor wasn’t as fast for opening for their liking? But in all that opening we lost a lot of the magic like with Blaze UI. Also lot of the people who screamed about lock-in happily went over to other locked-in frameworks, which makes me think that for most cases it was just a bad selection of technology to solve their problem. :person_shrugging: I think the main problem here was the team moving on to Apollo so we never got any resolutions (though in a way Apollo GraphQL was suppose to be the solution to the data layer).
    The monolithic approach could potentially also help with performance as the core team could be hyper-focused on just one solution instead of having to cater to multiple options.
  • Complexity Beyond the Basics - Yes
  • Stagnation and Community Concerns - Yes, though that has improved significantly lately. Still a long cry from the golden years, but this is limited with the size of the community. I’m doing my part.
  • Ecosystem & Tooling Gaps - Yes, this has been mostly addressed. Still need to deprecate and remove the old confusing ways (which will also make the tooling a bit easier to maintain). Testing I find still confusing and needs a better story and official integration.

Better Mobile & Desktop App Distribution

Yes, most of that is on the roadmap. The core team is small, compare to the golden years, so it will take a bit to get there.
I believe the team is in contact with the Capacitor team (or the other alternative) and they have official integration with Meteor on their roadmap, but they have similar resource constraints.

Versioning and Naming

I think @alimgafar might have a feedback on the marketing aspect of it. I’m fine with the version numbers, but I’m deep in the code and releases so I know I’m the exception to knowing what is going on. If anything I think the names should be reserved for major release lines. Right now there is a small push to make sure that everything Meteor 3+ is labeled as MeteorJS, to have SEO differentiation from the previous versions.
I like the idea of the StackOverflow audit.
I think we also need to update Meteor Academy and I would love to have some time to re-build Discover Meteor (but right now I don’t know if I will have enough money for groceries next month). Would people be interested in paying subscription for weekly updates and advance tutorials?

Will check out the paper next. Thank you for your feedback @wreiske, I think there we need some hard talk on the monolith issue and to make a hard decision and stick with it.

3 Likes
3

I could tell lol.

1 Like
4

Hey @wreiske, thank you for sharing this! I think @storyteller already said everything I was going to say as I read your post.

I really like your ideas related to outdated/confusing documentation! We are already updating a lot of stuff, but it needs to be better (especially for newcomers).

1 Like
5

I still love Meteor after all these days. Never found anything that could match its capabilities. One thing to improve would be: Cleanup the existing Meteor packages on Atmosphere / Packosphere. I think one of the reasons folks think Meteor has been abandoned is the poor quality and lacking updates (sometimes for many years) of many of these packages. It would be better to massively promote the Community packages instead. I would also remove any packages that do not have a Git link. It’s hard to fork them if you don’t know where the source code lives.

3 Likes
6

That would be amazing. But how would you keep compatibility with mobile apps then?

7

Especially when that “new stuff” wasn’t even ready yet. Meteor is still suffering from Geoff’s post where he abandoned Blaze in favor of React. Having said this, allowing some flexibility is a must these days, and I won’t want to miss React. Never went back to Blaze, tbh, although I loved its simplicity when I got into Meteor for the first time.

2 Likes
8

Not only this. They moved on, but dropped Meteor in a way that they did not even provide proper Apollo support for it. The only last man standing was Ben. Who did a great job, but one single guy was not enough.

1 Like
9

Thanks for this, man. Highly appreciated.

1 Like
10

The more things change in React towards Next the more I agree with this sentiment. While I also would stay on React at this point (though I want to migrate to Solid as it plays nicer with Meteor’s reactivity), if more resources were put into Blaze to advance it then it might have been different. Today I’m not sure how to best approach it. Things I have discussed with people would be to build something on top that would have this united approach. As a first step I’m trying to update Mantra, still work in progress, but I think it can become the first piece once I figure out a few more things.

I was the one who made the upgrade of the Apollo package to support the latest version. I don’t think the official Apollo package is now even mentioned on their website anymore (they link to swydo’s package) and there are no official docs compare to other integrations. Sad :smiling_face_with_tear:.

3 Likes
11

Thank you for upgrading Apollo package.
In this page: Apollo Server Integrations - Apollo GraphQL Docs, they said you can submit an Apollo Server integration. If you can submit one, that would be great.
I’m still using apollo server v3 at this moment, but I will update v4 soon.

12

Here is the PR:

2 Likes
13

Definitely some interesting thoughts. Thanks for sharing. I’ll summarize into 3 main points and give you my take on each:

  1. Why Meteor lost its momentum
  2. The write once, run everywhere dream
  3. Version naming / branding

Why Meteor lost its momentum

I think the biggest reason was the “it can’t scale” refrain. With regard to realtime – a core differentiating feature and its primary initial draw – the naysayers aren’t wrong, this is still true. Otherwise it’ll scale just like any other Node app.

Out of the box, realtime will run into problems with low-to-mid thousands of concurrent users (possibly even less). Sure there are ways to increase the number of concurrent users, but historically it’s meant

  1. bringing in something like redis-oplog which lacks someone dedicated to improving / maintaining it
  2. give up realtime all together by switching to fetching via Meteor.methods which brings a host of other issues to solve

Neither of which are very satisfying answers and both dilute Meteor’s realtime promise. Meteor needs a core-maintained solution here. I hope that all or some ideas from jam:pub-sub make their way into core. For many apps, they may be all that is needed to scale beyond the current limitations. For the small percentage of apps that require the highest levels of scale or have complex publication requirements, it’s likely a different solution will be required (unless Mongo removes some of its current limitations on change streams) – perhaps something along the lines of a service like ElectricSQL that sits between your app and mongodb (it could even be built with Elixir).

Can Meteor scale to millions of real-time users someday? Hard to say but the vast majority of web apps don’t come close to requiring that. My belief is that a better solution could 10 - 100x the current limitation on number of concurrent users, making it suitable for a wide range of apps – possibly something on the order of 90%+ of apps. One thing I am certain of: oplog tailing must go.

If Meteor had a better realtime scaling story, it would be much more sought after, especially with the current trend of syncing over fetching and collaborative, local-first apps. Meteor is poised to be a go-to solution here when an authoritative server is needed (which is basically all B2B apps and non personal-use apps).

Beyond realtime scaling issues, my sense is that there was a lot of confusion back in the day sparked by the move away from Blaze and the focus switch from DDP to Apollo graphql — that pushed people away at the time. These days, allowing people to bring their own frontend framework is a strength. And funnily enough we’ve seen the shift away from graphql to rpc as people have come to realize graphql is unnecessary for most apps and teams and the simplicity of rpc is wonderful.

I also think the proprietary bundler, which was amazing at the time but now few understand the inner workings of, has hindered Meteor. The move to Vite will be a big benefit — it’ll make integration with any frontend easier, bring tree shaking (finally), and I assume allow for using things like vittest which should help a bit with the testing story.

Lastly, it would have been miraculous if Meteor sustained its early momentum. The fact that it’s still used and loved by many is a testament to it, especially in the world of JS frameworks which pop up every year and then fade away.

I still believe Meteor is the most productive JS framework and would love to see it double down on its strengths and unique capabilities.

The write once, run everywhere dream

As you’ve said, this is another compelling and unique feature of Meteor. Unfortunately Cordova has gone down hill but there are replacement options. Capacitor could fit the bill. There’s also Tauri, which seems very promising. As I understand it, the Meteor core team is investigating both of these so hopefully there will be a better solution in the near-ish future. For apps that don’t need access to specific mobile OS APIs, PWAs have come a long way.

Version naming / branding

Generally I like this idea. Could be fun if the frequency is right. (But definitely not anything with “Phoenix”, that’ll lead to confusion with the Elixir framework :slight_smile: )

Major releases 3, 4, 5 etc. make sense for this kind of thing. The only issue is, at least traditionally, these have been far and few between for Meteor. From a backwards compatibility story, that is amazing. From a marketing standpoint, not so great.

IMO, Meteor could benefit from the Apple-style major yearly release (even if it remains backward compatible) mainly for marketing buzz. It’d also be cool to see it coupled with a conference, ideally in person and streamed live.

I think, to fulfill its true potential, Meteor needs to figure out how to fund big improvements (or get a new capital infusion from a white knight / benefactor :slight_smile: ). Imagine a lean, mean completely modernized Meteor to take advantage of the current state of JS with a sync engine that “just worked” and could scale. It would be truly glorious.

I have more thoughts but this is getting long in the tooth. If you made it this far, I commend and appreciate you for reading.

12 Likes
14

Life’s gotten pretty rough for me lately, but I promise, if none does it, I will eventually do a Nats Jetstream + KV Pub/Sub and it will get much better. Literally difference between “toy” and “could use in production and get approval” in my eyes.

I basically grown up with Meteor, but I’m Highload engineer. Years ago, implementing React support when there was none, implementing SSR when there was none, NPM when there was none, SSL-HTTP2, etc, it was all worth it and not exactly complicated, especially since community was very active and helped with new ideas and implementations.

I know dozens of ways to overcome any issue in Meteor besides performance and stability. So idk, I’ve seen many features in latest versions implemented or planned for benefit of newbies that dont know how to setup a REST-API server and stuff like that. I feel for them, but its not one of things that hinder Meteor rebirth.

I remember myself wanting stuff like writing API requests in Meteor codebase. But I think we all grew up, - Its ok to have multiple containers for different things. Its ok to tinker around to get new feature like package-manager, encryption, etc. We just have to love and rely on thing that we tinker for.

I feel that for Meteor to be reborn, we must take on most important thing, - real time stuff. And just imagine how Meteor’s paradigm fits into LLM/Generative AI stuff. We could be “THE ONE” framework that solves collab- and time-constrained generation.

Sorry again, I really appreciate everything Meteor team does

3 Likes
15

A lot of the input is actually based on an underlying issue: Leadership. Currently the strategy seems to be a thing like “not enough capacity”, “talking with capacitor”, “who knows what will happen with react”, etc.

In the same line more voices from the team are added in roles like developer evangelist/communicator and so on. Also developers communicate (great!!) about the pieces they are involved in.

But there is no Bold statement.

What is Meteor?

Announcement of Meteor 1.0

Meteor is an open source platform for building modern web and mobile apps in pure JavaScript. These apps have live-updating interfaces that let people see information and collaborate with each other in real time, have subtle but essential touches like dialog boxes and popups that feel more like desktop apps than websites, and most importantly, can be run in a browser or installed on any mobile device from the app store.

Announcement of Meteor 3.0

We are thrilled to announce the release of Meteor.js 3.0, a milestone in our journey to create a powerful and versatile platform for modern web development.

This release marks a significant leap forward, and we couldn’t have achieved it without the unwavering support of our incredible community and partners.

What does Meteor 3.0 bring to the table?

In short, Meteor 3.0 brings Node.js 20, Express integration, Fibers removal, async server methods, ARM support, package updates, and new documentation.

The, in my opinion, core value of the Meteor platform is to get valuable user experience to our users.

And exactly that core piece is not being told anymore. Everything goes about tech, performance and other stuff.

The dev time spent seems to be on the behind the scenes improvements. Which are noteworthy, things are getting better. But the real Meteor experience does not get the attention anymore. And it seems that isn’t really where the focus is internally. It’s still visible in marketing text on the website though which is the strange part.

Gotta love the initial experience when you made your login page as an example:

Then simply add the {{> loginButtons}}helper to an HTML file. This will place a login widget on the page.

It did. It did work. It did delight users. No other platform ever got that good. That simple. If that level would be possible in react without searching for external stuff. Just in the manual, do this, do that, login works. That’s where you really achieve:

Stop fighting with frameworks and start shipping real apps.

1 Like
16

Agreed. A strong example app will be needed here, once we get there, that can attract people on sites like HackerNews, etc.

Yes, that was the immediate issue which then lead that the real-time scaling issue wasn’t really resolved. The idea was that Apollo will be the solution, but when that became more lucrative than Meteor (thanks to people pealing off due to the Blaze v React issue), it never got resolved.

I believe we should mirror Node’s releases. It is predictable and well known, plus we depend on them as well.

I think Meteor Impact is the best we can do now. We will need to grow community and the money going into it to expand further (though there are some options coming up for the live part).

I think this might be a good idea for a talk for Impact.

Very much agree, but there is a split in community between returning to that paradigm where we had {{> loginButtons}} and being more open and flexible. The issue is how to resolve the front-end splintering. One possible solution is here:

17

Thanks!

I read that thread with the Blaze-Component idea. I get it, might be a good idea or not I don’t know.

But if you look at the thread it is again about technical implementation. That’s the point I made.

I do see the value in being open and flexible. But I think it has become a black and white discussion and that is not what I think the leadership strategy of Meteor should be:

Very much agree, but there is a split in community between returning to that paradigm where we had {{> loginButtons}} and being more open and flexible.

I think that is the thinking / communication issue. It is not like supply all tools, custom template language, full blown app building environment etc. I think there is a baseline of the tools we all need to get our first prototype of an app or a new feature out to test with users.

That’s the start of the magical Meteor experience we had the honor to experience.

The great experience was:

  1. meteor create (no template)
  2. create projects collection
  3. autopublish did it instantly, no need to understand the technology behind publish-subscribe to show a demo
  4. Show the data with some scaffolds, add data via de console Projects.insert({name: ‘Project X’})
  5. meteor deploy myapp.meteor.com
  6. Magic, client could see something which looks and feels like an app

For comparison: Making a login now:

You get a manual like: Meteor.js 3 + React | Docs where you are building your forms by hand.

So every developer has to go through those steps. Why not just supply them as a tool to get started. Basic level, customization can always be done. Like scaffolding.

I do understand that the open and flexible paradigm should exists, that there should not be too much maintenance for the team etc. But I think you do can supply the basics and communicate in that way to get user to quicker real world results with Meteor as a tool.

We had apps surviving more than a year with loginButtons before we started building our custom ones. So we could really dedicated focus on the user.

1 Like