It’s being pulled out of main repo, you need to add the UI layer yourself.
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…
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.
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.
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.
MUP is actively developed and works perfectly with Meteor 1.4, you need to use Kadira version not arunoda.
Thats right, there are multiple options out there for different use cases.
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!
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
@mitar, yes – you keep reminding me, it sunk in this time.
Looking forward to closing that issue. How can we help?
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.
Real deployment scripts are the solution, but they require some sysadmin knowledge.
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.
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.
They have been reported, no need to pile on in threads with a +1, I guess?
Thats right, no need for that.
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.
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.
This might foreshadow what’s to come once the various part of Meteor-classic become the community’s responsibility. For example this correspondence:
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.
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.
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.