@slava ok, i read what you had to write. Here’s the thing, a lot of what you had to say is understandable. I’m gonna choose to not take offense and keep the discussion focused on actual issues. I hope you can also see how it’s understandable that I perceive Meteor to be in a very dangerous position having been beat out by competition for the first time in its history.
This isn’t about me and my ego, but I have put in lots of “work” to determine Meteor’s precise place within current trends. I may be bringing up a lot of the same points and perhaps you disagree with post length, but there’s a reason I’m getting emails and private messages and invitations to do interviews on the daily: because I’m giving a detailed voice to concerns that take a lot of research to truly understand that our community’s amazing developers don’t all have time to address themselves, which MDG wants to downplay.
The particular issue of researching how to build subscriptions isn’t something I perceive that I need to spend hours researching. The wheel shouldn’t have to be re-invented or re-researched. I generally perceive that behavior as young developers trying to boost their egos and show how smart they are, which I don’t find productive for me.
There’s a reason I opened this thread with a question: I don’t have the answer, I think those that do (clearly not you) could easily explain it, and I have reached a point in my career where I don’t have to do everything myself to feel good about myself. I don’t know the answer, I’m showing work in related areas to pin-point the trends, I’ll do the research if I have to, but I think it’s fair that I ask. And I do think the behavior shared by both MDG and the community of not knowing how our core subscriptions feature works and keeping the information siloed is “pathetic.” If you want to take one word, one sentence and interpret it to be an attack on you and other developers, that’s your choice. In this case, it’s hardly what you made out it to be. The golden rule (or rather, a golden rule) is: there is no offense unless it’s taken. You clearly invested time doing your research on what I have to say–what I have had to say is edgey, but ultimately makes important points, and at the end of the day it’s clear I’m not trying to make anyone feel bad, but just steer our focus to under-served areas. We are strong resourceful developers, and I don’t believe in singing kumbaya when the ship is burning. However, I do get it, when you worked at MDG they likely truly helped foster your growth and you’re sticking up for them. Meteor has problems @slava, and they seem to be starting to get addressed, but I’m gonna voice my concerns until I feel they have amply been addressed. MDG can kick me out if they choose, and that would be their loss.
So anyway, Meteor isn’t an open source project. This is a major problem because Meteor isn’t a single focused project but a conglomerate of many sub-projects. Projects that aren’t being attended to–just look at other threads at the top of the forum today. If I could easily fork and switch out the subscription stuff without resolving to hacks (like you can do in the rest of NPM) you wouldn’t be hearing my vocal side in this forum. Other developers have been content to monkey-patch everything. That’s their prerogative, but keep in mind that Meteor Hacks was named Meteor Hacks for a reason–literally every single package created under the Meteor Hacks brand was a monkey-patched hack. Everybody seemed to skip over that aspect. That’s worked out for @arunoda as after several years he’s been able to redirect the respect and fame toward Kadira, but that’s not a path I’ve found value for me to invest my time. Other languages don’t even have support for monkey-patching. That it boils down to that is one of the #1 reasons you shouldn’t use Meteor–it relies too heavily on hacks.
I think when this is addressed, a lot of problems will be solved. I recently myself have gotten tired of writing all this, and I’ve pin-pointed the root issue that would solve most everything to be: make Meteor sub-packages their own repos, and provide syntax in the packages file to refer to forked versions of core packages. The latter which is one of many ideas that nobody at MDG has cared to take the time responding to. Contrary to statements you made, there are open source communities where its core leaders communicate on the daily, giving good ideas some sort of acknowledgement. It’s clear Meteor is overworked and spread too thin, and that’s why it’s allowing competition from all sides to take its throne.
As far as the initial question that was asked, we need to figure out how we are going to bring subscriptions to the GraphQL future. If done truly right can continue to be the #1 attraction of Meteor. There needs to be a heavy duty undertaking, which likely only MDG can afford, to do this all over again and better than ever. The information I’ve been told is @gschmidt sent @sashko on some experimental scouting. That might already be too little too late.
Lastly, this thread is still open. Anyone with expertise in this area, it would be great to hear from you. I think Relay and Om Next have laid out a great foundation for a new full stack reactive interface, but my perspective is that what’s most important is working out the challenges regarding the db implementation since we wouldn’t be using a single db that has native support for subscriptions.
If you would like to contribute to this thread please keep it to discussing the problem domain, rather than bike shedding about tone and process etc. Lengthy responses welcome. Our community has a problem on our hands, let’s solve it together, and at the very least get informed once and for all about the deepest most important inner workings of our beloved platform.