The contents of this article are unofficial and based on my own opinions. That said, the future of Meteor is bright.

The Early Days

I first watched this screencast in 2012. I get a big kick out of watching it again after four years!

Back then, I had just wrapped up a large Backbone application backed by a PHP REST API. I had, quite painfully, hand-coded every model both on the server and in the client. I had hand-coded my own authentication mechanism over the API. I had hand-coded my own Ajax wrapper and request/response/error handler. I loaded every dependency via require.js. For deployment, I hand-coded my own Grunt-based process to pre-compile templates, minify code and bundle everything together.

It was awesome. Or, at least, I thought it was until I saw the video.

Meteor 0.6 felt like a breath of fresh air! Reactivity everywhere. Authentication (even OAuth!) was a 10-minute effort. Ajax was a thing of the past. The build process (with live reload) was free! Who needs dependency management when you have autoload!

1.0

Meteor's vision was a world where writing this new class of real-time, client-connected software was easier and more accessible. It was hard to argue that they weren't on the right path.

The roadmap to the much-anticipated Meteor 1.0 was very public, and the Meteor Development Group executed on it well. There were things they definitely felt were important to put in 1.0 (Blaze and a mature packaging system). There were things that they definitely did not need for 1.0 (testing and Windows support). Yes, there were tradeoffs, but 1.0 marked a very big milestone for Meteor and signaled to businesses that Meteor was enterprise-ready. During World Meteor Day, I was like:

{:width="100%"}

Fatigue Sets In

During this time, something else was happening. The landscape of Javascript development shifted underneath Meteor's feet. As Meteor apps matured, their developers started asking:

I need hot reloading in my app. Why can't I use webpack with Meteor? Blaze is too hard to organize. I want to use React Angular Vue in my app. Why can't I use React Angular Vue in Meteor?

And especially:

I want to use SQL in my app. Why can't I use SQL in Meteor?

And so on. We got some of those things, like React support. For the others, all of a sudden, it felt like progress stopped.

Meteor Finds a Galaxy

But not really. Between 1.0 and the current version, Meteor improved by technical leap after technical bound. The problem? Sacha Greif stated it very eloquently in this comment:

Compared to a few years ago, Meteor has improved leaps and bound from a technical standpoint. But paradoxically, the framework’s value proposition is far less obvious than it used to be.

Since 1.0, Meteor has brought huge improvements like npm integration and the constraint solver. Likewise, it has upgraded support for newer versions of Node and Mongo. It was among the earliest adopters of built-in ES6 support, including modules. Meteor 1.4 improved build performance and 1.5 aims to improve page loading time, in particular by code-splitting.

But, as Sacha pointed out, these improvements are not obvious, not immediately visible and can be difficult to explain. They are improvements for sure, but they don't help the developer who just wants to use MySQL.

After extensive surveying and interviewing, Meteor says that these are features that most users wanted. If that doesn't make sense to you, consider that the most important users of Meteor are perhaps the real customers of the Meteor Development Group: Galaxy users.

Galaxy customers have invested perhaps the most time and money into mission-critical Meteor apps. These users want performance, low tech debt and do not upgrade so easily. This is understandably so. Who are they not? They are not hobbyists who want an easy start. They are not advanced users who are constantly on the forefront of Javascript.

Towards 2.0

So what might happen with Meteor in the next year or so? Let's look at the most common flash points separately.

View Layer

You can already use Blaze, React or Angular out-of-the-box with Meteor. There are community solutions for other view libraries.

Routing

This definitely needs work. Flow Router is the de-factor standard, but it is a community package maintained by Kadira, who is no longer in the Meteor game.

Building

If you're like me, you've never setup webpack from scratch. You always start by copying configuration from another project. Webpack is powerful, fast, overly-complicated and poorly documented. I could live without webpack.

Fortunately, I can and I do. Achieving 90% of the niceties of webpack already work simply by typing meteor. There are a few things missing, but they are on the roadmap. Meteor 1.5 promises features that webpack fans have been clamoring for such as code-splitting and tree-shaking.

Packages

Atmosphere needs to get cleaned up and pared down before any Meteor 2.0 release. Meteor packages and npm packages fulfill different needs, so it would be foolish to ditch Atmosphere completely. The majority of Meteor packages on there today should get removed or move to npm.

Meteor itself will eventually be installable via npm, bringing Meteor closer in line with the rest of the Javascript ecosystem.

Data

A main component of Meteor's vision was the connected client. This client could query the database and not only get results once, but continue to receive granular updates to that data in real-time. This system, called Livequery, took no work to set up, and even came included with optimistic UI. There was only one problem: you were required to use MongoDB.

Enter Apollo. Apollo is already a stable GraphQL client. But many are waiting for Apollo to become a first-class replacement for Livequery in Meteor. Then, and only then, do we get back the original principle of full-stack reactivity, only now with the ability to use any data source that we want.

What's holding Apollo and Meteor back? Not a lot! In fact, you can use Apollo with Meteor today. But there are a few things missing.

1. Livequery's is incredibly simple to setup, and very bandwidth-efficient. While Apollo does support GraphQL subscriptions, updates are not as granular as Livequery's. (For more disussion on Livequery vs Apollo, read Apollo Subscriptions For Meteor Users{:style="background-color: rgb(255, 255, 255);"}.)
2. Meteor developers are spoiled by the Meteor accounts system. Using the built-in UIs and client APIs take no effort for a web app. If you are using a native client or API instead of a webapp, the server APIs and database schema have already been thought out for you. One of the key requirements for making Apollo "first-class" in Meteor is to support accounts with a non-Mongo back-end.

All the above is true today, and all the while Meteor remains dead-easy to send emails, do end-to-end testing and other common tasks.

What Might 2.0 Look Like?

If you watch that video above, I'm pretty sure that that exact code still works today, 4 years later. Which is amazing. So there is no historical evidence that Meteor 1.x apps will get left behind. I think it's fair to say that the only reason such fear is out there is because Meteor has not made any strong statements to the contrary. I believe Meteor 2.0 will:

1. Have a few breaking changes for Meteor 1.x users.
2. Have a clear upgrade path, just as always.
3. Allow novice developers to create apps quickly and easily, just as always.
4. Allow seasoned developers to create apps quickly and easily, but choose the view layer they want, choose the database they want, scale when they need to scale and move libraries to new ones as the requirements of their apps change.

To Infinity... And Beyond!

So will Meteor become a game-changing, next-generation software runtime, or just a really, really nice wrapper of other tools?

In my opinion, it doesn't matter. The mission is still the same. The original mission of Meteor's was to make software easier to write. We can still get there in either case. I will still be able to type meteor create app and get my app up and running in no time. Then, when I need to, I can be confident that I can choose the best database, best view layer or best build process for my app.

I can't wait!

For further reading, there is an extensive discussion on this subject on the Meteor forums.

Some images grabbed from Geoff Schmidt's Javascript State of the Union talk.