Why choose Meteor (or not) for your next project?

The recent State of Js 2020 survey results are out and as a long-term Meteor developer I am shocked about this result* for such an amazing framework. See for yourself:

*Meteor is located bottom left in the "avoid" section ☢️

Well, from here I could write a page-long article, bragging about these results, stating that the people don't know the framework or rated it, based on a past (and outdated) experience.

However, this article is rather intended to figure out how it came to this whole situation, where Meteor is heading and how you should evaluate Meteor for your next project.

Disclaimer: I am not affiliated with Meteor Software, MDG or Tiny. I am a constant Meteor user and active contributor to the Meteor community.

---

What is Meteor?

If you have "never heard of" Meteor, like 5743 out of 23,765 respondents of the survey (26.8%), even if you are among those 46.3% of "not interested" respondents, you might consider this section to get to know Meteor.

Meteor is a full-stack JavaScript framework, that brings nearly all functionality, required for developing JavaScript apps, out-of-the-box. Full-stack means here especially to use JavaScript as main language for every layer of the stack (client, server, transport, database). Furthermore, it's also completely open source and the code is MIT licensed.

⌨️ Developer ergonomics

Meteor is not only a JavaScript framework but also a complete development tool and it brings many features for a great development experience:

• running the development server; zero-config
• running a development MongoDB, provide zero-config DB integration
• auto-rebuilding development application on code-change, zero-config
• build output from one codebase for server, client, client-legacy (IE and friends) and mobile architectures with zero config / minimal config for mobile
• zero-config transpilation; constantly uses latest babel features to support ESNext features where possible
• bundling the code to an executable node application, zero-config

💠 JavaScript ecosystem

Meteor also integrates very well with the rest of the JavaScript ecosystem:

• built-in support for major frontends (React, Vue, Svelte)
• built-in support for typescript (zero-config)
• built-in NPM support, integrate any NPM package on server or client (without the need for tools like browserify)
• therefore you can use alternative databases
• and have great support for major testing frameworks
• create RESTful applications using express or Meteor-specific packages
• you can basically consume any external API as in every other node-based app

❄️ Unique features

On top of all that Meteor offers some unique features:

• well-defined data-communications layer (rpc-style and/or publish-subscribe pattern) with a buil-tin lightweight reactivity system and a custom protocol over WebSocket
• out-of-the-box OAuth-based accounts system with minimal-config
• many of the zero- to minimal-config features are actually configurable so you are not locked to the default settings
• an extra ecosystem of packages, that allow to write extensions with direct Meteor-integration; these packages can also include or extend existing NPM packages Meteor's custom package ecosystem
• perfectly coordinated infrastructure for hosting Meteor apps

This all means - you can create a project and immediately start coding with a zero-config setup. Yes, like those "create a <name-of-app-clone> in under <x> minutes". (In the future I will add some of these kinds of tutorials.)

If you are already hooked up at this point and you simply ignore the "avoid" status, you may check out my < 5 min setup article to get started right away. ⌨️

For everyone else - let my clear up a bit how it came to this situation.

---

How it came to the "avoid" status situation

"If it has all these great features, why are people so unsatisfied with it?" would be my first question from reading all the above praises. Of course I am biased here, since I am engineering production-grade JavaScript apps with Meteor since 2015. However, the journey to this situation is much more complex than it could be reduced to the technology itself.

🚀 The beginnings

Meteor as technology is a mature and very alive framework. It was initially released in 2012, gained a great funding and grew very fast. The reason: Easy, out-of-the box JavaScript fullstack with tight (and zero-config) database integration; an extensive data-loading layer and a WebSocket-based custom protocol (DDP) to automagically sync data.

It's core business was to provide the infrastructure that is required to properly connect the client with the server and allow a close-to-realtime data communication via WebSocket. It also came with a custom package ecosystem that allowed an easy integration of reusable code and libraries. In 2012 this was a major deal!

The Galaxy service for one-step deployment (which was also a major deal in 2012!) included a free-tier and as a consequence there were new Meteor projects and packages popping out of nowhere, showing what Meteor has to offer.

The developer community was very excited about this groundbreaking all-in-one ecosystem, though there were already complains about the unsatisfactory NPM integration and the lock-in to MongoDB. At the same time new players emerged on the market, offering a much higher flexibility and scalability at the cost of higher development and configuration effort.

📉 The drop

This caused a first drop in the community in about late 2015 to 2016. Then, after one of the communities most recognized persons also left, many people considered Meteor as "dead". In consequence this also caused many packages to become unmaintained / abandoned and even more people became frustrated. Articles and tutorials about Meteor were not updated or removed and even nowadays, people find outdated tutorials that actually don't work and crash, leading to just more frustration. On the business side, the free tier on Galaxy disappeared, too, due to the costs and less generated income.

In the meantime the Meteor Development Group (MDG) did an excellent work as they integrated bleeding edge tech (ESNext) even before it had been adopted by many other major frameworks in hope to regain traction. Furthermore they worked on all the major flaws and from release to release the framework gaining "superpowers" in 2017.

If you want to see the timeline, just scroll down the blog for the older articles.

Unfortunately it all did not regained traction and I assume that many people from the old days still think about Meteor from the time when everyone left. MDG started focussing on their next bussines, Apollo GraphQL, which became a great success and has also been well recognized by respondents of the survey.

With this shift of focus the community also felt to be left alone and the satisfaction with Meteor declined even among it's own users. This effect happened around 2018-2019 and it correlates with the 10% satisfaction drop in the survey.

🧑‍🏫 What can we learn from this?

Although many of these previously described effects are of a social nature (community, trust, communication, public relations, financing and profitability) the consequences directly reflect on the technology itself. It's the brand that has been damaged, not the tool. The software behind the brand can run as stable and as reliable as possible and have most promising features but once the brand is damaged it is very hard to take an objective view on the technology.

This process itself is also very hard to stop and I wouldn't blame MDG for it, because in this very process they gave their best to provide so many awesome features to the framework, basically for free (Meteor is MIT licensed).

We all should learn from this how fragile a ecosystem can be and how intertwined the technology is with it's surrounding social context.

📈 There is recovery!

Fortunately the future of Meteor looks brighter than this whole situation right now reflects on.

First, the Meteor community formed in late 2018 a new GitHub organization (named Meteor Community Packages) to keep popular and widely used packages updated, while offering backwards compatibility and some kind of semi-official status. This was a first step to rebuild the trust in the whole ecosystem and it is now a well-recognized part of the overall Meteor developer community.

In 2020 Meteor has been taken over by Meteor Software, which is vc-funded by Tiny Ventures, so MDG can focus on their new main business with Apollo. Meteor Software offered a strong collaboration with the community, shorter release cycles and a vision for the future of Meteor, which is becoming reality with the upcoming major 2.0 release.

A major upgrade has been introduced by using React Native as alternative to cordova while keeping all the benefits that Meteor offers. Hosting plans also changed to include more affordable plans and the famous free-tier plan is back again!

---

How to deal with this "avoid" status?

Note: in the following sections I am speaking in "we" when I want to refer, how the Meteor community tries to deal with the situation. It is not 100% representative for every person but I try my best to reflect my observations from chats and discussions, conclusions and actions.

With all the great development efforts of the recent years we as Meteor community a happier than ever to use Meteor. In consequence we were - again - disappointed by the survey results but we also have to simply face it as part of reality.

The survey shouldn't be blamed either, since they were totally neutral about the technology. In fact, this is already proven by itself - the survey is built using VulcanJs, a framework that builds on top of Meteor and runs on the Galaxy hosting service! (I bet you didn't know or noticed.)

We are also aware that Meteor still has a lot to improve:

• the Blaze engine (Meteor's own frontend engine) has not been updated in a long time
• many packages have still dependencies to underscore, lodash, moment or jQuery
• there are still many unmaintained packages out there, which have not been flagged as such
• there a still people who find outdated articles and tutorials using very old Meteor versions, leading to crashes or unexpected behaviour, thus finally to frustration
• topics like JAMStack, serverless, microservices and SSR are still rather intermediate- to expert-level topics and require a deeper understanding of how Meteor works, which can lead to the impression of Meteor not being capable for these topics

Especially the last point could make many people consider to avoid Meteor, simply because this is what is currently in high demand. The community and the Meteor Software team are very aware of these and is constantly improving the framework.

From this point of view I'd like to transit over to the arguments for and against Meteor from the perspectives of a beginner, advanced and professional developer.

---

When should you consider Meteor

We know that this survey has some impact, especially for people who are currently looking for picking a technology that suits their use-case and requirements.

If this applies to you: do not avoid Meteor! Let's go over to the good part and see what Meteor has to offer for you.

As a beginner

🚀 The biggest pro for Meteor as a technology is that you can install it fast and start immediately without having to care about things like bundling and server-client communication. This brings fast results and allows you to focus on your code and improve your development skills step by step.

🤝 Meteor offers integration for nearly all frontend frameworks/libraries out there, where at least the major ones (including svelte!) are integrated. Checkout this < 5 minutes setup guide for creating a new React or TypeScript project with ease.

🔒 You have a full working authentication system with nearly zero-config out-of-the box. The auth system is based on oAuth and you can easily integrate third-party logins (for example via ).

📚 The guide and API docs are exhaustive and cover all you need from basic commands to best practices. Beyond that there are actually very good tutorials out there for many topics, helping you to transit into becoming an intermediate.

💪 The Meteor community is very welcoming and helpful. A good amount of active members is there since 2015 and earlier. If you have any question just say hello in the forums and there will be someone who is ready to help.

As an intermediate

You can integrate nearly any NPM package on the server and/or the client. This also allows you to use a different database, like PosegreSQL or redis.

You can create RESTful services parallel to your Meteor methods and publications using the builtin connect handlers, express or one of the many packages for REST.

📦 You can count on the Meteor Community Packages to offer stable, maintained packages of high quality.

🍃 Use dynamic imports to minimize your bundle size and optimize your Meteor app for PWA usage.

🧪 You can integrate nearly all major testing frameworks (unit testing, integration testing, e2e).

🚀 You can deploy with one step to the Meteor application cloud. If you want to host on your own you can use Meteor-up for one-step deployments.

📱 You can deploy to mobile architectures from the very same code-base you use for developing the web-app. You can choose between Cordova or React Native. This saves lots of time and management between multiple codebases.

As a professional

🤝 Meteor works very well with GraphQl via Apollo, which comes with a special Meteor support.

🏘️ Scaling is no issue (anymore) as you can easily use all MongoDB features, as well as packages for clustering, zero-downtime-deployment or databases like Redis for caching or oplog-tailing.

🔄 Meteor integrates into most (if not any) of the known CI/CD pipeline providers and you can easily deploy from GitHub actions.

🔀 Meteor does exact code-splitting, even with packages, so you can write isomorphic code that works on server and client without creating a dependency-desaster.

📦 Very soon Meteor will have hot-module-replacement (HMR) and tree-shaking with it's upcoming major 2.0 release.

🤑 Finally to say, there are companies out there doing a great and profitable business with their products and services, based on Meteor. Most recent examples are Qualia, which just recently raised 65m and CodeSignal, which just recently raised 25m in funding. Beyond these there are other companies and official partners, too.

---

When should you avoid Meteor

There are situations where you might want to avoid Meteor. It's hard to be objective as a pro-Meteor developer and I hope the following is as unbiased as possible.

As a beginner

Actually there is not much to say for beginners to avoid Meteor as it has such a low barrier of entry that you won't waste any valuable time of your live. Just try the < 5 min starter guide and create a simple app in a few steps.

👔 However, if you are concerned about getting a job you may look out for one of the rather popular frameworks. The chances are not bad to get a job as Meteor developer but if you are in need to get a job as soon as possible and want to increase your reach as potential employee then you may rather be suited with one of the popular frameworks. This is because most companies that search in the field of NodeJs will mostly look out for talent in the area of SSR+HTTP and with Meteor these concepts are not really included in the beginner topics.

📱 If you intend to develop a mobile app then on the first glance it might be very tempting to use Meteor's "once-codebase-deploy to many architectures" features. The problem is rather under the hood (if it uses Cordova) when specific plugins for native integrations don't work as expected. For beginners this can be a great showstopper, because debugging them can sometimes be very frustrating and time-intensive.

As an intermediate

🔍 If you intend to do lots of SSR+SEO+HTTP without the need for reactivity (as for example in e-commerce) then you might be better with a different solution that already focuses on these parts.

⭐ If you are looking for recognition of your open-source contributions then you may become frustrated when your really-great package will remain < 100 stars for a long time.

📡 Also, if your target audience lives in an area with poor bandwidth and you still haven't mastered all the internals of Meteor's data handling you still might end up frustrated with optimizing the app for low bandwidth a lot. Optimizing for smaller bundle in return requires more than just tree-shaking (Meteor 2.0) and dynamic imports - it also requires to know when and where to place them in order to intelligently let your app bundle "grow" over usage time.

🧪 If you really intend to learn NodeJs application architecture from the beginning or you feel patronized by all the abstractions Meteor brings, you might actually want to start with an empty node project and dig your way through. It will be a great hassle but you will also learn a lot about NodeJs and may soon start to create your own framework.

📁 Doing heavy lifting on the file-system is a great pain with Meteor when in development mode. This is because Meteor builds a local node-application each time your code changes. However, this advantages makes it very complicated to work with file-system-focused packages as paths a very different in the build output than the development files and the context switching can make your brain hurt easily.

As a professional

🚫 Some of Meteor's core feature may be prohibited by project constraints or audit requirements.

For example: While Meteor's authentication is one of it's biggest advantages it can also be a problem in professional contexts, for example when audits do not grant the way Meteor's tokens are stored or a very specific authentication method is required, that you intend to write on your own. The same goes to WebSocket or the (open) DDP-protocol implementation.

👔 It is hard to find experienced Meteor developers that are free for hire, compared to other frameworks like next. If you are a leading a team and have to decide for a framework with high developer supply in the market then this might already be the k.o. criteria for you.

📦 Meteor will heavily rely on it's package system and decisions about where to place common code (NPM package vs Meteor package) have to be made early on or you will end up in trouble when your codebase grows or you prepare to split your monolith into services. A deep understanding of the Meteor package system and architectural constraints is required before planning and it may not be feasible for your project to gain this experience in the given time.

🔒 On top of that, if you don't want any tight technological dependency to a framework or ecosystem beyond using NPM to build your own stack then Meteor may not be suitable.

---

Wrap-up

🔍 The state of Meteor 2020

I hope the article summarized the current state of Meteor, how it came to this situation, it's strengths and weaknesses and it's surrounding ecosystem. It has matured well as a technology but it's brand suffered a high loss in reputation. In the meantime it changed ownership and is getting back on track with a new vision and constant improvements.

🔭 What the future will bring?

The development of Meteor 2.0 is in it's beta rc phase and the long awaited major release will be out very soon! The recent development within the community and the collaboration with Meteor Software promises a lot. If this will reflect on this year's State of Js survey remains unclear and I think the earliest impacts of the this development will rather start in early 2022. Until that I hope this article gives a clear and objective insight to the state of Meteor and in 2021 and provides some valuable information for you to decide, whether to use Meteor for your next project.

👍 Why I will choose Meteor for my next project

Let me add some final and highly personal words.
As a long-term Meteor user I am highly satisfied with the speed, stability and comfort during development, as well as deployment. From a DDD perspective Meteor brings me all the infrastructure I need to entirely focus on my business logic while I can still manage to bring in my architectural decisions to build the kind of applications I need. Most of my applications are rich in client features and heavy in server-client communication, use-cases where Meteor perfectly fits my demands. There is no other framework to me that currently helps me to realize my projects in a faster and more enjoyable way.

Thanks to @storytellercz and @filipenevola and all the other Meteor community members who supported me in writing this article.

---

I regularly publish articles here on dev.to about Meteor and JavaScript. If you like what you are reading and want to support me, you can send me a tip via PayPal.

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

Keep up with the latest development on Meteor by visiting their blog and if you are the same into Meteor like I am and want to show it to the world, you should check out the Meteor merch store.