@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.
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
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.
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:
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.
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.
Is there anything in the following that can be added to the action items?
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.
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.
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.
MDG and the community of Blaze users can continue contributing to Blaze, it just wonāt be hosted by MDG.
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.
@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
Youāre basically rewording what I wrote, MDG will not maintain Blaze, the community will.
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.
Specifically, the pace of development of Meteor has slowed down dramatically in favor of Apollo.
Apollo is the MDG answer to the two issues you highlight:
ā¦the main struggles we see on the forum, namely DBs:
- Replace Mongo with RethinkDB (95% ready some quirks to solve before going to production)
- Replace Mongo with MySQL
Meteor 1.5 will feature fast integration with Apollo, so it will take care of these two issues. Also, thereās an argument that since Meteor 1.5 is all about Apollo, the MDG team being focused on Apollo right now really is for the benefit of Meteor. Technically Apollo is stand-alone, but as you point out, two of the things Meteor needs most are access to SQL and other databases, and thatās what Apollo provides to Meteor.
Apollo is a different paradigm then pub/sub, and is overkill for many apps. Like React for us, no value add, just trend chasing.
Second, these drivers are already operational and work great with our apps ā so why bother, change our apps, wait for rethinkdb to be tested with Apollo etc ā shortest path to $$$
You make some interesting points (some forcefully 
We could always reach out to rethink folks once the db driver is officially released. There are many things meteor offers that horizon does not, like you say. Including client-side changes.
In terms of atmosphere, I think the new approach is to clone repos directly into packages/
I find this thread very interesting.
Personnaly, I discovered Meteor and work 6 months on a site, I was very happy with it. Then after the 1.3 update, without warnings, I could not pursue on the 1.3 nor going back to 1.2. I felt cheated. So I am waiting for a clearer choice. Now I am on an other project and just suspend my Meteor project, waiting for Meteor to be mature while still looking at others javascript frameworks.
Why?
You should be able to revert back to an old version.
Blaze has been removed from core Meteor repository and a community Meteor organization on Atmosphere has been created. I think now it is time for community to start contributing to Blaze. We can also now release our own versions of Blaze.
Awesome. Something so important should also be announced in its own thread as well IMO rather than just 100 posts deep in this one.
OK cool.
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.
For example, Facebook deprecated version 2.0 of its Graph API on August 7th 2014 and they totally disabled it on 8th August 2016, so any app that tries to access it will receive an error.
For this reason, ādeprecatedā should not be used willy-nilly.
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.
I am not familiar with these indirect statements - I try and avoid making inferences as its easy to get things wrong. As you say, 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.
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.