An Open Letter to the New Owners of Meteor
Disclaimer: these are my personal views, and I have no relation with either Tiny or MDG. So take this entirely unofficial opinion with a grain of salt.
Meteor.js was first unveiled publicly in April 2012. Six months later, I started writing a book about it with Tom Coleman, the main creator of (among many other things) Meteor’s package management ecosystem.
That book, Discover Meteor, went on to become the main reference for the growing Meteor community and became my main focus for the next few years, spanning countless updates, blog posts, podcasts, and even a very cool t-shirt which I still wear to this day.
In parallel I also launched Telescope, an open-source Hacker News clone app built with Meteor which was in its day probably the largest open-source Meteor app in terms of GitHub stars.
Telescope then morphed into Vulcan.js, a full-stack React/GraphQL app framework which is alive and well, and still uses Meteor under the hood.
I’m saying all this to give some context, and show you that I’ve been involved with Meteor from the start.
Tiny Meteor
So with the recent news of Tiny acquiring Meteor from MDG (the Meteor Development Group), I thought this would be a good time to reflect back on Meteor’s past and potential future, and maybe give the new owners some advice (and do so in a more diplomatic way than last time).
Why Apollo Succeeded (And Meteor Didn’t)
The best way to understand what happened with Meteor is to look at Apollo, which was built by the same company and much of the same people.
In many ways, Apollo is almost the complete opposite of Meteor: whereas Meteor is a broad framework that includes modules for everything, from email sending to templates to user account management, Apollo is much more focused on GraphQL data loading.
And whereas Meteor privileged a simple, “it just works” approach that entailed a lot of magic behind the scenes, Apollo leaves a lot of manual work to the end user, sometimes to the point of making seemingly simple operations very complex (just look at how they both handle something like updating your client-side cache after a server-side mutation).
This is by design: despite its popularity in those early days, Meteor actually completely missed the mark of the enterprise market, and so MDG took care to adjust their aim when it came to their second shot.
Without the enterprise market, Meteor simply couldn’t hope to ever justify the millions of dollars in funding raised on the back of it, which made a pivot inevitable.
The Enterprise Market
So why did Meteor fail at getting the coveted enterprise market? There are a few main reasons.
Perception
Meteor initially demo’d a feature that let any client modify the server-side database. While this feature was always meant to speed up development and obviously should never be deployed in production (the package that enabled this was even called insecure), many people failed to understand that and as a result Meteor gained a reputation of being weak on security. The fact that Meteor initially picked a debatable “allow/deny” architecture that made it very easy to get things wrong and expose security holes in your app didn’t help. As a result, Meteor had a hard time shaking its initial reputation as a “prototyping” tool that wasn’t suitable for larger projects.
Performance
There’s also no avoiding the fact that Meteor simply didn’t scale well, almost by design. Because of its all-real-time-all-the-time architecture, Meteor put a much bigger load on any server than comparable non-real-time frameworks.
And, maybe because real-time was such a big selling point for the framework, Meteor never offered a way to “turn off” real-time when you didn’t need it, meaning every single Meteor app had to pay that real-time performance tax whether they wanted it or not — at least in those early years.
The Monolith Problem
The final nail in the coffin of Meteor’s enterprise hopes and dreams was just that at the end of the day, enterprise customers don’t want a one-size-fits-all monolith that locks them in to a single ecosystem.
Sure, increasing your productivity by X% by adopting a more integrated framework sounds great in theory, but getting an entire team to drop their current stack completely and jump on the Meteor bandwagon is a big ask.
Compare that with React, Vue, or even Apollo, all of which only target a single part of the stack, and all of which can be added incrementally into existing applications.
And it’s not just a theoretical problem: even today, Meteor’s idiosyncrasies can make using third-party tools like Storybook quite a lot harder than it should be.
Boiling the Ocean
Still, even without the enterprise market, Meteor was growing steadily with hackers, students, and small businesses, and MDG could’ve had a nice business on their hands in the form of Galaxy, their hosting platform.
At some point though, Meteor just couldn’t compete with the rest of the exploding JavaScript ecosystem.
- Blaze, its template engine, was good, but it wasn’t as good as React or (later) Vue.
- Its bundling system could do some amazing things, but it wasn’t popular as Webpack, and to this day still can’t do hot module reloading.
- Its data layer was amazingly simple and easy to use, but it didn’t have the flexibility and enterprise appeal of GraphQL.
- Its server worked, but couldn’t do SSR as well as Next.js or serve apps as fast as static solutions like Gatsby.js.
You get the idea. Meteor was under attack from all sides, and the work of providing superior alternatives for every single part of the stack would’ve required hundreds of developers.
Looking back, the obvious solution would’ve been to adopt all these new tools into the Meteor stack and discard Meteor’s own home-grown solutions (which is exactly what we’re doing with Vulcan.js by the way — more on that at the end of this post).
But Meteor was paradoxically prevented from doing just that by its own success.
The Meteor Community
Meteor still has a small but active community, but years of neglect by MDG have whittled it down to the die-hards–and to people who use Meteor because they have to.
The most brilliant and forward-thinking people have long since left the community–and before you get too offended, know that I don’t include myself in that group.
I mean people like Vue founder Evan You, or the Chromatic team, who also maintain Storybook — which was itself created by the legendary (at least within the Meteor community) Arunoda, who now works at Next.js.
(The fact that so many figures of the JavaScript community all came from Meteor is both inspiring and a little sad. You can’t help but wonder what could’ve happened if they had all stuck around.)
All this means that the people left quite like the way things are. And that’s definitely made it tricky to evolve the framework over the years. Change things too much and you lose your last die-hard fans. Don’t change them, and you kill your chances of appealing to anybody outside the community.
So today, the community is split between the “conservative” Meteor users who want to keep using Blaze and Minimongo despite these technologies having zero adoption or support outside the Meteor ecosystem; and “progressive” users who have adopted React and Apollo–and as such already have one foot out the door.
Meteor Today
So the current situation is a bit paradoxical: technically speaking, Meteor is in a better place than ever thanks to the heroic efforts of Ben Newman, Meteor’s lone part-time maintainer at MDG. But the question is, does it even matter?
Maybe this will be surprising given the overall pessimistic tone of this post, but I think it still does. To this day, no other framework has come close to replicating Meteor’s initial vision of a single integrated JavaScript full-stack framework.
And given how complex JavaScript development has gotten over the years, I think it’s fair to say there’s still a big appetite for something like Meteor (even if that appetite doesn’t come from big enterprise companies — at least not at first).
Next Steps
I feel like Tiny is kind of in the position of those guys who restore old steel implements on YouTube. They have an old, rusted tool of some kind on their hands, and their job is now to turn it into the sleek, polished object it was meant to be.
- As a first step, I would probably try and map out the main players in the community. Read the forums, see what’s going on on GitHub, and talk to as many people as you can.
- Then, identify one or two major technical sticking points (the lack of hot module reloading would be one of them for me) and throw money at those problems until they’re fixed. A good start would be doubling Ben’s salary and hiring him away from MDG if at all possible.
- Third: get rid of the “old” Meteor. Keep backwards compatibility with Blaze, Minimongo, and so on whenever possible, but make it clear that they’re deprecated. Embrace Apollo and GraphQL. Don’t be afraid to pick sides even if it angers some people. Rewrite the docs from scratch to be geared towards this new approach.
- Fourth: rebrand. Meteor needs at least a “2.0” tag if not a complete name change to break with its poor perception over the last few years.
What’s so delicate about this situation is that both of the more “obvious” paths lead nowhere: keep things exactly the same, and the best you can hope for is to slow down Meteor’s current decline. Change everything, and you’ll lose the value of your acquisition since the current user base won’t follow along.
What happens next could really go either way. If Tiny hires the right people and makes the right move, it could really breathe a second life into the framework. Considering that Meteor got where it is now with barely a single full-time employee working on it over the past couple years, one can only dream of what could be accomplished with a full team!
But things could also go really wrong. If Tiny acquires the Meteor brand without hiring any of the Meteor team, it might have a hard time finding good enough talent to make the necessary changes. If for whatever reason Tiny can’t take the framework to the next level, it might end up deciding to shut the whole thing down to avoid throwing good money after bad. After all, Meteor is only one project among many others in Tiny’s portfolio, and they won’t have the same sentimental attachment towards the framework that MDG always had.
So it won’t be easy, and if MDG –which was literally composed of some of the best developers I’ve ever known or heard of– couldn’t do it, then it remains to see if Tiny can.
Still, I’m hopeful. So here’s to seven more years of Meteor!
Addendum: Vulcan.js
I didn’t want this post to turn into an advertisement for Vulcan.js, but at the same time it’s still very relevant to the discussion at hand. So here’s a quick, easy-to-skip explainer to wrap things up.
Vulcan.js grew out of the Telescope project. As more and more people adopted Telescope, a lot of them started to customize it in ways I never considered. People really enjoyed the starting point that a Reddit or Hacker News clone gave them, and were able to easily customize it into all kinds of communities and social sites.
So with Vulcan, we decided to focus one layer deeper and look at all the primitives of a modern web app: data loading, forms, datatables, accounts, permissions, SSR, and so on.
These are all things that I’m convinced Meteor would have eventually tackled on its own if it had kept the same trajectory. In fact many of them were part of the original Meteor roadmap, but as they got delayed over and over the community started taking things into their own hand.
And as Meteor did its best to preserve its original technology yet slowly lost track of its original vision, Vulcan went the opposite way: we kept the vision but abandoned Blaze, Minimongo, DDP, and all the rest in favor of GraphQL and React.
The result is that today the only visible remnant of Meteor in a Vulcan app is the user account stack, and even that is going away soon. In essence, Meteor bundles and serves your app, but everything else is then left to the same modern JavaScript technologies the rest of the ecosystem also uses.
But what makes Vulcan unique is also what makes Meteor unique to this day: its full-stack nature. Because Vulcan and Meteor span the whole stack from server to client, we’re able to make both sides of the equation work together seamlessly.
As an example, because Vulcan’s GraphQL API is generated from a central JavaScript schema, we’re able to reuse that same schema to generate forms and datatables that automatically adapt to your data.
In other words, just specify that field createdAt is of type Date, and not only will the resulting GraphQL field have the correct type, but the resulting form input will use a datepicker; and the corresponding datatable column will also feature date-based filtering controls.
This is what I mean by preserving Meteor’s original vision. Despite the pitfalls of a monolithic stack, full-stack apps also provide very real advantages and enable things that only become possible when you can control the entire stack.
The big challenge is benefiting from those advantages without falling prey to the drawbacks. And I really believe that the way to square that circle is to embrace the existing ecosystem, and focusing on being the cement rather than being the bricks.
Of course that’s just my own vision. But if you’re at least a little bit curious, I definitely encourage you to give Vulcan.js a try!
