Yes, you’re on point here, but the reality is that all of these work really well today for building all kinds of apps, so I don’t think there will be a big time pressure to switch away from any of those.
I think the most official word you can get is Geoff’s talk in December:
I think being a complete platform to build an app is unquestionably Meteor’s goal. I think the Meteor Guide can be the only answer to that question, since we will never be able to personally build everything. If you’re asking about whether we will give advice about how to transition to the new stuff, I don’t have concrete answer, but there are already great resources like @sacha’s video series: https://www.discovermeteor.com/category/blaze-to-react/
If there aren’t enough resources, feel free to reach out to me personally with questions, but I think any sane strategy from Meteor has a keen eye towards backwards compatibility and transitions - you can see this with @benjamn’s modules project, which can currently run a Meteor 1.2 app with no changes at all.
Yes, I’d say this is correct, if “long term” is about 5 years. I’d wager you can trust everything in Meteor today to still work at least just as well as it does now for the next year or two. But keep in mind that everything takes time - just because we are not promoting Tracker actively right now doesn’t mean it’s going away, we just haven’t had that conversation yet since we can only do so much at once. I think there is a conspicuous lack of agreement in the React community about the best way to reactively update data, with several proposals being considered and rejected.
Myeah, not downscaling all you guys have done/are doing… but that’s not gonna cut it (my 0,02). And just like @funkyeah said, I’m sorry this sounds like being a prick (most likely I am ), but it’s all just been a little bit of a let down lately.
There was too much here to read everything. But as I scrolled down after reading the article I became queazy, then felt quite ill. I’ve been on the Meteor JS train from the beginning, developing one week then making adjustments for the next new beta version the next week. I love Blaze and have become quite expert with it. I’m not happy about this plan.
That’s how I was feeling too, but the more I’ve read the more I am starting to change my mind.
Meteor started by being a grand vision for the whole development stack. In the meantime the world (Facebook in particular) stumbled across some things that called some parts of that vision into question. So what is MDG to do? Stubbornly forge on in the same direction?
I think its clear the answer to that is no. So what then? The answer to that has been to open the doors to outside solutions that at least in some ways improve on the original vision. The troubling part about doing that though is it pulls all parts of the vision into question.
When part of the stack is a solution provided by an external community and there is a lack of consensus in that external community about how to do something, then there definitely can be no certainty within the Meteor community.
And I think this gets at the heart of why adopting React can feel so frustrating to some. Sure de-emphasizing Blaze hurts because of investment to date, but for me its more about how confidence in Blaze and the vision for a complete Meteor stack was replaced with React and an uncertain vision for the future.
As sashko mentions, Meteor will be a solid collection of technologies representing present day best practices. It will continue to morph as the wider javascript community generates consensus. It will not be a stack that can be counted on to be backwards compatible for any time-frame. It will not come with a promise for continued support of any part of the stack.
So the major change is not that Blaze has been dropped. Its that Meteor is no longer meant to be an enterprise development stack. Developers should expect changes like dropping Blaze in the future and need to see the value in Meteor from a slightly different perspective.
I do want to reiterate that Meteor has been great to develop with and I have no doubt it will continue to be this way.
Also, since I think this doesn’t get said enough, @sashko your patience is commendable and your interaction has been invaluable for myself and many.
I’m curious what people are referring to when they mean “support” - as far as I know, Meteor 1.2 is pretty backwards compatible to 1.0 - what additional support would you be looking for?
I don’t want to speak for anyone else but I think of it in terms of long-term support of other enterprise level tools.
E.g. a time-frame for which a release:
Will get support for bug fixing (especially security bugs)
Will work with the rest of the ecosystem without being upgraded (like Atmosphere and Galaxy)
Maybe there is a notion of these within MDG and I am just not aware of it.
On back-wards compatibility I mis-spoke. While there has been some friction getting from 1.0 to 1.2 it really has not been bad at all for me. What I meant to do was reference that the recommended technologies that make up the Meteor stack will be reflective of a continually evolving consensus rather than any medium to long-term commitment to one approach.
As far as I know, these are true for everything in Meteor 1.x+, barring some minor breaking changes. Like Blaze still gets some bug fixes, and works fine with Atmosphere and Galaxy. We just might not be adding lots of new features. I think that’s very different from “unsupported”.
I think this is the only way a web framework can stay relevant today. But we do try our best to make it easy to stay up to date with this consensus.
Maybe I’m wrong but changing this from “as far as I know” into “we will for X amount of time” could go a long way.
I don’t disagree at all, but I do think it’s a bit of a change of approach from what Meteor was originally. And it will be a challenge to communicate this change to the community at large. Geoff’s talk does touch on this in parts, but its not explicit and it has way less views than it should have.
Don’t get me wrong, my main gripes have nothing to do with the stack in itself. If React is the next shiny thing, by all means let’s run after it.
sidenote: (I’m coming from a Flash/Flex world, dare I say it, where all the ‘chasing the magic’ has been done before with kind of the same outcomes btw :), all the magic stuff of React/Redux/Blaze/Etc… has already been done in another Ecma language, Actionscript, many times in 100 different ways. But let’s keep busy nonetheless. We need another wheel ).
What I meant by being dissapointed, is by the (for me at least) total chaos the eco system is in. It used to feel well taken care of. Lately it has more of a feeling of something that is (kind of) without clear direction. I’m not sure if I’m an old guy yet, but in my experience that’s not a good sign if you’re thinking about adopting Meteor.
Some examples (if I’m talking rubbish, I’m sure someone will put me in my place):
One post of Geoff, getting a lot of people “upset”. Then… nothing. For a long time
His collegues do chime in, but seem to be contradicting what Geoff said (I would assume everybody would be on the same page?)
Although @sashko is right that you could still use Blaze and that it’s still “supported” (thanks btw), most people will still run away from it as fast as they can. It’s been called a dead-end by Geoff (and others). So now all available packages will be in flux as well… who knows which ones will be updated later on.
The guide (which was great) feels outdated even before it was coming out (not saying it’s not relevant at all, it just feels weird if someone said we’re all going “left” and the guide is still being worked on going “right-ish”).
All this focus on the view layer, when there were so other (maybe just as important) issues still unworked on. E.g. an already started SQL innitiative (great!) which was then just left to… die? Nothing, nada. No news, no plans, nothing.
Galaxy… who knows what is going on with Galaxy. No idea. As an outsider? It feels like it’s having a hard time getting up to speed and every available resource is being put on it to get it right. Note: Totally clueless here, so no basis or facts whatsoever. That is probably one of the reasons why Meteor is getting less (is it?) attention.
For me, the only real value I can think of that’s left (for the time being) is a nice integrated build environment. But that one makes me feel silly if I wait for 30 seconds on every file change, and reading Webpack people doing the same thing (and more) in 2 seconds per file change So that value is relative as well lately.
After typing I feel like an “old man” complaining/whining. But don’t get me wrong, the original idea of Meteor was great and made me start using it. I’m hoping it will succeed, so that’s why it is so frustrating to see it in it’s current “state”.
It’s a fact that the conversation on the forums is not representative of all of the people successfully building great apps with Meteor - the number of users that have ever visited the forum is a small fraction of the overall Meteor user base, simply because not everyone is interested in having lots of public discussions about their work tools.
That’s true, and a good reminder for me to keep that in mind. But in this case, I meant I was wondering if the Meteor codebase (platform) wasn’t getting all the love and attention it once got (from e.g. MDG). Even after it has been left in “flux” (no pun intended) by announcements like the one that started the thread.
This is a quote from @sashko that I think sums up the recent moves by MDG:
@sashko, maybe my question should have been, what parts of the stack is MDG going to build and what parts are they going to “outsource”?
I mean, we know that once Blaze goes, Tracker will follow. What will fill in that void? Is MDG going to take one or more of Flux/Redux/Relay and shoe-horn it into Meteor or will we see something custom from MDG?
And to continue, with Blaze and Tracker gone, when will Sub/Pub be put out to pasture? And what are the plans for the replacement?
And further, once Blaze, Tracker, and Sub/Pub are gone, and with GraphQL on the horizon, how long will Mini-Mongo have left in this world? And here too, what are the plans for replacement?
Further, I’ve heard you say on other threads something to the effect that due to patterns and practices around React not being fulling flushed out within Meteor, the Documentation and How-to around the UI are not in place. When will we see something on this? Is someone flushing out these patterns and practices?
The migration from Blaze to React. I know I’d love to see documents from MDG on how to replace portions of a Blaze template with a React components and all that entails.
Hey, just curious (I don’t want to start new topic). What’s the status of this ‘Standalone Blaze’ https://meteor.github.io/blaze/ project? It is so old, but really cool
so you can use Tracker with React without getting unnecessary rerenders? I’ve fiddled with fine grained reactivity in React for quite some time now, and I can’t seem to get Tracker to rerun computations correctly. Please, enlighten me…
For something so, so simple and trivial 150 screens of code and explanations - it’s just ridiculous!
Blaze 2.0 need to be Fast, Simple, Functional, Easy to Learn and Usable in 90% of the Everyday Scenarios and need to take only 10% of the time vs React and Redux.
Blaze-React is ready for review, we’ve got most of Blaze 1 functionality. I hope you like it
Will probably work on building a template parser for react using the learnings from this project. That might be a great continuation of blaze, if not people find this package really useful.
), but it’s all just been a little bit of a let down lately.
It is so old, but really cool 
Keep it up!