It’s no secret that Meteor is in a state of flux right now.
Blaze is being threatened by React. Meteor’s homegrown package system might be replaced by NPM. And there’s even rumors that Tracker and Minimongo might eventually disappears as well.
So it’s fair to ask: what does Meteor’s future look like?
The Meteor Experiment
Meteor has accomplished a lot since its original launch back in 2012. It was one of the first isomorphic app frameworks (meaning it spans across both server and client), and remains pretty much the only viable one to this day.
But at the same time, Meteor has yet to establish itself as a mainstream development technology on the same level as Rails or even vanilla Node.js, despite the Meteor Development Group (MDG)’s best efforts.
Sure, these things take time. Still, almost four years after Meteor first launched, I have to admit I thought the framework would be more widespread by now. So what happened?
All-In
First of all, adopting Meteor requires switching out both your front-end and back-end. You’re either all-in, or you don’t use it at all. This creates a bigger barrier to entry compared to front-end frameworks like React and Angular, or server languages like Go or Elixir.
Add to this the Meteor ecosystem’s reputation as a walled garden (although official NPM support is coming in version 1.3, so better late than never!) and you can see why some developers might be put off.
Still, that hasn’t discouraged people from trying out Meteor, and to the MDG’s credit they’ve made huge efforts to drive new people towards the platform through guides and documentation, meetups, hackathons, and other initiatives. And the people who give Meteor a chance usually come away impressed.
But the bigger issue here is that even developers who try out Meteor don’t necessarily adopt it as their framework of choice.
Hitting A Wall
I believe some of Meteor’s early choices may have ended up handicapping it. For example, Meteor’s focus on real-time applications makes them a lot easier to build compared to any other platform out there. But it does also come at the cost of hidden complexity, and potential performance problems down the road.
And this focus on the cutting edge also means that more practical everyday issues haven’t always received the same attention. Once a new Meteor user starts to go beyond the basics and look into things like routing, pagination, subscription caching & management, server-side rendering, or database joins, they realize that the difficulty curve quickly ramps up.
Yet these are all things that are core to nearly every web app out there. And since they’re also trivial to implement in more traditional server-side frameworks, it can make it tempting to bail out on Meteor once you start hitting that wall.
Framework vs Platform
This all goes back to what I believe is a fundamental dichotomy.
From the start, the Meteor Development Group has viewed Meteor as a platform: they’d give developers a toolbox, some screws, and a bunch of wooden boards, and developers would then use these tools to build whatever they wanted, however they wanted.
This explains why MDG left things like file structure, routing and forms to the community. Even though these are key part of nearly every single web app out there, they’re framework-level components, not platform-level.
On the other hand, many community members (myself included) have asked all along for a real framework. One that would make choices for you, and give you easy blueprints to quickly build apps. In other words, not just a few two-by-fours, but an actual IKEA kit.
In this alternate universe, Meteor comes with its own router, models, forms, server-side rendering, and all the other building blocks required by modern web apps.
Of course, this would’ve required a lot more time and effort. In fact, most of these features were part of Meteor’s original roadmap, but MDG just never got a chance to work on them.
So we have to be realistic: creating this easy, all-in-one environment that just works out of the box represents a ridiculous quantity of work. After all, the fact that no other company than MDG has even tried to make it happen should be proof enough that it’s not trivial.
To be fair, Meteor has recently made some big progress in that direction thanks to the awesome Meteor Guide. But the guide is still brand new, and many in the community aren’t aware of it yet.
Awkward Place
The result of all this is that Meteor has ended up in an awkward place.
New developers love how easy it is to get started with it, but can get discouraged when they start struggling with more complex apps. And purely from a financial standpoint, it’s hard to build a sustainable business on the back of new developers hacking on smaller apps.
On the other hand, many of the more experienced developers who’d be able to handle (and help solve) Meteor’s trickier challenges are turned off by its all-in-one approach, and never even give it a chance in the first place.
The recent Blaze/React debate clearly illustrates this gap: as one part of the community is pulling Meteor towards React, Webpack, and the rest of the JavaScript ecosystem, another is despairing the loss of the very things that were making Meteor worth using in the first place.
A New Approach
But don’t despair. Meteor may have lost its first battle, but it can still win the war. So stay tuned for part 2, where I’ll explain why I believe 2016 can be the year Meteor finally fulfills its potential!
Please note that the views I presented here are purely my own, and are not endorsed in any way by either Tom Coleman or MDG.
