As you can read further down from the post that you just quoted, we made this bet too. With an enterprise-level SaaS. And I am happy we did. No matter what MDG does, we will always have the technical ability to change/maintain our own code.
1 Like
If I was starting a new app tomorrow, I’d still bet on Meteor. What’s more, I’d still use Blaze, globals, pub-sub, tracker, package-based architecture – all that bad sh*t (well … maybe not Session) – because it still all works just fine with 1.4.2.3 and I know I can build something pretty awesome in a fraction of the time I could with any other stack.
If things stop working with 1.5, so what? (Not that that’s likely, given Meteor’s amazing track record with back-compat.) It’s already got everything I need and more. The only missing piece for me was cheap and easy scalability and, with the advent of redis-oplog, that may be the last real barrier removed from starting any project with the old school Meteor I know and love.
Then again, I’m not the target market. I’m the one-man-shop, evenings and weekends coder. If I had a team working on a project, I might be bothered to learn React, modules (and ES6 in general), Apollo, etc.
10 Likes
Unfortunately you are so wrong. I realky do try to get help with something and i propose changes. That means, i fullfill at least 2 of these Points.
But People like you always think to have the right to judge others. So i now not gonna fight anymore on this point.
In my eyes, you don’t have any right to do so and that’s enough for me.
I like to focus on the questions. But thanks anyway for your input.
The way I see it, is a lot of users around these days are using Meteor in production or at their business, etc.
In this case, a lot of us just kind of want some… reassurance? We don’t really know what’s going on, and there have been warning signs (being told things are going to change, these things are just temporary, certain aspects are going to be deprecated, and so on). We heard a few times “we should be happy in the end”… but we have no idea of current status, or progress, or what the plans are for 3 months from now, 6 months from now, a year from now, etc.
The key here would be communication. Which we have also been told would be improving moving forward. But has it, really? No… not really. Which then makes it a trust issue.
That’s usually not the dealbreaker with development software, that’s usually once things such as security vulnerabilities are found. At that point, it’s not a “so what?” anymore. It means your live app in production is vulnerable.
I obviously still have faith in Meteor since I am still developing in it. I just wish it actually showed that MDG cared about those of us in my situation - who supported Meteor for a long time, pushed to get it in to business, and now are not really benefiting from the last 6 months of updates, and worried about functionality of our apps in the future and/or security patches.
I would be completely fine sticking to this version of Meteor, assuming any major vulnerabilities would be addressed… Without that, it can be said “noone is forcing you to upgrade”… but if vulnerabilities will not be patched up, we ARE being forced to upgrade, or lose our app.
1 Like
I think the biggest problem is that we have been communicating a lot but haven’t done a good job of doing it in a focused and productive way. It’s becoming pretty clear that individually responding to a lot of forum threads isn’t really that helpful at improving the state of communication.
I bet your app is much faster both in production and at build time in 1.4.2 - and that’s been the main set of updates in the last 6 months. So what updates are you referring to?
1 Like
I can agree with this. Forum posts do help a bit, but they get drowned out. Also, things change, and forum’s cant really confirm if anything changed or not.
Without an official announcement, it’s hard to take things too seriously.
Thing is, as a user of Meteor at my business, with our business app deployed on Galaxy, I’m pretty sure that MDG is aware of the cause for concern. It would really go a very long way if an official announcement were to mention that our concerns are recognized and there’s a plan of action to support us.
Without that, it feels that although we’re supporting Meteor and we’re in it for the long haul (with live applications), we’re not really valued long-term.
Yep that’s probably true about the speed. We have plans to upgrade Meteor version in the future, but some more high priority updates first.
Regarding my comment about last 6 months of updates, I was mostly referring post 1.4. With development being moved to Apollo. MDG announced the future Meteor updates will be integrating Apollo in to Meteor, and then moving over the NPM completely. So to be honest - the future updates are a very scary situation.
We don’t know how Apollo is going to change Meteor, and pub/sub is usually fairly condensed code, so if all we have to change is that it should be reasonable. But then with that combined with moving over to NPM, and not a clear plan on how Atmosphere is going to be handled, or if it’s just going to be completely deprecated, or if there’s going to be any way to more easily repackage our Atmosphere packages as NPM, or if Atmosphere packages will even work with Apollo… it’s again very scary to think about.
As mentioned in earlier posts, I would be fine staying on an older version of Meteor - but the big concern is major vulnerabilities or security updates. That would completely ruin any possibilities of sticking to an older version.
We’re supporting you guys and want only the best for Meteor, we just hope we’re not forgotten in this transition Meteor is going through…
Case in point:
I think the conversation/comments surrounding the workload at MDG is another good example of a lack of communication negatively impacting the community. It’s probably dozens of times now I’ve heard “Ben is the only one working on Meteor” in posts, podcasts, etc. – without a public-facing response from MDG.
I think that many of the devs here who have been with Meteor since <1.0 realize that it’s a product that is beginning to reach stability, make better use of community contributions, etc. but the forums aren’t a place to address that type of concern, in my opinion. Just as these forums aren’t really the right spot to maintain the Apollo conversations – Meteor-Apollo integrations, sure, but Apollo !== Meteor, and I can’t help but think that there is something missing here in the separation of concerns, for lack of a better phrase.
As always, 
Meteor and MDG and want to see the best for the products, team and end users.
On the other hand, I wrote an app 2 years ago in Meteor 1.1, Blaze, Tracker, etc. (then upgraded to 1.2 mid stream - without too much trouble even). This year, I dusted it off, ran all the updates and it took like maybe 2 horus to get everything up and running on 1.4.
From what I can tell, Blaze, Tracker, Mongo, etc. will all be supported going forward, they just aren’t treated like a single product anymore. But I can’t see why that’s a problem. It all still works very well.
The only problems I’ve had with Meteor are more micro - like when they updated LESS a few versions back, and it broke like half the packages I was using (most of which just needed a minor update). But that kind of thing happens on any significantly useful platform.
2 Likes
Yeah, but we’ve been told that the backwards compatibility is likely only temporary. This is a lot of the reason I have worried. Some have said backward compatibility is not going anywhere though? No idea really, not sure what the MDG team is up to.
That’s the primary concern.
I also just want to see Meteor do as well as it has in the past. Ironically, since Meteor tried to address the major concerns with the platform, we have hit a bit of a decline. You would think the opposite would happen. But reality states otherwise.
I personally feel that’s because Meteor’s improvements have been focused on trying to make “Users who do not already use Meteor potential new users”. But I believe the traction was lost on current users of Meteor. We became worried and unsure of direction, and that shows in the morale of the community, hence that actually lessened the amount of new users coming in.
Of course there’s also the concerns of “If everything changes, it isn’t really Meteor anymore, is it? Why not just use React straight up?”. That’s another concern I think should be addressed publicly by MDG.
Also, I believe the feedback kind of got MDG off track on what needs to change. They heard the main complaints and tried to address them, but at that time, Meteor was still growing very rapidly. This is before Apollo, before NPM functionality. At this time, non-Meteor users of course would say they want things like SQL and NPM. But people currently using Meteor at that time were more looking for improvements to what they already have in their projects. Once they see all the updates not only don’t address any of the issues current Meteor users were having (such as scalability) and instead focusing on things they don’t need or won’t be using, but on top of that, adding these things may make Meteor much more verbose, require huge gigantic refactors in order to make their projects work, and potentially lose many of the time-saving features Meteor has… I believe this did more to damage Meteor than it did to actually improve/bring more users to Meteor.
I don’t know, I just think proper understanding of the concerns of Meteor developers, followed by communication to users as to why we don’t have to be worried about these things, and a very clear description of what is going to happen in the future, would go a very long way in giving Meteor some traction again.
I mean, we all know what the roadmap says. But what about all the things we will need to rework when Meteor goes to NPM? Is backwards compatibility really going to be temporary or is it going to be permanent now? Is there going to be any features to help us refactor for the updated versions? How much of our code won’t work? What’s going to happen to Atmosphere? Will there be a way to easily convert Atmosphere packages to NPM?
Those are just some of the questions that, if answered, would make Meteor developers much, much more comfortable. And if the answers are positive, rather than negative, it would bring the morale back to where it should be.
But here’s the thing - if they are quiet about it, that implies that the answers are not positive and will most likely be negative. If they could quell the unrest with a simple statement they probably would. But being quiet? That means that most likely they don’t want to drive people away until they have something “new” to show them to try to keep them happy.
That’s not really a situation any current Meteor developer wants to be in. It’s harmful to businesses that are already using Meteor. It would ruin trust of developers to MDG, and make developers feel like they have been abandoned. Many already do suspect they have been abandoned, and you can see the unrest in the community. But it’s never been confirmed. If it becomes actually confirmed, many developers would just leave the platform. This would make it even harder to grow in the future.
I just hope MDG is aware of this and actually takes it in to consideration, and hope they do something to address the unrest and worry in the community.
The funny thing is, like I said in another thread - everything added or changed in Meteor since the beginning of this year at least has been in direct response to feedback from current production users.
I think we’re in a case where some part of the community feels like they haven’t been listened to, and assumes that’s because MDG doesn’t listen to anybody at all. From our perspective, the situation is more that the Meteor framework is evolving in the direction that we hear people asking for the most, especially people who are heavily invested in production Meteor projects. This is aligned with what we hear from calls with Galaxy customers, surveys we’ve done, and more.
If you look at my forum history I’ve been working on this for at least 30 min a day for almost the last 1.5 years. I think it’s becoming clear to me that this approach, including a regular transmission podcast, constant forum responses, and everything else I’ve tried to do isn’t working well at all. Perhaps I need some radically new idea.
4 Likes
Firstly, @sashko your positive can-do attitude is amazing. Thanks!
Case in point, I proposed to @thea a while back we write a blog post on Meteor’s blog / Medium about our experience, as well as have @diaconutheodor do the same about redis oplog and his other projects - I shared his email with @thea. There are a couple of other key things happening like Vue and code splitting where we can bring in more people too. Then we can solicit more involvement from other members of the community (already have a short list which will grow very fast as we advance).
I even floated the idea of joining on behalf of our organization to the next meet up in SF. To be discussed
We are waiting … let’s keep the ball rolling.
2 Likes
I can understand that perspective. Only issue is that, at the moment, morale is quite low and growth seems to have stalled - as this and other topics have noted, traction seems to have been lost.
So I would say, taking this under consideration, it’s more likely that some part of this community is happy with the upcoming changes, but the majority is likely unhappy with the direction. Things like Galaxy customers or surveys may give inaccurate results based on the demographic of the users being surveyed.
I love using Meteor at my job, and we plan on active development for at the minimum one more year, and this is software that will end up eventually being used by multiple other retail businesses that we are distributors for. I’m the IT manager and lead developer here, and I’m the one who pushed for us to use Meteor as our primary platform, so I’m pretty invested in to Meteor, and really hope for only the best success of the platform.
All I can say is from my perspective, it’s mostly just “worry about the unknown” and “hoping that these worries are unfounded”. I don’t really need SQL, but I think it’s awesome if Meteor supported it. I don’t really need Meteor to be fully NPM based, but I think it would be awesome to support. But I am worried about what sacrifices will be made in order to make that a reality… and I just hope it is fair to current developers (as mentioned, it’s kind of a vibe in the air that Meteor developers have been abandoned, but are hoping it’s not true).
Oh I don’t need to check your history, I seen you on here all the time (I usually check the forums here daily at work) and have seen or had you respond to my posts in the past.
But as evidenced by the responses a few posts up, just posting things on the forum are hard to miss. I had never seen the quote of yours that vigor shared.
Regarding that, I’ve seen many different conflicting points on the forum as well. The aforementioned backwards compatibility introduced in 1.3 - we were told that was temporary, some MDG staff had then said it isn’t going anywhere, but then it has been implied that it’s not permanent, and we have been told that it’s going to be required to even make full NPM support work… I have no idea what the truth is. And if it’s only in a forum post, it’s not really a solid piece of information.
My best suggestion for this would be, why not do public announcements/articles about these issues that are brought up regularly, and sticky those up top? Those have proven effective at not only reaching users, but generating a huge amount of feedback. I mean, think back to a year ago with the React announcements. Those reached everyone and were discussed for months. And even during this last summer, you would occasionally see some users thinking that the React-centric plan was still happening.
Assuming this happened, it would be very easy to respond whenever these topics are raised. If someone is worried Meteor is getting abandoned? Just link them to the announcement. Someone worried about backwards compatibility, or scaling, or the direction of Meteor? Just link them.
I just think at this point, it might be the time that it’s more important to address the “morale” of Meteor users, rather than focusing only on developing Meteor from a software perspective. Kind of sad that the last year has had such a decline of morale.
(Just seen Ramez’s post appear right beofre I posted mine, and I agree that blogs would be great as well. Just a solid place that people can not only see the information, but also allowing users to just link to that place whenever questions come up.
And I would like to add for my Christmas wish list, that I completely love the Blaze 2.0 idea of Vue and hope that happens someday, and in an ideal world, wish that MDG would assist in making it a reality as a first-class citizen, rather than leaving it up to the communtiy! 
).
1 Like
Heck Yes! 110% Meteor is by far the best production grade framework for node out there. It’s like Drupal for PHP. I can’t see any other de facto complete framework for node that does not require manual tinkering or hacking! Including mobile!
1 Like
Thanks @ramez. Really happy that we launched the new Meteor blog on Medium at blog.meteor.com yesterday to allow more contributions from the community like the ones you mentioned. As I’m out all next week, look for some follow up for @diaconutheodor and your talk proposal when I’m back first week of 2017. 
4 Likes
I have to jump in and answer a few points of yours!:
Agree with this, but I think some of this comes down to the community too. People like @diaconutheodor are clearly doing some great stuff for the community, so maybe others (myself included) could help out with that?
You say you’re unhappy with the direction but also “unhappy with the unknown”. So which is it? Either Meteor has a direction or it doesn’t…
Have you seen the roadmap by the way?
It already does, with Apollo. There’s a bit of learning curve (as I’m finding) but it works great. Postgres and Meteor work really well!
The morale is low for no real reason (I’m aware this is my own opinion). Meteor is already a great framework, it’s not really lacking much apart from maybe code-splitting and a few other niceties but it’s a stable framework to build node apps with a lot of the heavy lifting done for you. That’s what it’s been able to do for a few years now. When did that change?
I also think it’s some people just like a good moan and a grumble. Though I can see where some of the negativity comes from, it’s just blown out of proportion.
@sashko and @thea I think this is a good idea, though maybe with a bit of a tweak. Maybe a monthly ‘State of Meteor’ announcement post with some content and links to useful articles and tutorials would be good? Any updates to the roadmap could be seen in there too so the community can discuss some of these bigger issues, announcements and :shock: … success stories!
It’d be much better just having Vue work well with Meteor out of the box. I do think Blaze needs to be upgraded (though I now use React myself) but if you want to use Vue, use Vue. Again, that’s just my opinion though!
2 Likes
Couldn’t agree more. This is what we have planned for the new blog at blog.meteor.com - regular framework updates about open source operations and community news. Stickying them at the top of the forum is probably a good idea - will make note.
5 Likes
Yup, he’s doing awesome work!
I’m saying that I believe many users are unhappy with the direction. Regarding personal thoughts, I’m just worried. As mentioned, I’m a fan of those new features. But we were never told what we need to sacrifice in order to get those features yet. So I’ll probably be worried until that question is answered.
Yup… as just mentioned, my main worry is what sacrifices will be made once Apollo is integrated in to Meteor. We’ve only been told very few things, and the community as a whole has stated many times that nearly everything but the real-time data layer is likely going to be deprecated. But until there’s an official announcement of their plans to transition, we’re clueless, and that just leads to worry.
It may very well be for no reason. I have no idea really. I hope my worries are unfounded. But aside from statements like “We think users will be happy at the end”, we don’t really have any idea.
But really, the lack of information is really why morales low. The unknown is much scarier than the reality. Ever since MDG announced that it was going to be React centric (which I belive was a lil over a year ago?) people have gotten worried. Users don’t really know the direction, we’ve heard so many different things communicated, and even now - a year later - a lot of those same worries are there.
In my post above where I replied to Captainn, I explained many legitimate unanswered questions that were brought up by the community over the last year. Backwards compatibility, potential refactors, how much code will need to be rewritten, atmosphere, the transition to NPM - it’s all a big question mark really.
It’s been a pretty long time now, and many of those same questions are still being raised. If clear answers to these questions have not already been described, well, it gives the impression that Meteor’s future is not stable. Why would people feel safe using software that’s not stable? If current users aren’t sure of the future, and don’t really feel safe, it shows in the morale, and why would any new users want to start using Meteor if even current users are worried?
Like I mentioned earlier, since it would be so easy to alleviate these worries by just saying the plans if there was really some positive light at the end of the tunnel, the negligence on this front makes the unknown even scarier than it already is.
That makes it just seem more likely that it’s all negative, for example: “backwards compatibility is only temporary, we won’t have anything to help us refactor, the majority of our code won’t work, atmosphere will be gone with no way to use those packages at all on NPM, and they won’t work anymore regardless, and all our real time code will need to be rewritten for Apollo”.
That would be a disaster for our businesses software.
That would also break trust with all of the users who were worried that Meteor was being abandoned, who were told not to worry, when the exact thing they were worried about came true.
Plus, that would raise the question… “if every single thing in our projects except view layer will need to be rewritten at the end of this, if everything but view layer will be working completely different, why shouldn’t I just start using React now directly?” That option seems very appealing if they can start work on that right now, without the worry about stability or having to refactor their entire project.
People are already asking that question actually… And it’s kind of hard to answer without these problems being resolved.
1 Like
The answer to pretty much all of the questions is “we’re going to do our best and constantly weigh the pros and cons of every decision, with as much input from the wider community as possible.” I don’t think any other framework can promise anything different because none of us - not you, not me - can know what requirements or technologies will be important in 2 years.
Note that “shouldn’t I just start using React now directly” is also not going to solve the problem of ever-changing technology. For example, the new version of React Router comes with a completely different API, so people who used the previous version will also eventually need to change some of their code.
I would have hoped that the persistent effort of carefully releasing and testing for backwards compatibility with long beta cycles in Meteor 1.x would have spoken for itself, and reassure people that the project is focused on taking great pains to make transitions as easy as possible between different versions. IMO that’s much stronger than any promise or announcement we could make.
10 Likes
We face this decision every day where I work. It is very difficult to encourage simplicity. We tend to create a lot of ideas and start coding them quickly, without really justifying the ‘means’ or clarifying the desired ‘ends’.
