The key point is that Meteor as a Platform is not a goal anymore. Meteor is becoming an accessory or a tool of other eco-system. That is completely opposite to its initial goal: a coherent eco-system from database to app development. Tight database integration was breakout, view layer was breakout, router was breakout, package system was breakout, long time vision was based on fashion technologies. What is the road ahead, you bet. What I see is another Windows 8 Lite.
For me, it’s interesting to see repeated appeals to divorce technical aspects from “business arguments”, when that business itself (product? service?) is tightly coupled with technology 
Why are you assuming that people supporting, or not opposing, the announced move on Blaze2 in this thread (which, btw, is about the direction for Blaze and view layer) don’t want routing to be in the core of Meteor? Ever considered the possibility that good technical reasons should be part of the factors driving business strategy?
Just someone trying to politely bridge a gap in the discussion, as I assumed all people here basically share the same interests. If MDG does not see a coherent ecosystem as top-priority, then that is their right. At least it is clear and each person in the community can decide if they need to move on or bite this bullet and the ones to come.
By making wild assumptions about who we all are, and that you are somehow not one of us, someone special? That seems really polite to me.
Of course you are right. At the end of the day it is all connected. Still, hair-splitting the ecosystem is costly in many ways and should be taken into account when deciding on technology, I think. And that’s why I understand @aadams The incompatibilities and emotions that I see arising in this community are a lot bigger than I saw in others… and many of them failed… so well… let’s hope the posse stays together 
I saw @aadams using business arguments and some people, responding technically. I assumed nothing and did not even had you in mind specifically, so apologize if you feel insulted.
To clarify a bit more the concerns: take a look at this example: Does Meteor has offical ways to handle with translation like i18n in Ruby on Rails?
Well, I meant that I read your posts and still could not understand your line of reasoning. You make presumptions, and contradictory statements…
How do you know that’s gonna happen for sure, for all packages you’re using? Are you concerned about packages you’re using today, or packages that people might have built in the future for Blaze 1 if it existed? Even if the packages you use today were to migrate later, couldn’t you just continue using the same versions that you know work today?
I haven’t seen any popular library/framework not releasing major api-breaking versions just because some businesses think they “can’t afford” (or don’t want) to “put in the effort” to upgrade. Even the paid commercial ones don’t stop making progress, or deprecating outdated ideas/APIs. MDG articulated their reasons why they feel Blaze2 should be built with a particular approach. You want them to not go ahead with it, because your assumed “necessary” upgrade would presumably affect your “bottom line”?! Of course staying up-to-date needs effort and hence money, but you spend it only if there’s a justifiable ROI (valid “business argument”?)
On one hand you say you’re willing to pay for Blaze1, and on the other hand you’re worried about the “drag on your bottom line” caused by refactoring to a version that no one has yet strongly suggested to be a bad technical decision (the line of argument, though flawed IMO, only being: it seems unwise in “business sense”). Instead of opposing the evolution of the view layer in a way that the founders find appropriate, why not spend the same money to refactor and stay up-to-date? Or fix the “abandonware”? Or maybe even keep Blaze1 alive in a way that makes sense to you. If it’s indeed true that “many others are in the same boat”, get them together and collectively sponsor the maintenance of a fork in a way that makes sense to you! Your money/effort, your roadmap!
If you were genuinely looking for solutions, you’d have already seen merit in many comments here why it wouldn’t necessarily be as bad as you “think”. If nothing else, you’d have at least tried to explore them to address the concerns which “put your business in a precarious situation”. I replied with the assumption that you’re looking for views to (in)validate your concerns and/or find solutions. But…
…seems you’re more interested in imagining and labeling logical fallacies in others’ views! 
Tomorrow, Dec 3rd, Meteor SF is hosting its usual devshop.
Most interesting to commenters here is that Geoff Schmidt, CEO of Meteor, will be speaking. The title of his talk is: Meteor: A Look Forward
The youtube channel at devshop.meteor.com should go live at 7pm Pacific Time. If you can’t make it live, you can always watch later.
9 Likes
I’ve stated what I think some solutions could look like several times now friend: here here and here.
Sorry if this is too direct, but so far I’ve been disappointed with our exchanges as most of your comments/arguments/thoughts I think have not helped much, if at all.
Further, your comments were littered with logical fallacies and distractions (like your latest one) – hence the reason I called you out on them so many times (sorry about that mate).
Please, try not to invalidate what we say as much as try to understand where we in the Meteor community are coming from on this topic.
Honestly @gaurav7, I think it would be better at this point for someone from MDG or even @gschmidt himself to address my and others’ like-minded concerns here.
Cheers anyway –
You’re iterating on your own supposedly-only-solutions-based-on-presumptions, and why they’re not valid. You refuse to consider others’ points and label them fallacious if they’re not in alignment with yours.
I’ve only replied directly to you twice before this. Are you mistaking me for someone else? You’re probably treating everyone not aligning with you as a single opponent to defeat in an argument. Most of us are not here to score debating points. Not me for sure.
Someone as good as you in identifying fallacies should have been able to see them in his own arguments. Alas! Wonder how anybody’s comments would help you if you adopt such an approach. Hope you find your answers and solutions somehow. Cheers.
Thanks mate! Cheers!
Exactly my sentiment.
How do we explain this to those who bet their future (and their money) to us? That they will have to pay again to update their platform to the latest version in 6 months (more work hour to upgrade).
Ok before we talk about payment, how will they respond to this kind of situation? They are (most likely) business entities who deals more with RoIs than keeping up with platform updates security or efficiency. They wouldn’t care if meteor is whatever compared to php or c++ or should they upgrade or not, but if security upgrades are necessary (with hours of work entails) who pays for our work hour then? I can immediately imagine the look on their face…
EDIT: OK, nobody says blaze is going to be deprecated, but my dread has already there. Now I’m not sure if Meteor is ready for long-term projects. Maybe Meteor is not meant for long-term enterprise projects? Thoughts?
I think most of us just need a confirmation from the MDG, that all projects are written using Blaze, will be fully operational, for example, 3 years. During this time, even a very large project can be completely rewritten in the React.
And after all someone tell me how and where to use observers in React?
1 Like
If that’s the case they really don’t take the forum any seriously and we should draw some conclusions from that. If the willingness to communicate is not there it’s very hard to get it fixed.
We are in the process of starting a complete new app. The suggestion we got from the experts now is: learn with Blaze (tutorials, books available) but at the same time develop on React (future ) !!. “The problems you will encounter like incompatible packages like i18n, … wait them out until you have enough expertise to fix yourself or that the volunteer creating it might have time to fix.” Maybe during his Christmas break ??
Ahh… we are a corporate trying to make money and serve clients for years to come and this does not give confidence, really. It would be nice if we all understood that. But maybe you are right, maybe the best options is either forking or accepting Meteor turned to dust upon impact… But not appealing, that is for sure. Please, the reason so many people did not yet turn their back on Meteor is that it is (still) a great platform we really, really like(d?).
3 Likes
I think @sashko et al answered the question (here or elsewhere, don’t remember) why the current guide uses Blaze. I hope when Blaze2 is released and/or they improve React integration, the guide will be updated accordingly.
As far as the suggestion on what to use for new apps is concerned, it was a generic one from what I understood. Did you get the same suggestion when you provided more details like the project kickoff and delivery times, packages you’re basing it on, etc?
If you are heavily invested in, or reliant on, Blaze and its packages, I think it should be safe to use it for the new app. The sense I got from MDG’s communication is that there would be a migration path from Blaze1 to Blaze2. If you’re basing a business decision on it, reach out to MDG, through this forum (I’d suggest a new thread) or phone or whatever gets you a definite response!
Package/Plugin compatibility is definitely an important consideration whenever there is a major change in a framework with an ecosystem. But it would be unfair to hold MDG responsible for compatibility of packages they don’t maintain. They have articulated their reasons for the move. Now we (including MDG) gotta figure out how to do so with minimal impact! Simply opposing the move altogether is not constructive. We could take examples from other open source projects who face similar situations. This is what we did for Grails: https://github.com/grails/grails-core/wiki/Grails-3-Priority-Upgrade-Plugins (Btw, one of my business apps built with Grails is still on Grails 2 and with new features getting added regularly. I didn’t have to upgrade it to Grails 3 just because it was released.)
2 Likes
Of course and you are so right here. Actually, I am for one willing to fully go with React and bite the bullet, even happily. My objection is not React at all, it is the patterns we see here.
The point of objection is that MDG leaves so many things dangling that it becomes a pattern and instigates ecosystem splits: announcing both React AND Agnular as “1st class citizens” ??? Just as we know Iron, we need to go for Flow?? Now i18n is shaky, what to do? Cordova/Mobile? Why all the Coffee pollution if they also consider Typescript? … and so on.
Anything that is not Meteor’s USP, let’s take one and stick to it, even if not always the latest greates. All the other very welcome but 2nd class citizens, can live happily as community.
What I am asking for is more opinions and official consistency from the leaders, not less.
4 Likes
But isn’t the reason given for this move (Blaze2 = templating layer over React) precisely to help fix some of the issues you pointed out?
I agree in principle that we don’t want an ecosystem split the way you described. But let’s not confuse it with a perfectly valid approach of supporting multiple options where it makes sense. I got to Meteor because I found it to be a good backend for my React app (that was a few months ago). Now I’m considering Ionic + Meteor for a mobile app. So I for one am glad that Meteor wants to take this approach for the view layer.
I do agree with the principle of what you’re suggesting. But the answer to that is not as straightforward as we all would like it to be. So, like you, I hope MDG leadership reaches out more often, and whenever that happens, I also hope the entire community keeps the discussion within context and constructive.
1 Like
Indeed and I agree mostly for sure. I am also pondering over Ionic…
I still feel we need a reference platform. One that we can all test and develop against. That still leaves room for supporting multiple options, but at least we have an agreed full stack to start from.
4 Likes