Top 5 Predictions for Meteor in 2016

The year 2015 was pretty great for Meteor and a lot of new things came up. Have a look at this and this article.

But that’s history. Right now, Meteor is a mess. Frankly, this is a really bad time to start a new Meteor app.

Oh. You said this post would be about some predictions for Meteor in 2016. Now you are talking about something else.

Okay, okay. Actually, I was leading up to that.

1. Meteor will become much closer to the JavaScript ecosystem.

Starting with Meteor 1.3, we’ll be able to use NPM modules very easily with Meteor. We could use NPM modules from the very early days, but with the new module system, building a Meteor app will be closer to building a normal Node app.

Also, we’ll starting to see the use of NPM modules instead of Meteor packages. Have a look at this project. You’ll find it interesting. This is just the start.

2. There will be a few stacks built on top of Meteor.

Meteor will be the best place to run JavaScript apps. JavaScript is a huge ecosystem. So, there won’t be one single way to build an app. As always, there’ll be many ways.

So, there’ll be few opinionated stacks built on top of Meteor.

You can consider Mantra as an example of this.

Wait, what’s Mantra?

Oops.

3. RIP, Tracker.

Tracker is the core part of Meteor. It is used everywhere on the client side of Meteor, but we won’t need to use it in our apps in the future. Originally, Tracker was built for Blaze. It’s used to identify data changes.

And there won’t be a Blaze 2 project. Blaze is already a dead project.

With the evolution of virtual DOM, we don’t need anything like it. Instead, we can re-render components from top to bottom with new data.

We may still need to observe data, but for that we may use something like Rx.js observables.

4. We’ll starting to see a new meaning for isomorphism.

In Meteor, being isomorphic means that you build an app and it’s available everywhere. Everywhere means it’s available on the server, web, iOS and Android.

We will never be able to write a single app targeting all these environments. Even if we did, we would need to use different styles and even use different UI code.

Instead, we’ll build multiple apps for each of these environments. We’ll use modules (possibly NPM modules) in multiple environments. That’s the meaning of isomorphism.

It’s not isomorphic apps, but isomorphic concepts and modules.

5. Meteor will be the infrastructure, not the framework (or SDK).

With all the above predictions, you might be thinking something like this:

Okay, it seems like we are removing things from Meteor. So, what’s left under the name Meteor?

That’s a good point. Meteor will be the infrastructure for JavaScript apps.

For example, we could get started on building a JavaScript app without worrying about build tools, transpilers and so on.

With Meteor, we can build and ship apps quickly.