Eh, to a point. But to be honest, a LOT of the problem was very bad communication.
Let me take you on a trip of what went through many of our minds…
It wasn’t just “React support” at first. They said they were going to do a complete switch to React. And for Blaze support, they were going to make a package to use Blaze inside of React.
React was pretty new at this time, and of course, there’s going to be a backlash as people don’t want to be “forced” in to a specific view layer, and it seems other users would be out of luck. They updated their comments on the situation, but it was still somewhat vague, and for months people didn’t really know what was going on in to the future.
Then with 1.3, all they talked about for months was NPM support finally coming. You can use NPM packages in Meteor. Awesome, right?
The excitement died very fast when people went to check out the new guide/tutorials, and rather than “Meteor with NPM support”, what they seen was very different. The “my first Meteor project” tutorials had nearly double the amount of code that the original had, to do the same thing.
Unluckily, we hired employees right before this to assist with our project. Our job applications were simply looking for front-end developers who knew JavaScript. That’s all you really needed to know pre-1.3 and it was easy enough for them to pick up. But the tutorials were no longer targeted at that type of user. The tutorials confused the heck out of our new employees. Before, you can just hop in the tutorial, with little code you see so much magic, and really have a general idea of the Meteor mindset. Now, taht’s not the case. And a big problem for us, we had just hired employees that had to be trained.
I had to end up training them myself, as DiscoverMeteor was too old, and the new tutorials were not sufficient.
A number of us mentioned this wasnt really good for a “my first project” tutorial - it definitely did not help users in that situation. We recommended multiple tutorials - one similar to the old for new users, and put the new one in the guide for “Best practices”. I don’t believe they ever did this, and I’m sure it hurt many peoples impressions of Meteor.
Furthermore, even experienced Meteor users were surprised at what they seen in this “New user tutorial”. Import statements everywhere??? The response was “This is not Meteor - I moved to Meteor to get away from having to do import statements! What’s going on?? Is my project even going to work???”
I was personally afraid to even update.
It’s only through comments on the forum where I found out that there was backwards compatibility for the old Meteor file structure (client/lib/server folders and no imports). But there was a catch - “backwards compatibility is only temporary because we’re moving to NPM”. No more information than that really.
Now put yourself in the position of a business with a large application with thousands of files. How would you feel to know that you are only going to be compatible with Meteor for an undetermined amount of time? And what would the benefit of this new system be? It would not help our project at all. (Lazy loading was not yet announced, so there was no true benefit, it was just a refactor we “had” to do.)
Around this time, they announced Apollo, the new data layer. Also, they modified the actual Meteor page. They used to have a bunch of key points about what Meteor was - including things saying how it was easy and pleasurable to use, and fast to work in JavaScript (I do not recall exact wording). Basically, they completely removed those things from the marketing.
Again, horrible communication. It looks as if Meteor was dropped for Apollo. It looks like they aren’t even targeted the few things that made Meteor “Meteor”. Is Meteor even going to be the same thing in 6 months? Are they just going to keep making you refactor without any more focus on being pleasurable to use or quick development time? Are they really betraying their whole user base who loved what Meteor is NOW, and are they giving that up to potentially get some more hits from NPM users…?
Then take a look at Meteor. Now Blaze they officially announced was not supported anymore. They seemingly are still focusing on React (even though they said Blaze/Angular/React would be “equal”). They are going to be dropping Atmosphere for NPM in an undetermined amount of time (with absolutely no information on what we are going to have to do once that happens - do we just lose all the atmosphere packages???). They seemingly were not focusing on speedy development anymore after changing their marketing. So what’s left of Meteor that made it great? The data layer.
But what about Apollo? The team moved to working on Apollo. That IS a new data layer. And their marketing thought this was a wise time to focus on how Apollo will be available for ANY NPM project to use… WITHOUT having to use Meteor, you can just use Apollo in any NPM project!
What does logic say at this point? Meteor itself is seeming to lose support on every aspect of itself. And now the team has moved to Apollo, which is the new data layer, which was the single best part of using Meteor, and anyone can install Apollo in to their project by itself without needing Meteor???
Looks as if Meteor was abandoned at that point.
Of course we see now, that Meteor was not abandoned. But the whole situation did not seem that way for much of the time this was happening. Poor communication made every step look worse and worse. It made users worried (including myself). Rather than saying something to alleviate these worries, they either responded vaguely, indirectly, or did not respond at all.
Even to this day, I don’t really have an idea what’s going to go on with Atmosphere. I hope they would have some sort of tool to help convert the packages to NPM, but I have no idea if that will happen. And if it’s anything like the NPM support in Meteor, you might have to jump through some hoops to refactor some of the packages to work (if bindEnvironment-similar code does not work).
Regarding imports, they should have prepped users beforehand. They were excited expecting Meteor + NPM, not a trade-off. They did not even annoucne anything about backwards compatibility officially - we had to find out on the forums. They have lazy loading soon, so that’s not as painful. But it would have been much better if they just communicated that they will be keeping backwards compatibility going until at least lazy loading is ready.
Regarding all this refactoring required, it would be nice if they give us some tools to assist with any major refactors.
Regarding tutorials, it was an easy fix, I’m not sure why they still have those god forsaken “My First Meteor Project” tutorials up there that are much more difficult than someones first Meteor project should be.
Regarding Apollo… that whole situation should have been a positive thing, but the way it was communicated made it more worrying than anything, especially when the marketing changed directions at the same time. Just made it look like Meteor was dying (this is where those rumors actually came from).
Without any communication, most of the changes proposed just seem unnecessary more than anything. People want the software they love to become better and better, and it sucks if your software begins to lose the things you love, just to add some new features that will not help your project at all. Makes users feel like fools for supporting Meteor, if they will be abandoned in order to try to make Meteor reach further. It loses trust. In marketing, there’s not many things that hurt your image more than losing trust of your customers.
Again, I want to stress that MDG still hasn’t made any major mistakes (outside of communication), and I hope it stays that way.
But I can’t say users did not have a legit reason to complain, or blame it on JavaScript. Most of these issues could/should have been handled better.
