I think it was this one (too much Christmas cheer!)
But I found this useful also:
which lead me here:
and then I ended up here after other searching:
1 Like
@vonwao did you read what I wrote?
To quote myself:
I don’t know a thing about intimidating terms like non-optional module systems, react, flux, redux reducers, action creators, component stores, provider context, relay… will I need to know these things at some point soon or be sidelined to Meteor 1.1.0.3 or 1.2? Will I need several courses on this tech in order to use Meteor in the future?
I asked if I’d need to know these things – not making a statement that I did need to know these things.
The reason there’s been fear, uncertainty and doubt in the Meteor community as of late is not simply because MDG has decided to depreciate Blaze. It’s because MDG has not engaged the Meteor community in any significant way. It’s because there’s some substantiated evidence the technology they’re going to replace it with, React, will cause a domino affect that transform Meteor from top to bottom in significant ways. There’s talk of merit from respected Meteor developers that MDG’s new strategy is simply to become a hosting company that distributes JS tech in some opinionated way. If MDG abandons their JS framework and instead becomes a JS tech distributor + hosting company, that’s a significant change that could worry many players.
@vonwao I can’t speak to your Blaze + Meteor experience or how vested you are in the platform and Blaze in particular. But some of us that have invested much time, money, and reputations into Blaze + Meteor are trouble by these developments, I believe rightly so.
This is like not seeing the forest for the trees.
I’ve not read anyone’s posts where they said you’d have to learn flux/redux and designers will stop working. But lets be clear, with React, comes the React way of doing things. Tracker will fall away, what will follow?
Do you think the tech that complements React will not be incorporated? Tech like Flux/Redux/Relay?
I’m on sure where you’re getting your information, but after reading MDG’s comments I think there will be no tempting in Meteor. No Blaze 2, no Blaze over React templating:
1 Like
With Blaze, I use IronRouter, Autoforms, publish-composite, Tracker, Session, ReactiveDict etc etc because that is the ‘Meteor way of doing things’. I took the path of least resistance, aka path of many tuts/books/guides. I spent quite a lot of time reading about parent/child template relationships, asking for help in this forum because everyone was using the same packages and having the same problems. Parent/child template communication, etc etc.
With React, I quickly hit a snag with component communication. Around about my third react component, it needed to talk to the parent component requiring a callback to go through the middle component. React, by definition is a massive tree of nested components. Getting a signal in a child onClick to the parent would be very tedious without flux.
So the ‘React way of doing things’ is with Redux and all it’s jargon(reducers, thunk, middleware). Because this is the path of least resistance with many tuts/guides and because when I hit a problem, I’m going to find alot of people who’ve hit the same problem with their Store/Reducers, but not in their Session variable.
Therefore, saying you don’t have to learn flux/redux with React is kinda like a jQuery dev thinking they don’t have to use Methods/Tracker/Session with Blaze. You could do ajax calls, use a Promise library and keep state in the DOM.
Looking back at this time, the first 9 months building the Blaze app was the most productive time. I almost completed a MVP at work while learning Meteor before being made redundant 
, would have been awesome to publish to iOS/Android app stores too. It was a good goal that Meteor had and I had just got to the point where I knew enough to make a pretty decent app.
The next 6 months of trying React, exploring techs, reading this monstrosity of a topic, finally learning and loving Redux which lead to FRP was the most enlightening time. It brought to me (although with much resistance at first) the ideas presented in Elm, Cycle.js, Phoenix. (Actually I was going to spend the hols creating a cycle.js branch to see how true FRP works, will I still have to learn thunk? middleware? wtf is middleware?! sounds scary…)
So bite the bullet, keep moving. Tracker isn’t next to die… it died with Blaze.
3 Likes
Mhhh…where is the problem when you use https://viewmodel.meteor.com/? Also I have a state for each of my “templates/components” - accessing parents templates state is easy as “this.parent().someData()”.
I have to say that I’m searching for the benefits of React at the moment. I’m using ViewModel and I’m satisfied with it, giving Blaze a better data structure and I can handle my template like components.
1 Like
Man, it’s been a while since I did any Blaze, VM. I loved the idea of ViewModel right up until I couldn’t dynamically bind to any #if or #each dynamic templates as I lamented here:
And it’s not just about accessing parent data, it’s also passing callbacks down to call parents, having the child at different levels of nesting to the parent that you want to call this.parent().parent().parent().someData()? What about reusing a child template for another parent? More templateHelper plumbings in the new parent. Sure there are alot of ways to accomplish this in Meteor using exsting packages, however, I found that redux/actions/reducers handles this in such an elegant way, I was sold 10 minutes into watching Dan’s intro.
Redux makes React… bearable. I hate that I can’t use jade, I really dislike the levels of indentations you have to put in to get a list going, but having redux is making the difference for me so far on my latest attempt at React and it’s only because I end up using React purely as the view engine for VDom and rendering.
You won’t need to learn a lot about module system, react, redux, etc. etc.
Meteor 1.3 (and I imagine 1.4 and 1.5) will be 100% or 99% backward compatible. You can also use Tracker with React, it works great.
And before Tracker 1 is retired, most likely someone MDG or otherwise, will invent a Tracker 2 that is meant for React, and will make things easier than Redux.
Well, I’ve seen plenty of posts by MDG people, so I don’t know what you mean by “engage”, if you mean “appease”, accommodate, coddle, answer the same question over and over again, I don’t think thats their job, their job is to create a good platform for the future.
In the future, don’t invest all your reputation, hopes and dreams in a UI layer, they are a dime a dozen. Instead, learn the basic patterns of JS, modules, etc. then you can easily replace one UI layer, one module, with another.
I think a new technology will be introduced that will be simpler than Flux/Redux/Relay, achieving the same purpose as Tracker 1.
Splitting out a template from a React component is trivial. Adding some more syntax sugar on top of JSX is very easy also. “100% Blaze-to-React compilation” would probably be a bad idea anyway, because it would give the illusion of backwards compatibility, when the semantics are different.
2 Likes
This sounds condescending. If you were around Meteor a couple of months ago, we all invested in Meteor and Blaze – because Blaze was the official UI layer – there wasn’t a choice. We all learned the basic patterns of Meteor – because Meteor had its own way of doing things. Now MDG has a responsibility to provide a easy transition and upgrade path for all the developers invested in the platform.
You seem to be making two points here: (1) That Tracker is accessible and Flux/Redux/Relay is not very accessible. I agree with this. (2) But don’t worry, MDG will build a Tracker 2 that will “fix” the complexity with Flux/Redux/Relay.
I’m sorry but I’m not convinced that MDG will do anything of the sort. Where’s your evidence?
Again, this sounds condescending. How are Meteor developers with no React experience to know how trivial it is to convert? If it’s so easy, why hasn’t MDG provided an upgrade path and how-to on this themselves? I’d love to see a step by step on converting portions of a Blaze template to React.
I’ve not advocated for a Blaze-to-React overlay. I want a clear upgrade path from Blaze 1 to React (and any satellite tech that may be required) with support from MDG. How-to guides, videos, maybe even tools to help with the upgrade process. I want to come along for the ride, but the migration path is going to be long and costly. Since Blaze was the official UI for Meteor and we didn’t have a choice, I believe it’s MDG responsibility to help with migrations.
5 Likes
I think it’s pretty hard to write a constructive response to 500 comments, but I know Evan is working on making the plans for the near future more concrete. We all just went on vacation for a couple weeks.
4 Likes
Thanks Sashko. I understand where you’re coming from, but I’m not talking (only) about a detailed response for every forum item. Even a “ping” every now and then would be a lot better than how it was. Leaving everybody discussing about choices MDG is or isn’t making (adding to the confusion). I get that not everything is clear upfront and is in constant flux for the time being. But to give an example, people being confused about statements regarding a “Blaze 2.0” that is or isn’t coming from MDG, should have been cleared up much sooner I think.
Vacation is as important as anything. A little heads-up would have been nice though, after the initial bombshell from Geoff (in november btw, long vacations at MDG haha), that further actions would take a while. Because for me as a semi-outsider, everything Meteor related is becoming more uncertain/unclear by the week. Having clear guidance/direction from MDG would help.
1 Like
Those were problems with v1, I encourage you to take a look at v2 on viewmodel.meteor.com. To address your issues:
- ViewModel works seamlessly with
#each,#if, and#with. For example you can do the following:
<body>
{{#with person}}
<div {{b "text: this.name"}}></div>
{{/with}}
<div {{b "text: person.name"}}></div>
</body>
Template.body.viewmodel({
person: {
name: 'Alan'
}
});
It prints the name twice, once from the context of #with and then from the context of the body view model. See this and inheritance.
- V2 has mixins which make global helpers moot. Take the common scenario of accessing user data (and functions around it). The way to do it in Blaze is to create a global helper for the templates and if you want to access it via code you need to put the functions in a global object. With React you have two choices: 1) toss the properties and methods down the component tree like a hot potato, or 2) create a global context for the component tree.
With ViewModel you define the mixin properties and methods and then any view model can opt-in to have/use the mixin.
- Component communication (not just parent/child or on the same tree) is achieved by sharing properties. Let’s take the common scenario of having a list, being able to select an item, and then another component present information about the selection. With ViewModel you can simply create a shared property and use it on whichever view model that needs it. e.g.
<body>
{{> peopleList}}
{{> personDetails}}
</body>
<template name="peopleList">
{{#each people}}
<div {{b "text: this.name, click: selectedPersonId(this._id)"}}></div>
{{/each}}
</template>
<template name="personDetails">
Show information about the person with id:
<span {{b "text: selectedPersonId"}}></span>
</template>
ViewModel.share({
peopleSelection: {
selectedPersonId: ''
}
});
Template.peopleList.viewmodel({
share: 'peopleSelection',
people: [
{ _id: 1, name: 'Alan' },
{ _id: 2, name: 'Brito' }
]
});
Template.personDetails.viewmodel({
share: 'peopleSelection'
});
That’s a lot cleaner and easier to read than firing off an event, catching it on another process which will then update the state, which will then be used by another template.
3 Likes
Echoing @Ben’s position. Responses to 500 comments is not the answer. Meteor guide helps a lot but reads much more as advice for the present without regard for the future. Blaze is front and center with nary a mention of MDG moving away from it. I read it and it says Blaze is officially supported, but what does that mean? Its officially supported until its not? How long will it be supported? Afterwards will it then be turned over to the community to manage?
It’s great that @evanyou will start on a more concrete plan a month and half after the community was left floating in the wind without one. The future is very unclear and it seems we get more bankable insight into the future plans of Meteor from @arunoda’s guesses than we do from MDG.
I get that the JS eco-system has changed significantly, which is driving a lot of the shakeup, but what can we trust MDG to provide long term? Certainly not Blaze, probably not Tracker, Fiber based server-side is starting to look less necessary. Is Minimongo the right complementary tech to React/Angular? Will pub/subs withstand the test against GraphQL?
None of this is to say I’m disappointed or really have a right to complain. I’ve been happy with my development experience. It’s just that for the longest time it felt like the future was being created here. Now it looks like the future will be created elsewhere and MDG will focus on being the glue for some disparate pieces. Do I believe Meteor will be a good JS infrastructure delivery system? A resounding Yes. Do I believe it would be wise to plan any long term investment today in any MDG developed magic like the things mentioned above? Unfortunately No.
The real question is what does MDG want the community to trust them to be?
7 Likes
I’d say the opposite - it was written with great regard for the future, and we are taking great care to make recommendations for which we can pave great transition paths. For example, you might notice recommendations about splitting your UI into “smart” data-loading components and “reusable” and easily tested components - this will lead to a very natural transition towards a React component-based UI, without having to rewrite your data loading logic, methods, or anything else except for some mechanical transformations to your HTML that you can do incrementally.
I’m sure we, or people in the community like @sacha who is already working on this, will produce resources on how to transition to any new stuff in future Meteor, but we need to know what the starting point is.
Right now, there are 1000 different ways to write Meteor apps - we can’t produce transition guides for all of those. So step 1 is writing down the patterns for today, then when we talk about transitions we know where to start.
If you ask me, it’s a coherent story for how to build a complete app, with advice about how to transition from one to the next, through the Meteor Guide. This story will be supported by some core technologies like the data system and build tool, an ecosystem of useful packages from Atmosphere and NPM with some recommendations, and commercial tools like the Meteor developer subscription and Galaxy.
I think the biggest problem is that we didn’t put in effort to make parts of Meteor easily adoptable outside of the Meteor ecosystem, so we didn’t get people from the wider JavaScript community helping to maintain those projects. You’ll notice that a lot of our more recent moves are trying to go in a direction that will align us more there. For example, aligning the next generation of Meteor view technology with React will allow us to more easily take advantage of new features developed there, for example React Native. It’s also important to go in the other direction - I love @sam’s strategy with Chimp of making a tool that works well with and without Meteor, so that it can have a diverse community.
I think there is a limited conceptual budget for how much new stuff Meteor should have compared to well-established tools from the outside, for example it doesn’t make sense for us to have Tinytest when Mocha is a much more popular and better documented alternative.
12 Likes
I think this is absolutely true in places where the text is agnostic to Meteor built infrastructure (those parts are truly great) but its much more grey where that infrastructure is referenced. I believe you if you are telling me that the patterns for the integration of Blaze, Minimongo, Tracker, and Pub/Subs will lead to an easy transition to their future replacements. I don’t necessarily believe you if you are telling me that the most up to-date thinking inside of MDG is that these tech pieces will be around for even the medium term.
Can we trust your opinion on this to be the official position? If we can great. If we can’t then your response is helpful commentary but can’t really be qualified as an answer.
One wouldn’t have to take too big a leap to infer from this that the only things we can trust to be around long term are things that MDG A) starts trying to get wider community adoption on B) are not being maintained by MDG directly, or C) are obviously directly tied to MDG’s business case. I’m assuming I’m wrong here but I don’t know how else I should think about it.
Apologies, I think I’m starting to sounds like a prick. No need to answer anything in this post, just food for thought.
3 Likes
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.
3 Likes
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.
3 Likes
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.
@sashko is certainly correct when he says:
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.
3 Likes
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?