It looks my last two posts hit a nerve, to say the least.

The Hacker News effect in action

Both parts shot up to the top of Hacker News, and both threads received over a hundred comments. Here are a few stats in case you’re curious:

The State Of Meteor Part 1: Growing Pains:

The State Of Meteor Part 2: What Happens Next:

Overall, that’s 587 comments total! I haven’t seen this much debate online since that white and gold dress!

As you might imagine, I couldn’t reply to every single comment. So I thought I’d wrap this whole thing up by addressing a few of the most common reactions.

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.

“Blaze is fine! I use it and it works great!”

If you like Blaze and wish it would just stick around forever, I feel your pain. Over the past couple years I’ve used Blaze and written about it extensively, and I think it’s great too.

But there’s two simple reasons why I think it makes sense to move away from it, and they have nothing to do with the technology itself: first, it will free up MDG’s time to work on things that are even more important. Second, it will help Meteor piggy-back on React’s popularity and reach a broader audience.

“I like Blaze because it’s simple, React is too hard to learn

You know, I originally thought the same thing. When I originally learned React (through the awesome React for Beginners) series it seemed a lot more complex than what I was used to with Blaze.

But after actually using React in a real-world Meteor app, I’m starting to change my mind. A big part of the initial hurdle with React wasn’t due to React at all, but to all the other new things I was learning together with it, like ES2015 and Webpack.

React itself isn’t much harder to use than Blaze, especially since you usually only use a subset of React’s features.

Practically speaking, the only major difference with writing Blaze code is that React requires you to aggregate all your reactive variables in one place, instead of letting you directly pepper them throughout your template code. Once you get past that, it’s pretty much the same thing.

Doing the official Meteor+React tutorial is a great way to see that React isn’t that scary after all. Also stay tuned for a “React Primer for Meteor” blog post coming soon!

“We can’t just jump to the latest new shiny framework every 6 months! We need stability”

I think this argument is a bit disingenuous. We’re not talking about jumping to a random new front-end framework every 6 months.

We’re talking about switching once to a framework that A) has been around for a couple of years already and B) is used in production by the largest web app on earth.

I would be willing to bet that React will still be around 3 or 4 years from now. In fact, I asked Dan Abramov to address this argument, and I quite liked his response:

And at the end of the day, if you value stability above everything else then Meteor is probably not the best choice for you. While MDG always does an admirable job of making updates and transitions as easy as they can be, they have also made it clear that they intend to keep pace with the rest of the JavaScript ecosystem (as they should!).

“React isn’t even that great! It’s not as good as Angular 2 / Elm / Cycle.js / Aurelia / Scoobydoo.js”

Again, technology isn’t everything. Other frameworks might very well be superior in certain aspects, but React has the (relative) stability and broad user base that make it attractive to build on top of it.

I’ve also yet to hear any horror stories about people picking React and regretting it down the road (although let me know in the comments if that happened to you). In other words, React is quickly becoming something nobody will be fired for picking. Plus, you know, React Native doesn’t hurt either!

Oh and no need to google Scoobydoo.js. I just made it up.

“But JSX! HTML in JS! JS in HTML! What about the separation of concerns!”

I’ll be honest, I quite like Spacebars, Blaze’s templating language. And I do think {{#if}} and {{#each}} look a bit nicer than using the ternary operator and map.

But in the grand scheme of things, these are really minor things, and you get past them pretty quickly. And I have to say having everything in the same file is a definite plus for productivity.

I also don’t believe “separation of concerns” to be much more than an empty buzzword people like to wave around, but I can see how some might worry React will make working with non-developers more challenging.

Thankfully React has its own solution in the form of functional stateless components. By using the smart/dumb component pattern and simplifying your components, you can remove a lot of the JavaScript logic from your components, making them a lot easier for even designers to handle.

“Meteor shouldn’t pick sides, it should leave the door open to any front-end framework”

I don’t necessarily disagree with this. I absolutely believe Meteor should be compatible with as many front-end framework as it can.

All I’m saying is that if a new developer comes along and asks which front-end framework they’re supposed to use with Meteor, the answer should be “use X” (with X being React), not “use Blaze, or maybe React, or maybe Angular. They each have their pros and cons really”.

You also can’t reasonably expect package maintainers to maintain three versions of their package’s front-ends.

On the other hand, what we definitely should do is strive to make packages front-end agnostic, by splitting them in two for example. Think autoform-core and autoform-react for example. Then if someone else wants to come along and build autoform-angular, then why not!

Again, I’m not advocating locking down Meteor at the technological level, just having a clear main target for the community.

“What we really need is SQL support!”

Any thread about Meteor needs at least one person mentioning the lack of SQL support. Here’s the thing: if Meteor truly wanted to support SQL the same way it supports Mongo, it would require writing an entire “MiniSQL” implementation of SQL that runs in the browser.

That sounds like a huge technological challenge, and probably not a very productive use of developer time.

What will probably happen instead is that GraphQL will make the whole debate irrelevant. You’ll use GraphQL on the client, and whichever database you want on the server.

“What’s with all the negativity? Meteor is pretty awesome already!”

That’s right, and I apologize for the overly-negative original title of the first part (“What Went Wrong”).

One thing I didn’t make clear enough is that a lot of the frustrations I expressed in there were the results of using Meteor over the past three years, which includes the very early days.

Someone coming into the Meteor world today will have a very different experience, and that’s great. Independently of the whole Blaze/React thing, Meteor has definitely accomplished a lot and is without a doubt one of the most productive software platforms out there!