index.md 8.6KB
title: The State Of Meteor Part 2: What Happens Next
url: https://www.discovermeteor.com/blog/the-state-of-meteor-part-2-what-happens-next/
hash_url: c42e26d79e
In my last article, I talked about the current state of Meteor and some of the things that have been holding it back.
There’s reason to be hopeful, though. Indeed, I believe that while all this effort might’ve fell short of changing the world of web development, it did lay the groundwork for the true Meteor revolution.
Please note that the views presented here are purely my own, and are not endorsed in any way by either Tom Coleman or the Meteor Development Group. I don’t work for or with MDG, and do not take part in the development of Meteor in any way.
The Rise Of React
In the JavaScript world, the big story of the past few years has been the rise of the React ecosystem.
In many ways, React’s trajectory reminds me of jQuery’s. After years of debating the merits of Dojo, Mootools, ExtJS, and countless other libraries, the web development world finally settled on jQuery. It wasn’t necessarily the most powerful, comprehensive, or performant library, but it was focused on doing its job well and everybody was glad to finally agree on a common standard.
Similarly, while Ember and Angular might do more, and Vue or Mithril might be more lightweight, React is a well-regarded, good-enough solution that works for almost everybody, and has a serious shot at establishing itself as the new standard in front-end frameworks.
This is important because development standards are a winner-takes-all game: once jQuery became the default, it enabled an explosion of plugins and components built on top of it, and every JavaScript widget became a jQuery widget.
The exact same thing might very well happen with React. And that’s a very exciting thing for Meteor.
The Reactification of Meteor
Officially, Meteor supports three front-end frameworks: Blaze, React, and Angular. But Blaze (no matter how much we like it) is probably not going to stick around forever. And Angular is… well, it’s not React.
This might be a bit controversial, but I think the path that makes the most sense for Meteor is to drop any pretense of neutrality, and whole-heartedly embrace the React ecosystem.
This is already happening. A sizable part of the Meteor community (myself included) is currently migrating towards React. Not because we don’t like Blaze, but because using React means being part of something bigger.
And there’s even talk of one day replacing core parts of Meteor like Tracker or Minimongo with their React alternatives. Who knows, maybe GraphQL will be the way we finally get support for other databases baked into Meteor?
The Cure To JavaScript Fatigue
Of course, the question that everybody then asks is: “but wait, if we end up using React, Relay, and GraphQL, what do we even need Meteor for anymore?”.
The answer in a nutshell: as the cure to JavaScript fatigue.
Right now, using React requires cobbling together multiple bricks: React itself, its plugins, Webpack, some kind of data management system, to say nothing of a whole back-end stack. But Meteor is in a unique position to solve that challenge for you, and in essence become the best possible platform to build React apps.
This all boils down to one key fact: Meteor is the only framework that controls the whole stack.
Server-Aware Components
Whenever I introduce Meteor to someone new, I have to explain that unlike React or Angular, it’s a full-stack framework.
As I said in part 1, this turned out to be somewhat of a double-edged sword, as it also made switching to Meteor much harder compared to simply swapping out your front-end.
But this liability turns into a huge asset when using Meteor with React. This is because Meteor is the best platform out there to build server-aware React components.
The Meteor community has been spoiled with full-stack components like Autoform, UserAccounts, or Tabular for years. Just add the package, and you not only get both the server and client components, but also the key server-client data management layer.
Meteor To The Rescue
This is in stark contrast with the rest of the JavaScript world, who can’t even dream of such components. A great example of this is Facebook’s own FixedDataTable component.
Notice how the demo talks about “Client-side filter and “Client-side sort”? The documentation just assumes you’ll load all your data in memory and filter directly on the client. While server-side filtering and sorting may be possible, they’re treated like edge cases. And the same goes for similar components like Reactable.
Contrast this with Tabular or Reactive Table: in the equivalent Meteor components, it’s a given that some of your data will remain on the server, and that the component will help you manage it.
This is possible because Meteor being full-stack means developers don’t have to aim for a moving target. We know what APIs are available both on the client and server, and how to connect the two.
The best part: React developers can keep writing back-end-agnostic components. As long as they expose the necessary APIs, we can just write Meteor wrappers to magically transform them into full-stack components!
In fact, I’m putting my code where my mouth is, and lately I’ve been working on such a wrapper for Griddle.
Welcome To The Future
So this is my vision of the future of web development for 2016. React as a common front-end standard, and Meteor starting out as one of many possible back-end choices, but slowly becoming the one that just makes sense.
For my vision to come true, a few things will need to happen:
First, the Meteor Development Group will need to provide a clear story about the best way to build Meteor apps. It might seem like supporting more front-end frameworks will attract more developers, but I believe splitting up the community in three will hurt it in the long run. That’s why initiatives like Mantra and the Meteor Guide are so important. Independently of their technical merits, they give the community a common target to organize around.
Second, MDG will need to get Meteor itself up to snuff. Thanks to Webpack, React developers are used to niceties like modules, hot reload, and code splitting, and they won’t adopt Meteor if it means giving that up. The upcoming Meteor 1.3 release is already a big step in the right direction, and I’m impatient to see what the future brings.
Third, we’ll need to fill the package void created by moving away from Blaze. Packages like Autoform and UserAccounts will either need to be migrated to React, or new solutions will need to be created. This will achieve the double goal of both encouraging existing Meteor developers to port their apps to React, and attracting React developers to the Meteor ecosystem.
If we can manage all three, I believe Meteor will be in a great spot. And when I write my next “State Of Meteor” post one year from now, it’ll hopefully be much, much shorter!
You may be wondering what all this means for Discover Meteor, and to be fair we’ve been wondering the same thing! We hope to have an answer for you very soon, so stay tuned.