Time for a Community Fork?

[aadams]

@vlasky

My concern was mainly over the incorrect use of the term “deprecated” - a strong negative term meaning that that something is being discontinued and is on its way out, being kept purely for backward compatibility and/or to provide sufficient time for people to move to something else before it is eliminated in its entirely.

@vlasky

When it comes to Blaze, the only way I would consider correct is by saying “Blaze has been moved out of the MDG meteor repository and is now community-supported”. That way it is clear that it is still alive and people know that others have been assigned the duty of maintaining it - it is not going to be turned off in any sense of the word.

Please don’t be concerned. If we go back to my orginial sentence I state:

"MDG will no longer maintain Blaze… [In this sense] post 1.4 it will be officially depreciated… The jury is still out as to what becomes of Blaze. [new emphasis added]

I don’t want developers to pretend like nothing is changing. I think it’s important for developers to have a full understanding of the situation so they can make more informed decisions. Judging by some of the comments on this thread, some developers where confused by earlier comments and chose Blaze, when they might have chosen React.

I don’t want to parse terminology, but to me what said above is still valid. As far as new development and maintenance is concerned, MDG will no longer be involved with Blaze. To me this means Blaze is “officially” deprecated. To me there is no negative cognition here, it happens all the time (but I can understand the sensitivity and will try harder to choose softer words next time). But, again as I said above the jury is still out on what becomes of Blaze, because the community has not had a chance until now to step up and advance the state of the Blaze art.

To further put things into perspective, this could be the start of the golden age for Blaze. Blaze has been almost untouched by MDG for a very long time. The community has an opportunity here to step it up and really advance Blaze into the technology we always knew it had the potential to become. The community still has a moment now, let’s see what happens.

@vlasky

I am not familiar with these indirect statements - I try and avoid making inferences as its easy to get things wrong. As you say, know, MDG have not made any direct statements about DDP, Tracker and the others. I haven’t really needed them to - the important thing is that MDG staff are responding to and resolving issues on Github and that is really good.

Again, I don’t want others to get the impression that MDG is taking care of Meteor classic components. I want developers to understand that they need to step up and take on DDP, Tracker, MiniMongo – to advance these components – because I think MDG will not anymore. For example, when MDG sends Blaze out to the community, do you think MDG will not do the same with Tracker? Just look at this post on github from today:

@mitar referring to adding Blaze to NPM:

OK. So, feel free to make a pull request moving to NPM. I think we could extract Blaze to it, and then use compiler plugin from Meteor package only, like @stubailo wrote above.

The issue with NPM is that there are also dependencies. Like Tracker. Then we have to move those to NPM as well.

@stubailo, what should we do with those packages? Would MDG be interested in moving them to NPM and then providing just thin backwards compatibility Meteor packages?

…

@stubailo, @tmeasday, what do you think? Could we move Blaze dependencies to NPM?

…

@stubailo 's response:

@mitar Yeah I think it could be cool to have tracker on Atmosphere just be a simple package that Npm.depends on tracker from npm. Do you have an idea of the full list of Meteor packages that would need to move to npm to make this work? Is it 2? 10? 50?

Or how about the future of DDP?

@hwillson

MDG themselves have said that the plan is to have Apollo become the default data layer for Meteor.

Future of Pub/Sub and DDP

Regarding the future of DDP, I’ll quote @debergalis from his Meteor 1.4 and beyond talk when he was talking about using DDP and Apollo side by side: [image] … we’re committed to a path where you’ll be able to use these different pieces together as we figure out the right time for a transition for Apollo to be the new default data layer. I think MDG has made it pretty clear (well, clear if you attend Meteor Night or watch the videos) - for now nothing changes with DDP, but in the future e…

There has been very little “direct” statements from MDG on any of this. We’ve come to know what’s going on by small posts by MDG here and there. For example, just in this thread:

@sashko

As of Meteor 1.4.1, core packages can be updated outside of the release cycle.

This was a pretty big change we made specifically to enable this kind of mini-forking of formerly core parts of Meteor. We were planning on doing a similar thing with Accounts as well, back in the day, but we haven’t found someone to be “in charge” of that section of the code. Perhaps it could be you!

@vlasky

Right now, I see the current version of Meteor 1.4.1 as being the best one MDG have ever released. For us, it’s been a succession of monotonically increasing improvements since we first started with Meteor in early 2015.

As someone whose main business activity revolves around Meteor “Classic”, I want to do what I can to provide the necessary inspiration, motivation and means for its continued support and enhancement.

I agree, I’m on 1.3.5.1 and I’m enjoying it. As I’ve stated in previous posts on this thread, we can keep our Meteor classic. Just know that in the relatively short term, the various tech within will not be advanced anymore by MDG – again the developers in the community that have the time should get involved if they feel passionate enough. Further, we will be able to pick and choose what parts of Meteor classic we want to keep and throw out. For example, if I want React with DDP/Tracker/SubPub and Mongo, I can have that. If I want Blaze with Apollo, I’m all good.

This is actually the best of both worlds now that we have more choices. We have the stability and tight integration of Meteor classic, with the option to replace pain points with tech from NPM. The only question now is: will the community advance the tech that we know collectively as Meteor classic.

@vlasky

As someone whose main business activity revolves around Meteor “Classic”, I want to do what I can to provide the necessary inspiration, motivation and means for its continued support and enhancement.

I’m right there with you. I’m all for solidarity and comradery. We’ve all been in the Meteor-classic trenches for a year or more. But I also have to be practical.

Let us speak plainly, if we are wrong, then we’ll be corrected soon enough. So please, if someone feels passionate about Meteor-classic and wants to get involved, pick a portion of the stack and ask MDG if you can contribute. Become the owner of that portion and advance the state of the art. We are all counting on it.

I’ll answer the question, is it time for a community fork? Doesn’t seem that way for now, since MDG is willing to help guide the community with the heavy lifting.