I agree - a totally complete analysis, Spyridon. I opened this topic saying how much I love Meteor. I do. It was its simplicity that I love. A telling point is that on none of my projects have I moved beyond 1.3.4.1. I appreciate the ability to use nodejs, but too many changes make me suspect of later versions, and I refuse to upgrade until I hear otherwise. I take advantage of ‘Meteor Classic’ binding, still use Blaze, and use only import for when I need them for npm modules.
I think this is something you can pinpoint as MDG making a bad decision (“everything global!”) and then correcting their mistake (“no, actually let’s use imports like every other Node app”), except that part of the community had trouble adapting to the new, “better” way. Blaze vs React is another example of this.
It just goes to show how hard it is to find a balance between keeping things simple (globals, Blaze) and embracing the ecosystem (imports, React). Personally I think MDG made the right call, but I can see why there’s a debate.
Meteor is so cool, I have already finished three projects with meteor and blaze, i don’t care about that it’s great or not, i heavy hope meteor grow up always. I think about the ruby on rails is very fast to develop before i meet meteor, but it changed when i try to create my first project, I was shocked by the meteor design and the meteor packages, awesome meteor, thanks to meteor creator and contributor.
I really enjoyed this article that closely relates to this forum topic. https://medium.com/@rkstar/a-journey-back-to-meteor-6fa513bd42c0
Good capture @Spyridon. But I think you answered very well the question “Why the existing users got concerned last year and half?” but not “Why Meteor is not more popular?”.
Meteor started very early, the Node.js ecosystem and NPM were still growing, React was not even there, the ecosystem was very different and fresh. Today npm is the largest package registry in the world and React made the 11 years old promise of web components a reality. Furthermore 2015 introduced major changes to the JS language with ES2015.
If MDG didn’t open Meteor to NPM and ES2015, the framework would’ve been detached and competing with the NPM ecosystem and that’s not wise. Thus the changes were necessary and they were to the better, but as you noted, the communication with the existing user base could have been much smoother.
But folks, this is behind us now, we know how the events unfolded and I firmly believe that today’s Meteor is much better positioned to be popular then the one two years ago. Yes there was uncertainty, yes the refactoring was painful, yes we’ve to write extra import statements, yes the communication could have been smoother, and yes the trust was shaken at some points. But major changes are never easy and I firmly believe MDG did the right thing to keep Meteor relevant. So I’d urge the community to move forward and inject some positive tone to this form to make the experience much more pleasant for the newcomers and everyone else thus contributing to making Meteor more popular.
Looking at things objectively, as of today, we’ve a much more flexible and capable framework then what we had two years ago, it’s still backward compatible, we’ve a better guide/docs, new packages, redis-oplog, Galaxy hosting, access to NPM packages, Apollo data layer, open source Kadira, dynamic imports, and the core is still improving. Meteor came a long way in the last two years and we’ve many reasons to be positive, but I don’t think it’s getting the marketing and credit it deserves.
A more fitting title would be: Meteor is great, let us make it even more popular .
I think there is also another reason, it has to do with the business model. This depends ofc on how IT companies work in different countries but in many countries its the same. Big key players in the IT industry have a big network of authorized resellers and partners. Microsoft, oracle, ibm are really good with this. Companies tend to try to become partner (gold silver etc) with these key players in order to gain access to opportunities and connections. Then goverments, big corporations , banks etc tend to buy things from big resellers based on these key players. The reason they do it is because of trust, many years in the market, connections etc. So if you want to go in the big boys arena you might need to work with a key player and become a partner. In that case forget about open source things or startups. This is why asp mvc is really popular today among enterprise business applications (Example). When you go to make a sale and you tell these dudes, its based on a new open source you get the red card straight.But if you say its based on ms/oracle/ibm etc then you get their attention. The same then goes for further sales. Sales people usually say things like “buy this, bank A and bank B has it already for years”. You get the idea. Also there is a ton of professionals around these key players. E.g. there are microsoft certified IT professionals, these dudes cant just quit their experiece and certifications. Same goes for all key players. Some companies prefer professionals with certifications, if you hire an oracle certified professional what will he propose as the development platform? It is how the IT industry works. In my opinion perhaps any new platform should try to get access to this key players perhaps through some sort of collaboration or partnership. It will open doors to a whole new world of people there.
and things get really more advanced from there on. e.g. now some companies are moving to the cloud. whos cloud will they trust? obviously knowing how these customers think they will go for a key player. Its about trust, years, brand name etc. But its even more about knowing that even 10 years later this company will still be a key player. Just as an example about the cloud options please check which cloud option has implemented what it needs for the new european law on privacy and data (known as GDBR). Immediately half of the cloud providers are taken out. I remember for instance people knew and worked on knockoutjs. The minute microsoft placed knockout on its asp mvc template alongside jquery , suddently everyone and i mean everyone acted as if they discovered the wheel.
By the way, where’s the Meteor Manifesto gone? I cannot find even cached copies anywhere. It was really nice ‘dream’ which came true but disappeared afterwards.
Do you mean the seven principles of Meteor?
- Data on the Wire. Don’t send HTML over the network. Send data and let the client decide how to render it.
- One Language. Write both the client and the server parts of your interface in JavaScript.
- Database Everywhere. Use the same transparent API to access your database from the client or the server.
- Latency Compensation. On the client, use prefetching and model simulation to make it look like you have a zero-latency connection to the database.
- Full Stack Reactivity. Make realtime the default. All layers, from database to template, should make an event-driven interface available.
- Embrace the Ecosystem. Meteor is open source and integrates, rather than replaces, existing open source tools and frameworks.
- Simplicity Equals Productivity. The best way to make something seem simple is to have it actually be simple. Accomplish this through clean, classically beautiful APIs.
Oh man. I wish I could press “like” more times or there was a “love” button or something.
MDG totally delivered on those seven principles. And this was over four years ago. Since then, I’ve never seen anything come within a bull’s roar of Meteor for full-stack developer experience and productivity.
In my opinion, the only things missing from complete perfection were 1) keeping the initial uncached payload to a reasonable size and 2) cheap scaling. The first one is being fixed in 1.5 with code splitting. I think I’m going to have to rely on Moore’s Law for the second (or redis-oplog
).
“Meteor classic”, as outlined in those seven principles, still floats my boat.
Couldn’t agree more. Fully delivered back then and still delivering today.
Loving 1.5 BTW!
Wow, looking at those 7 principles I’ve to say MDG delivered and held their ground!
That may actually be true. But the main part that did some damage is that they didn’t really communicate that they were going to do this properly, and people found out through the tutorial, which I believe it was a bad decision to make a “my first Meteor project” tutorial that is focused on experienced users, rather than actual new users (as the tutorial section implies).
Up until that point of the React thing, Meteor was actually gaining in popularity super fast. There’s some graphs around somewhere in old topics that showed growth start declining around the periods I mention. The graphs were constantly moving up until they became neutral around the time period I mention, with the first drops ever happening around the time of the few months following 1.3 release.
I remember this because I mentioned in a post around then, you would think with the NPM support, it would be a time for improvement, but it seemed to be the opposite. It seems that the discontent with the changes 1.3 brought did more damage than it actually brought in new users - at least at that time.
(Edit: Found it!: https://forums.meteor.com/uploads/short-url/nOUp5meWfX1RgOIPXqJJfkcHgHY.png - Now the thing to note on this graph, the part where that dip started dropping? IIRC, that was the month directly following the release of 1.3 - that should have been a period for growth with NPM finally opening, but it actually DROPPED. The only negative thing that happened at this point was what I mentioend earlier - the tutorials changed, NPM support required refactors we were not made aware of beforehand, and people began to question the direction of Meteor, without any solid answers that had anything reassuring about the future. The answers - such as focusing on Apollo or moving completely to NPM or removing backwrads compatibility, only led to more worry since they could not commit to saying anything.)
This is also, coincidentally, when the “Meteor is Dying” posts started appearing.
We can say the reason for the growth to slow down may have been anything, but I doubt it is a coincidence that the community turned from heavily positive to negative around this time, and that just so happens to be when growth started to slow.
You can also see me mention this change when returning to the forums - The State Of Meteor Part 1: What Went Wrong
Yes! That is exactly it.
I think those 7 principles are great, and those are the exact reasons I became interested in Meteor.
But during the times I mentioned in my post, they quietly removed that from their marketing. Some of them still remain, but some (such as simplicity equals productivity) were completely removed.
Once it was discovered that they removed this from the pages, at the time of worry in the community, it did no good to alleviate peoples worries. It seemed like Meteor might have been changing directions at that time to something people did not want, because I don’t know a single person who uses Meteor that did not support those 7 principles.
I completely agree with you that Meteor adoption got a hit when it was going through the changes last two years or so. I was concerned as well, I had two apps running on blaze and didn’t know what was going on. However what I come to appreciate later is that these changes from MDG were logical, important and for the better to ensure that meteor stays relevant in the coming years. So short term pain for a long term gain.
I for one has been using many of the NPM packages and react libraries and that was allowed by the changes MDG introduced, had they not made those changes, I’d probably be looking for something else by now. I mean NPM was and still growing exponentially and now it’s the biggest software repository ever, why would Meteor developers re-invent the wheel? And this is fully aligned with their principle of embracing the ecosystem instead of competing with it.
Overall in my opinion Meteor needed better communication strategy during those changes and it needs better marketing nowadays, but from a technical standpoint the changes were all to the better.
The good thing is that those uncertain times are behind us and 1.5 is on the way
Yep… communication was the #1 issue. They have not “ruined” the software itself as the fears suspected may happen. But with proper communication, most of that worry could have been alleviated from the beginning. At least tell users what they should be expecting before it happens, so it doesnt catch users off guard!
And returning to some proper new user tutorials, and saving “thorough best practice” tutorials for the Meteor guide, would go very far in helping establish some growth again!
deployment is the most easy deployment on any app takes less than 1mn to setup and deploy the app to any hosting from AWS to Rackspace!
Please help us spread the word about Meteor 1.5, we are going to do a lot of that in the coming weeks as well!
you’ll need to spend more on marketing and some ads a little bit
My main app is deployed to Galaxy, but for future apps, I am wondering what you use to deploy that makes it so easy?