Time for a Community Fork?

[ramez]

It’s being pulled out of main repo, you need to add the UI layer yourself.

[ralof]

Well, what is the difference? Meteor has phased it out and handed it over to someone else, together with the responsibility. Ok, there is a difference, maybe it’s not being deprecated (although it said so in the thread), but it is definitely not the same as “we will continue to support and develop Blaze”

At this time it would, of course, be good if I could find the original quote with the exact wording…

[aadams]

I read in the (now closed) “Sad state of web development” that it was being deprecated and I just quoted sashko saying 1.4 was the last Blaze release from MDG. What gives?

Yes, 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. At the moment things depends heavy on one man: @mitar.

I have yet to see much progress over on the repo ran by @mitar, which is really worrying as someone that has a production application running on Blaze tech. In fact, I’m now seriously looking at making the switch to React because of this situation.

I am currently very frustrated, Meteor 1.4 (not 2.0) suddenly breaks my deploy infrastructure, an infrastructure that relies on community projects that now seem to be abandoned (mup). Maybe abandoned because it no longer fits into MDG’s new plans for our future.

Well put. I’m in the same boat as you. I created meteor-up-classic in order to get my deployment situation straight.

It’s true, the tech that makes up meteor classic will all be depreciated at some point probably relatively soon – Blaze, DDP, Tracker, Minimongo, Atmosphere – all of it. The way I understand it, they will all become the community’s responsibility (Atmosphere excluded) to maintain and grow – or not. Hopefully each one of these will be put out on npm, but we can’t be sure.

MDG’s has a new strategy around, and focus on, Apollo. Post 1.4, from MDG’s perspective, Meteor classic will become an integration point for Apollo.

[hwillson]

I have yet to see much progress over on the repo ran by @mitar

All progress in the Blaze repo is waiting on Meteor pull request 7633 to be completed and released. Once that happens, the flood gates will open.

[indesign]

I am currently very frustrated, Meteor 1.4 (not 2.0) suddenly breaks my deploy infrastructure, an infrastructure that relies on community projects that now seem to be abandoned (mup). Maybe abandoned because it no longer fits into MDG’s new plans for our future.

MUP is actively developed and works perfectly with Meteor 1.4, you need to use Kadira version not arunoda.

zodern/meteor-up

[indesign]

Thats right, there are multiple options out there for different use cases.

[mitar]

While I sympathize with consultants being able to make more money off React, we will invest in Blaze, make it more performant. We want to see virtual DOM in it. Ember is still growing, a testimony that html-based engines are still alive and well.

I think incremental DOM could be more suitable for Blaze.

[joshowens]

I decided to start fresh vs porting the current accounts stuff to avoid removing blaze, ddp, minimongo, flow from each package, and also to leverage the 300+ strategies already available for Passport. Unfortunately this leaves quite a lot to do, but it’s great to add features incrementally with full test coverage.

Here in lies the problem… People are moving on to new tech. Personally, I am not building ‘new’ meteor apps anymore. I am interested in some of this because I am supporting existing Meteor apps like Spacedojo.com and Crater.io.

That being said, I am super interested in the work you are doing @gadicc, as I just started a project with Apollo/React and would love to easily use Passport.js!

[joshowens]

@indesign

MUP is actively developed and works perfectly with Meteor 1.4, you need to use Kadira version not arunoda.

That is just not true. MUP & 1.4 still don’t play nicely, tons of edge and corner cases still cause breakage for many trying to deploy. Some have been able to deploy, I spent 5-6 hours and gave up because I kept hitting error after error. Kadira-mup works fine with 1.3 and that is what I ended up deploying for the new Crater.io

[ramez]

@mitar, yes – you keep reminding me, it sunk in this time.

Looking forward to closing that issue. How can we help?

[indesign]

I have being using it with 1.4 without any issues. That still is true as not all projects are the same and you may have encounter some unknown issues. Why not report those issues in the repo? Maybe someone can help with it.

[ramez]

Real deployment scripts are the solution, but they require some sysadmin knowledge.

[joshowens]

While I sympathize with consultants being able to make more money off React, we will invest in Blaze, make it more performant. We want to see virtual DOM in it. Ember is still growing, a testimony that html-based engines are still alive and well.

This really has nothing to do with ‘consultants being able to make more money off React’. I wanted nothing to do with React, but I forced myself to try it. I get better tooling, a fast render speed, easy and widely supported libraries like React Router. Stability and speed are WAY more important to my clients in the long run. I would argue that shifting the building of Blaze to the ‘community’ feels way less stable in the long run, so I’ve turned away from Blaze to something that offers a promising future with a team that has a sole focus on making a fast front-end to help profitability for a large company that cares about those things.

[joshowens]

Real deployment scripts are the solution, but they require some sysadmin knowledge.

I have the knowledge, I’ve been building Linux servers since like 1996. I don’t really care to spend the time on something that isn’t core to my business. At some point, it is faster and cheaper to move back to Modulus or Heroku.

[joshowens]

@indesign

I have being using it with 1.4 without any issues. That still is true as not all projects are the same and you may have encounter some unknown issues. Why not report those issues in the repo? Maybe someone can help with it.

They have been reported, no need to pile on in threads with a +1, I guess?

[indesign]

Thats right, no need for that.

[ralof]

Yes, as you say they have been reported and lengthy discussions has followed without any input from the developers (that I have seen). There is some various suggested fixes by people outside the team but since there’s no “Oh, we will fix this” from the team, I assumed they did not care. There were also comments indicating that the team are looking at a completely different solution. Don’t get me wrong, I don’t blame them, they have made three incompatible versions and maybe they just started something that does not want to work as they wish, but the problem for me remains - I suddenly find myself with tons of work that does not drive my own projects forward.

[aadams]

I suddenly find myself with tons of work that does not drive my own projects forward.

I feel you bro. I’m in the exact same situation. It really hurts my bottom line to have built something up, just to have to tear part of it down and again and start over because the company behind the tech had a change of mind.

There is some various suggested fixes by people outside the team but since there’s no “Oh, we will fix this” from the team, I assumed they did not care. There were also comments indicating that the team are looking at a completely different solution.

This might foreshadow what’s to come once the various part of Meteor-classic become the community’s responsibility. For example this correspondence:

Apollo + Meteor: which features exactly are coming in 1.5?

I feel like the Express, Koa, etc. people have more up-to-date packages for Apollo than we do for Meteor, which is a bit of a shame.

EDIT: https://github.com/apollostack/meteor-integration/ this is the package I am referring too.

Apollo + Meteor: which features exactly are coming in 1.5?

The Apollo integration packages for React, Angular, etc. are community-maintained. It looks like that model hasn’t worked out as well for the Meteor integration, so we need to find someone who has more time to maintain it.

@Siyfion are you planning on using Meteor + Apollo in production? If so, I’d be happy to work together with you to ensure the Meteor integration stays up to date!

Apollo + Meteor: which features exactly are coming in 1.5?

Perhaps we should go back to the previous state, which was that we just had a few lines of code you could copy-paste from the docs to do your own integration.

I think the safe bet for my business is to migrate to Facebook’s React, but I don’t know if I have the time and wherewithal to make the jump at this point. I’ve taken the first steps, but now I find out I have to rip out Iron Router with replace it with whoknowswhat, and so on.

[mitar]

Looking forward to closing that issue. How can we help?

Let’s move that discussion to that issue.

I think somebody should investigate how to do something of things I wrote here. We should see where would be the best place to hook into that API.

[ralof]

There is a certain irony in that that the MDG group has basically made the ‘M’ disappear and turned Meteor into something can not be explained with much more precision than “Well, Meteor is a lot of things…”

I’m sorry to sound negative, but the reasoning behind making a framework that leads to a situation where no two Meteor developers have the same “Meteor” just doesn’t make sense to me.