Time for a Community Fork?

[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.

[ramez]

@joshowens
Nothing is forever - remember parse? – that didn’t exactly go forever. And it was Facebook’s.

The trick for open source is to chose projects with a good features vs risk ratio. Blaze suffered because it’s taking a long time to take it over – and that’s MDG’s doing. Once it is taken over who knows where it goes. Making it have great performance shouldn’t be too hard, we just need to start.

My philosophy … instead of watching … we are doing.

[kaiyes]

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

Don’t want to come off rude but Instead of replying forum posts, if you put that time and energy into react, you will nail it.

I too was very unsatisfied with blaze situation and was quite vocal on that famus 1000 reply thread. Then I stopped being active (replying ) on these energy draining, fear induced threads and kept my head down and learnt react. Guess what ? I’m loving it.

Also, I love the idea of Apollo. May be we have been using pub sub for so long that we have forgotten how painful building a rest api is. There are companies like loopback who’s value prop is solving the pain point of generating rest APIs. Apollo brings the best of meteor to the rest of the web dev world, not only to JavaScript. As soon as the accounts with Apollo is made somewhat easier like meteors accounts, I would say mdg have hit jackpot

[aadams]

Don’t want to come off rude but Instead of replying forum posts, if you put that time and energy into react, you will nail it.

No worries friend!

When I said I don’t have the time, I meant I don’t currently have at least a month worth of hours I would need to convert the now two hundred screens of Blaze over to React. 30 min here or there on these forums doesn’t hurt me, it helps sometimes.

But I think if I take it slow, and pace myself, I might be able to manage.

To share, I was off these forums for a while, I come back and things have changed a lot. I’m on these forums now to try to get a better understanding of what the situation is and what is coming. Actually this thread in particular has helped me a lot I think.

Although, I must say, the technical help we once enjoyed on this forum has seemed to wain a bit.

You’ve benefited from being on these forums too. I’ve seen you in the Meteor Mentoring group, and the youtube videos where you’re asking the React questions, maybe that’s how you got over the React hump after all. I’m sure they helped you out a lot as they have a few star Meteor devs in that slack group.

To share, I’m all in on Apollo too as soon as it gets reactivity nailed. I’m glad you like it so much, that gives me great comfort to see such positive feedback.

Also, I don’t think this thread has been negative really, but everyone has a different perspective.

[sashko]

I think there are a few possible action items from this thread that we should get started on right away, but it’s quite hard to parse them out. Here’s what we’re doing:

1. Splitting Blaze out of Meteor, so that new versions can be published quickly:
2. We already released Meteor 1.4.1 with version unpinning, so it’s possible to publish a new version and upgrade to it today, as far as I know.
3. We’re still working on actually deleting the Blaze codebase from the monolith repo, so that there aren’t two copies of the code out there.
4. Looking for people who are interested in a particular part of the Meteor stack, and want to get more involved in working on it. We didn’t get much response when we asked about this before, but I imagine there are a lot of people who have great ideas about improvements that could be made.
5. We have two applications internally built on Meteor, which are the only revenue source of the company. So we, as a business, are as heavily invested in the technology as we could reasonably be.

Are there some other action items, and people who want to sign up for working on them?

BTW, thanks @joshowens for proactively opening an issue about the Accounts/Blaze dependency and driving the discussion: https://github.com/meteor/meteor/issues/7715

---

As a meta-issue, perhaps we should split this into several threads about the different topics? I came back this morning and there were 40 new great messages, but I won’t be able to keep track of that volume and convert it into actionable information for long.

[ramez]

Hey @kaiyes,

Some of us really don’t like React, or have business / technical reasons not to want to embark on it.

And btw, React in itself is super-easy.

I don’t like the over javascriptization of view layer, don’t like jsx, don’t want to use flux / redux, or fb stack, I like how things work well as it is, like how easy it is to make changes, like separation of HTML.

Many switched to react just because MDG told them to so For us, it takes away value - doesn’t add. Also, many on this forum are freelancers. We have our own product to build and maintain.

[aadams]

Are there some other action items

Is there anything in the following that can be added to the action items?

In fact, probably a lot of the fatigue of people who feel like the official materials like the Guide have switched to a more complicated, module-first, choose-your-own-adventure format could probably be helped by collaborating on a new educational resource that describes the “classic” way of doing stuff, with only Blaze, “global” variables, limited NPM use, etc.

[ralof]

Exactly, @ramez
React is, I’m sure, super cool and everything, but whatever advantages it may provide - I don’t need it. Would be interesting to know how many who switch are doing it because they need it and how many is switching because everybody is talking about it.

To me, writing functions that returns HTML feels just wrong and it makes it much more difficult to work with designers who knows basic html but nothing about JavaScript. Handlebars are much easier to understand and the templates becomes human-readable and connection to the helpers are super easy to explain if you want to add another developer to the team.

[ramez]

Thanks @sashko,

I should be having the call the MDG community team sometime this week.

I would add this:

-4. Abstract a database layer, while keeping mongo syntax - i.e. Mini mongo on client and adapters on server. We already have MySQL/SQL operational, and rethinkdb (almost) operational. This will cover 99% of DBs being asked for on this forum. In addition, mongo syntax is so much simpler, it may even increase adoption of meteor (hence Galaxy) for people wanting to use these db’s (especially rethink with its quirky syntax).

If MDG wants to include its analytics API to monetize, we are all for it.

[vlasky]

We actually were investigating refactoring accounts for other databases already, so if there’s a good plan that sounds great - I’d be happy to take a look.

Yes @sashko, this is a necessity.

Currently, all the accounts-* packages presume that they are accessing a Mongo.Collection object. This makes it a very difficult task to implement support for MySQL (and other databases).

There needs to be an overridable/replaceable data abstraction layer for all database operations so that they can be handled in a custom manner for any specific database that a developer wants to support.

[vlasky]

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.

MDG and the community of Blaze users can continue contributing to Blaze, it just won’t be hosted by MDG.

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.

Perhaps this was not your intention, but this looks like an expression of FUD about deprecation of core Meteor components when many of us are happily using Blaze as well as DDP, Tracker, Minimongo and Atmosphere.

These packages work and they make us productive. The only issue is that they are not “shiny and new, like a virgin touched for the very first time” - that is not a problem with them, that is a problem with those who are neophiles - that is, overly attracted to new products/tools/libraries regardless of their worth and usefulness.

MDG’s mistake was not appreciating the massive psychological impact of discontinuing their support for Blaze as the main Meteor templating system. Many people incorrectly perceived it as a indication that MDG had begin a process of dismantling the Meteor ecosystem altogether.

MDG should appreciate that understanding developer psychology and perceptions is a key part of successful technology evangelism.

[ramez]

@vlasky, can you be responsible for the SQL driver? I’ll hand off what we did to your driver to have client-side updates, allow/deny, server side mongo syntax and mini mongo support and you can take it from there.

We can keep developing rethinkdb for scalable reactivity

[aadams]

MDG and the community of Blaze users can continue contributing to Blaze, it just won’t be hosted by MDG.

You’re basically rewording what I wrote, MDG will not maintain Blaze, the community will.

Perhaps this was not your intention, but this looks like an expression of FUD about deprecation of core Meteor components when many of us are happily using Blaze as well as DDP, Tracker, Minimongo and Atmosphere.

No one is taking anything away from Blaze or the Meteor-classic stack. I think DDP/Tracker/Blaze/Minimongo are great and I’m super productive with it.

Further there is nothing to be afraid of. There might be uncertainty and doubt by some, but for my business I can only try to calculate risk/reward ratios.

Like it or not, MDG will no longer maintain DDP, Tracker, Blaze, Minimongo, useraccounts and Atmosphere – Meteor-classic. They’ve stated this plainly in the case of Blaze and Atmosphere, and indirectly with the others. The community will need to pick up slack – or not.

I think moving forward, for the most part, MDG will focus on Apollo, it’s that simple. This should be crystal clear by now. So if someone would like to take over one of the areas of Meteor classic they feel passionate about and want to advance, reach out to MDG now.

I have a business with paying customers and I’m using the tech that’s no longer going to be maintained. I’m in the same boat as a lot of you using this tech. I have the job now of deciding if I’m going to migrate my code to GraphQL + Apollo + React or stick with my current Meteor-classic stack and trust the community to step it up.

Also, I would never change my tech stack just because something new comes along. But I will absolutely consider migrating away from tech that will no longer be maintain by MDG or maintained sufficiently by community – these are business risks I have to account for.

I’d like to add, we still should be able to use Meteor classic, and migrate to Apollo and/or React. From MDG’s perspective, Meteor classic will be just one of many integration points for Apollo.

I’m sorry if me laying-it-out plainly like this seems disingenuous or too harsh, that was never my intention friend. I believe its the reality we need to start living in and face up to. I believe we should be walking through this transition with open eyes. It’s the only way we can map out successful community strategies to deal the situation.