Next steps on Blaze and the view layer

core
528

And we all know that’s a good thing because frameworks are evil, right?

I think blaze will be around for years to come and people will keep using it small projects, prototyping, etc. Same for Tracker.

The FUD I’m talking about is that React will somehow infect the Meteor stack, that suddenly everyone will have learn flux/redux and designers will stop working because they can’t learn JSX.

Either MDG or someone else will develop something that’s more user friendly than flux/redux. And given the high demand for .html templates I have faith that’s coming soon too.

If pub/sub will die, it will have to be replaced by something better, because I know MDG won’t go to its clients and say “we’re going to go backwards and take a away features you already had”. I don’t know how it will play out, but @arunoda has already implemented GraphQL on top of meteor collections, and I believe you can still use liverquery/minimongo alongside GraphQL, it’s not necessarily one one or the other. But I’m sure MDG will wrap it all up into a nicer package, if they decide to go this route.

I wrote elsewhere, but it’s relevant:

React is a framework for professional developers. Blaze is great fun way for amateurs and designers who don’t want to spend about 8 hours learning some basic JS concepts.

If you pay attention, you will notice that the way professionals build something is different from the way amateurs build something. If you hire a contractor to build a kitchen for you, they will use different tools and methods than the do-it-yourself person who goes to IKEA to buy ready-made furniture.

People who have been building web apps and UIs for a long time have come to realize that the old, “easy” way of writing code, using JQuery and other code like Tracker (magical but unpredictable reactivity), doesn’t work that well in the long run, and it doesn’t scale for complex UIs.

MDG has said they don’t want to reinvent the wheel (“When we took a look at what [Blaze 2 and components] would look like, it looked a lot like React.”) The syntax may be unpalatable to some, but then again, syntax can easily be fixed.

2 Likes
529

This is quite wrong. It’s on top of Meteor collections.

1 Like
530

Thanks for bringing the mobile aspect up. My day job has seen us just put a mobile app (iOS/Android) into production.

The very reason we chose Meteor was that our native app iOS version was miles behind the Android version, so we decided to give Meteor a go. We had more done in less time and was able to get it run on iOS and Android with no dramas.

So I’ve been reading this thread with great concern as to how the company I work for needs to do to maintain this app if / when we need to go the React route. Will we still be able to build for iOS / Android?

I guess I’ll have to start a demo app and see.

Once again, thanks for bringing the topic of mobile into view.

2 Likes
531

Never mind.

I found my answer in other threads in the mobile category.

Thanks.

532

Would you mind to share the answer you got here? Thank you!

533

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
534

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

535

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
536

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 :stuck_out_tongue:, 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
537

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
538

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.

539

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.

540

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
541

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
542

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
543

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
545

@mordrax

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
546

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
547

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
548

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