The Meteor Alternative of 2022

Meteor is a JavaScript framework started in 2012 by 4 guys from MIT. They secured a total of 22M USD in funding and they have over 42k stars on GitHub. This article is mainly addressed to people that know about Meteor and want to see how we pursued the same bold vision but with a modern twist.

Ahead of its time

note

This is not a diss to Meteor, on the contrary, this is a historical perspective of what happened, and how we pursued the initial vision with modern technology.

When Meteor was launched it was pure bleeding edge at that time:

1. Reactive UI layer called Blaze (handlebars on steroids tightly coupled with jQuery).
2. Lots of tooling out of the box that gave us, developers, a big boost in productivity.
3. Everything was real-time through the websocket, the server's database was MongoDB.
4. Using meteor deploy you could have deployed to the cloud with zero config.
5. Ability to transform your web app into a native application using Cordova and release it on stores.
6. It was very well backed financially (22M in funding)

There was nothing like it in the world, and on top of that it had its very own ecosystem of packages callled Atmosphere separated from NPM, to be able to use all its features.

On the surface it looks like it had all the ingredients to succeed, but now, in hindsight, we see why it didn't.

What happened?

There are many reasons for why Meteor didn't turn out to be the solve-it-all framework in the web ecosystem. I like to believe it was way ahead of its time.

react & others

The rest of the world was moving on a more rapid pace than Meteor, with frameworks like React, Vue and later Svelte piercing the ecosystem and Blaze was left behind. The amount of effort to catch up was too much for a single team with their focus split in many areas.

npm came late in the game

Before Meteor 1.3 (which was launched in March 2016), in order to use a package from the Node ecosystem (NPM), you would have had to create a custom package to publish to Atmosphere. Imagine what kind of maintenance hell that created especially for the npm packages were getting updated quite often, and you can see how that would discourage a lot of developers.

locked in MongoDB

I'm not a MongoDB fanboy, but I appreciate what that database has to offer. It's versatile, developer friendly and in conjunction with technologies such as Nova it can be used relationally too. But at the same time, to force an entire framework to use MongoDB is a very bad design from the get-go. There was no way to opt-out of MongoDB and be able to use all the goodies Meteor had to offer.

fullstack

The world transitioned into microservices, you typically have one api for the backend and one or more microservices for the frontend. The reasoning for this is that nowadays you can publish static websites to the edge, for free, and also benefit of serverless and propper scaling, while with Meteor you were kinda stuck in having one backend and one frontend serving from the same endpoint.

While you were able to extract the client, and keep the server elsewhere it was often a hassle to do so, and there was no way that we could put Meteor's server on a serverless platform.

DDP (low compatibility)

In order to communicate via websocket, they have created their own communication mechanism called DDP which is basically a way to perform RPC calls through websocket, a more advanced serialisation library named EJSON (which supported Date, ObjectID, RegExp, Infinity and other JS common types), and a way to update client-side data for live/reactive data.

To illustrate DDP in the most simple terms it was something like this. The full spec can be found here.

// outgoing-> "callId", "call", "method", ["arg1", "arg2"]// incomming<- "callId", "result"

The problem? Most applications don't need websockets, or they conditionally need it in some pages, but the biggest problem from my perspective is that the only official DDP client & EJSON was written for JavaScript and locked inside the Meteor ecosystem.

There was no straight forward way to use your Meteor API from other languages such as Python, Ruby, etc, unless you created your own custom HTTP endpoints (REST).

horizontal scaling

A selling point of Meteor was its seamless live-data and everything realtime. Well, as you may know, websockets can be expensive, you would keep a connection active (consuming server resources) even if the person is doing nothing on the website he is on. On the server-side, live-data was relying on tailing the entire MongoDB oplog (basically MongoDB internal list of operations).

As your app grew, and you spin-up more Meteor instances, every instance you had was bombarded by tailing the oplog, especially when you had a lot of traffic or when you did batch inserts/updates.

At Cult of Coders, we solved this by introducing the RedisOplog, a seamless alternative that was fully backwards compatible and we made it open-source because at that point we still believed in Meteor and we knew that this can be a game-changer. Unfortunately, it was not enough, it came too late, even if it's the most talked about topic in the history of Meteor's community, the framework was still regarded by the general public as "unscalable".

Moreover, the technical lead from 1B+ unicorn company Qualia has boasted 100x speed improvements with our tooling, and now, with BlueLibs, we're just taking this a step further.

type-safety

Meteor was written in pure JavaScript (actually it was first written in CoffeeScript) so inherently type-unsafe. While this was ok for your prototype, by the time your team scaled, you were bound to pay the price. TypeScript was born in 2012 but it took a while until it got recognized and started getting traction. With Meteor, it took until late 2019 to offer official support for something that we now consider critical to any development workflow in JavaScript.

ditched by founders

The people who started Meteor, have also started Apollo quite early than most people realise (in 2011). They gathered over 183M+ in funding to this date,

Slowly but surely they downscaled the effort put into Meteor, moving most of the core team to Apollo.

The same guys who wanted to solve the Data Problem through DDP initially, accepted Facebook's solution (GraphQL) as the way to go and since then they have revolutionised and moved the world forward in a better direction.

Timeline

To understand a little bit more about us, here's our timeline:

• 2016 - we started using Meteor and we loved it
• 2017 - our clients were experiencing hiccups in how relational data was fetched, we open-sourced grapher
• 2017 - our clients were experiencing issues with live data scale, we open-sourced redis-oplog
• 2018 - we adopted GraphQL and started using Meteor with React and GraphQL
• 2019 - we decided to fully transition to TypeScript and Node ecosystem and slowly abandon Meteor for new projects
• 2020 - prototypes of our new framework started to pick shape
• 2021 - we launched BlueLibs on November 1st, to pursue the same bold vision.

While BlueLibs and Meteor are conceptually different, they share the same idea: accelerate development and enhance developer experience, giving you all the goodies that any developer needs:

• Start very fast
• Authentication & Authorization
• Straightforward & Easy Live Data
• Tooling for validation, logging, database events, etc
• Easy Deployment

The Modern Approach

In BlueLibs, one layer is built on top of the other giving you freedom of choice:

• Foundation (common tools, no lock-in, make your own stack)
• X-Framework (designed to work with MongoDB, GraphQL, React)
• Blueprint (generates X-Framework compatible code)

X-Framework is in a way our Meteor equivallent and while the backend works with any UI layer we offer rapid prototyping tooling for React, React Native and NextJS.

This is what it takes to get started with Blueprint:

Blueprint

# Install MongoDB & Node 16npm i -g @bluelibs/xx # pick project and answer questionscd projectnpm run blueprint:generatenpm run start:apinpm run start:admin       

Meteor

npm i -g meteormeteor create project --simplecd projectmeteor run      

We benefit from the same advantages that made Meteor great, but with Blueprint, we brought it to a completely new level. We can now start new projects extremely fast by rapidly prototyping our APIs and generate fully customisable Admin UI with Ant Design.

Feature Comparison

Meteor	BlueLibs
Tracker & Session	The Smart package is our solution to combining reactive state and api.
Live Data Server	We have brought RedisOplog into X-Framework, but this time not bound to Redis, + works with in-memory messenger for single instances or local development.
Live Data Client	Unique approach to having both live and static data fetched via same API.
Check & SimplSchema	ValidatorBundle
Collection Hooks	MongoBundle
Emails	EmailBundle
EJSON	Also EJSON, but adapted in TypeScript.
Accounts	SecurityBundle in conjunction with SecurityMongoBundle
Passwords	PasswordBundle in conjunction with XPasswordBundle which integrates with GraphQL API, Emails, etc.

Is Meteor dead?

No, not even close. Meteor was acquired by Tiny in October 2019, and due to their revenue from their cloud platform Meteor Cloud they can now support further development.

Projects built in the past with Meteor have now started to pick up traction and they need more scale making Meteor even more profitable. As a side-note, almost every Meteor project that reaches a certain scale is bound to use our package: RedisOplog or a fork of it. Some people even told me that it has saved Meteor, I don't know about that, but it definitely made scaling up possible, just by adding a fully backwards-compatible package.

I have a huge respect for the team running Meteor, I think they are doing a great job now and they haven't let this wonderful community down. Even if I'm presenting an alternative, this was only possible thanks to Meteor as a source of inspiration which redefined what is possible, and made me excited about development again.

Conclusion

The world moved extremely fast. Nowadays with tooling that is part of the npm ecosystem, Meteor no longer makes any sense for us to start new projects on. We have iterated on the same ideas, but with a modern twist.

The main sponsor of BlueLibs is Cult of Coders, a web development company with many production projects written with Meteor, but also with BlueLibs. Our plan is not only to maintain it, but also evolve it in the next years making it the greatest web development solution for the modern web and enterprise scale.

Next step, start with the documentation, and if you enjoyed our work or this article, share the love with a star on GitHub!