I recently picked up a comment on Reddit that directly feeds into the never-ending "Meteor is dead" FUD talk. Usually, I immediately join these kinds of conversation and beam a huge list of facts straight into the heads of them peoplezzZz to prove a point. 🛸

Well, this time I thought different. Let's skip this highly annoying type of interaction and cover the "dead debate" beyond Meteor.js and on a much deeper level. 🤯

Don't worry, as the end of the article will still contain all the facts on Meteor.js, so next time I can beam the article into them brainzzZz. 🛸

‼️Trigger warning‼️ The following article includes themes and topics about death that go beyond the realm of software engineering and web development.

---

Dead or not dead? 💀

We all know, in JavaScript there is only hype-driven-development (hdd) as the one and only methodology to rule them all. If you don't ride the hype-train then you're dead. Thankfully, this is just a superstition and far from being correct. However, many users feel the JS ecosystem is moving very fast and new tools emerge on a weekly basis.
If your software can't keep up with and ride the hype-train constantly then it becomes dead, right?

Well, it's not that easy. The term "xyz is dead" can actually refer to many more things than that and it also depends on the context and the intention of the person who used it.

At this point we can't clearly say what "dead" means to a software, as there is no generally agreed definition for it.

However, I don't want to go any further without a clear definition of what "dead" actually should refer to, when speaking about software, tools and frameworks.

When we should NOT consider a software as "dead" 😇

The great part of this is, that there is already an article that unwrapped this question in an amazing way. I highly suggest you to read on "What do we really mean when we say that software is ‘dead’ or ‘dying’?" by Richard Gall, before continuing to read. It perfectly summarizes misconceptions about software being considered "dead".

Furthermore, the concept of "dead" seems to be used too often in order to coin less popular or aged software as being not usable or that it should be avoided without reasoning why. If objectively evaluated, some of the software/libraries coined as "dead" are actually far from it.

Famous examples in web development

jQuery

• considered unpopular
• active releases
• >2m installs)
• constant development since 2006(!)

ember.js

• interest declined
• however, well matured and far from being dead

less

• lost the battle to scss
• still over 4m weekly installs)
• active development, although with pauses but nothing indicating death

Interesting fact: the famous state of js survey dropped the term "avoid" and replaced it by "harder to recommend currently", when categorizing libraries into quadrants

When we should consider a software as "dead" 😵

I believe, that we can validly categorize a software as "dead" or "alive", if there would be clear list of criteria for it.

For this, let me bring in some context from the real life: We have various concepts of someone being dead: clinically dead, brain death, legal death, biologically dead. For clinical death, there are specific criteria for physicians to diagnose the death of a person (without doubt). They may vary by country or even by state but in general they are very clear and unambiguous factors.

Of course, there are fundamental differences between humans and software:

• humans can live on their own, software always needs at least one external entity to advance any step in the lifecycle; not considering the whole AI debate here 🧐
• humans have a limited time for reanimation (the time from cardiac arrest to severe organ damage); software can be reanimated at any time
• humans who are lost cannot be restored, rebuild or reverse engineered; software can; not considering the whole trans-humanism debate here 🧐

From the above factors we can now build a very clear

Clinical Software Death

A software can be considered as "dead" when the following factors are fulfilled:

• the software is confirmed to be "abandoned", "archived" or any other form of "active development stopped" by it's owners
• the software is in one of the following states:
  • it's non-functional (has critical bugs; memory leaks; critical performance issues)
  • it's incomplete (missing critical features)
  • it's vulnerable (security; dependencies)
• chances are low for any considerable effort to change these two factors

The status of being "dead" is not fixed and can change, if one or more of the above factors change for the positive.

In an early version of the article I listed two projects here on the verge to death. However, they were still alive and as I know from the debate around "Meteor.js is dead" this would only create FUD. In contrast I advise you kindly to use the above list and do your check-marks on some projects you personally consider(ed) dead.

My 2cents on this 🪙

I found the whole topic becoming increasingly morbid the more I dealt with all these death themes and criteria. Due to this, I even dropped some sections (e.g. about "Zombieware" as it became ridiculous 🧟‍♂️🧟‍♂️🧟‍♂️).
I also think this whole death theme is a fundamental consequences of the negative framing of "is XYZ dead?". The question already sets a negative foundation for the whole upcoming debate, where proponents become highly defensive (often seen and sometimes practiced myself), while opponents may use invalid arguments ("nobody uses xyz today") or even become offensive. 🤬

I would even go that far to say, that if such a question is deliberately used to undermine the credibility of whatever software, then it could be described as dead-framing.

A change in perspective 🔭

Instead of this, I propose that everyone rethinks this terminology. We have seen, that a clinical software death is very rare (at least of you read the linked article above). A better alternative would be to ask

How alive is software/tool/framework xyz?

On the one hand, this question would not frame the involved software in a negative way and criticism on the software will not sound immediately offensive.

At the same time it allows for a more distinct evaluation, because it's an open question that cannot be answered with a simple "yes, because..." or "no, because...". Let's all consider this for the next time. ❤

Finally, at this point I'd love to transit over to the Meteor.js part of the article.

---

How alive is Meteor.js? ☄️

TL;DR: it's very alive and has never been dead (trust me, bro) but you better be reading the facts! 🛸 This part might also be interesting to you, in case you want to evaluate Meteor.js as your next fullstack development platform.

Let's get back to the initial topic that inspired me to write this article. For this I will check the current state of the Meteor.js ecosystem against the above criteria for clinical software death.

Ownership and Company backing 👔

For a project to not being abandoned there needs to be an owner that is present and reachable. For Meteor this is currently Meteor Software. They took over the ownership, when Tiny Capital acquired Meteor from Meteor Development Group (MDG) in 2019.

The company has currently 12 employees, working on the Meteor.js core, packages, documentation and the community around it. The team distributes across the globe with a great portion being located in Brazil. Furthermore, Meteor Software operates on providing cloud services around the Meteor.js platform, so they have an ongoing interest in it being continuously "alive and well".

Meteor.js core development ⌨️

The Meteor.js core platform is developed by the Meteor Software team on GitHub. There is a constant stream of commits since it's initial work in Nov. 2011. Also, contributions never really stopped, as you can also see in the following contribution graph
from the GitHub repository:

Integrations with popular tools and libraries 🔨

Meteor officially supports various popular frontends and technologies.

• React (default)
• Blaze (Meteor's original frontend)
• Vue 3 + vite
• Vue 2
• Svelte
• Solid
• Chakra-UI
• TypeScript
• Tailwind
• Apollo

Official support means, that there are ongoing commits in the repo to ensure these integrations into the stack and their documentation are up-to-date.

Use meteor create with options from the above list and try out a new project and see for yourself! You can also find the source for these commands in the respective skeleton projects.

Meteor.js package ecosystem and package development 📦

Meteor.js is built on top of Node.js and is fully compatible to packages you can find in the NPM registry. Some packages of Meteor core are also NPM packages.

However, during early days of Meteor.js an own package ecosystem emerged in order to provide zero-config integration with Meteor, MongoDb, Tracker, compilers and many more from the platform.

There are 14,646 packages available for Meteor.js as of today. Packages get constantly published by users and there is also Meteor-Community-Packages (MCP), a GitHub org under which very popular / widespread packages are kept maintained or improved with new features.

Community Activity 🤝

Meteor has an active community of developers, individual as well as institutional.

Communication heavily resides around the Meteor forums which contains a stream of topics up until back to 2014/2015 (31.3k topics with 217K posts overall as of today). Some members from that time are still active there as well.

Additionally there are active Slack and Discord spaces as well. Many of the packages beyond Meteor-Community-Packages are actually developed and published by members of the Meteor.js community.

Conclusion ✅

• the software is confirmed to be "abandoned", "archived" or any other form of "active development stopped" by it's owners

Not at any time, as you can see in the repository and its commit history.

• the software is in one of the following states:
  • it's non-functional (has critical bugs; memory leaks; critical performance issues)
  • it's incomplete (missing critical features)
  • it's vulnerable (security; dependencies)

A project of this size and in constant development will always contain one or more of the above as it hardly becomes "feature complete" as opposed to packages or small libraries. For Meteor.js you can see 222 open issues as of today, which reside around these topics. Most of them are related to "it's incomplete" as Meteor currently does a transition to a new Major version.

• chances are low for any considerable effort to change these two factors

If development would stop or be dropped by Meteor Software chances are very high that the community will jump in and continue development.
Additionally, there are various companies running a business on top Meteor apps, which will make it more likely ongoing development is ensured.

---

Disclaimer 🧐

I have to state a disclaimer here for those among y'all, who are already throwing the "full circle" argument at me. 🍅
Yes, I created the definition myself and applied it to the Meteor.js framework and it's all working out positive. However, I tried to be as objective as possible when creating criteria for a definition. I think I came up with one, you could also apply to any other project. And yes, the majority of evaluated software would not be considered dead, according to this criteria. That's the whole point.

Anyway, I'm also open for improvements of the criteria as my final goal is to either rationalize the term "dead" when speaking about software or even getting rid of it at all! In the end it's all about tools getting the job well done for their purpose. Personal opinions and preferences should be secondary to this.

---

About me 👋

I regularly publish articles here on dev.to about Meteor.js and JavaScript. Recently I also co-host the weekly Meteor.js community podcast, which contains the newest from Meteor.js and the community.

You can also find (and contact) me on GitHub, Twitter/X and LinkedIn.

If you like what you are reading and want to support me, you can sponsor me on GitHub, send me a tip via PayPal or sponsor me a book form my Amazon wishlist.