Tracker vs. Redux, Implicit vs. Explicit
Meteor is at a pivotal point in its lifespan. Meteor is grounded in a high amount of automagic and ease — definitely when compared to React and the Facebook stack, which is based around explicitness, even when it means repetition for the goals of predictable easy to reason about behavior by large teams on large apps. Using the entire stack they advocate for simply is too complicated for novice to intermediate developers — the category that the majority of developers fall into, basically by definition.
So, while it might seem that Meteor is in a gloomy place since it can’t as easily take advantage of these tools, given its an opinionated full stack framework that requires extra time to fit new pieces into properly, this is actually a major opportunity for Meteor. My prediction is all this stuff will be big, but anything beyond plain React will need a lot of coaching and help from 3rd parties. There will be more and more abstractions on top of all this stuff. I think Meteor needs to take a stand — and early — that it will continue to provide its signature implicit automagic, and now on top of these things.
Facebook has effectively flipped the web development stack upside down. Before it was HTML, the DOM, Rest and MySQL; now it’s React components, Flux, Relay and GraphQL. But just like HTML, DOM etc before it, these things will need abstractions on top of it.
If you’re following people like Sebastian Markbage closely you will hear this is exactly what he’s laying the groundwork for.
6:04 — checkout what Sebastian has to say about Polyfills and our time since:
13:20 — give a listen to what Sebastian Markbage has to say about abstractions:
All this leaves a lot of opportunity to get abstractions right where Facebook feels too high level of an approach doesn’t give their core developers enough control — keep in mind everything they built they originally built for themselves, i.e. super experienced developers that rather have supreme customizability than high level inevitably leaky abstractions. So, from a shear business standpoint, there’s a lot of value left on the table here. Pretty much the entire pie, given that Facebook is just pumping out the new protocol for how the web operates for free.
We as the Meteor community can’t just take what the army of Facebook Stack Regurgitators are saying as marching orders to us. They aren’t our boss or captain. We need to invest the time and pick the best parts, and determine what applies to us. For one, I personally am not going to let Tracker and Minimongo go so fast. I think we have something truly magical there that can pair up nicely with the Redux/Relay way of the future, perhaps as just the perfect amount of implicit automagic novices will continue to need to start out. Perhaps exactly what all of us want to use for most of our app(s) until we find a problem area we need to box in with a step-by-step unidirectional “trap.” Right now it feels very much like: “if you’re not doing it the Redux way, you’re doing it the wrong less professional way.” I can’t easily buy that. Not when looking at all the extra boilerplate I have to write compared to how easy Tracker + Minimongo is/was. There must be ways to solve our Tracker usage without throwing the baby out with the bathwater. If you’ve been following my forum posts, you’ve probably picked up on some clues I’ve dropped. I’m going to cover it another time — basically we need to better constrict our autoruns, and in addition we should build time traveling (via snapshotting) into Minimongo, Session and ReactiveDict. A lot of the so-called benefits of Redux we can accomplish with Tracker — it just hasn’t been done yet. In addition, Tracker can be built nicely into Redux — it just hasn’t been done yet! That would make for a very nice “level-up path” when you deem your app has reached a level of complexity where you don’t want to use automated action creators+ reducers provided by Tracker (well, TrackerRedux), and rather manually control control it for a complex/problematic scenario.
Hopefully you guys get the idea — we can participate in all the new useful tools, but we will benefit our beloved platform, Meteor, and ourselves more by imagining their usage — ah fuck it — I was gonna say “by imagining their usage as part of a phased and optional approach, etc etc,” but the reality is I’m only really talking about Tracker — Here’s the deal: if you use Redux + React as is, you’ve removed Tracker from the equation. You don’t need it. Where you interface with Meteor basically leaves off with subscribing to publications. Meteor in effect has gone from being a “full stack” framework to a server side framework, pretty much. That’s not going to be a good thing for Meteor, and ultimately our selves. So the question is: do we really need Tracker? Does Tracker add any real solid value on top of the functional “render the whole tree” approach. It’s a question we have to ask ourselves long and hard. If it doesn’t, throw it in the garbage. It will be a rainy day for Meteor, but we’ll figure something else out (Enterprise-quality React + Relay components??).
Now that said, I think we have actually lucked out! That’s my hunch. I’m not done with all my explorations here. But basically, Tracker fills in a major missing need of the React Stack: the implicit super easy option. Think of it this way: in life, you gotta define yourself right? Often times you find yourself in a situation where one person is super strong in one area, so you realize your only decision is to be as strong as you can in the area you know that other person is weak in. Got me? I think we need to explore this option — yes, React and everyone is saying “no no, that’s the past, explicitness is the present/future.” Yea, but everyone else is doing that now. All the experienced developers are promoting that path — while leaving the novices that join our industry daily, in droves, in the dust. Facebook literally just faked them all out for us. It took me forever to understand both Relay and Redux (and React before that) — nobody just coming from Code fucking Cademy is learning that stuff any time soon. Pardon the french, but it’s that big of an issue.
So by identifying the problem, defining ourselves, etc, we can take a stand and continue to be the most useful all-included application development toolset available. Just as it is with everything, it’s all about the how you look at it. We can make lemonade here. But first we gotta stop kidding ourselves; pretending that Tracker, Minimongo and Blaze are as professional as these new solutions. Once you’ve leaped over that hurdle (of which many of us already have), we then gotta be honest with ourselves about these new tools and realize they require a lot more work and boilerplate than various abstractions we can imagine, and perhaps the vast majority of apps will never reach a level of complexity that will require that level of debuggability and ability to reason about. Translation: the honeymoon period is over. Then we gotta build those abstractions and tie em back to what we got right in the original abstractions. Finally, Tracker is the key. So many things are already coupled to Tracker — that if we can make Tracker make sense and if it can truly become our savior (or that of the intermediate developer) then we may have something up our sleeve that nobody else has.
Tracker automates a lot of what you gotta go do with Redux and React. Go find how you can continue to make it useful with React and Redux. That’s my suggestion. That’s what I did with TrackerReact.
If that’s not enough for you and you don’t want to wait until TrackerRedux comes out, I suggest you check the following out:
Edit This Page Observable data. Reactive functions. Simple code. Mobservable enables your data structures to become…mweststrate.github.io
That’s a model for Tracker-style autoruns built for React completely unrelated to Meteor. It doesn’t use Tracker, but it achieves the same “sideways data loading” effect that TrackerReact achieves. That’s a pretty high quality looking piece of ware; that documentation is more thorough than our own “autorun” documentation! — see, look, they even have a method called autorun: https://mweststrate.github.io/mobservable/refguide/autorun.html.
There’s a lot of good things said about Mobservable on the net. If you look at it, it doesn’t look too shabby. The performance implications of not having to re-render the entire tree — due to “sideways data loading” — are an important topic to follow. Even Sebastian Markbage basically tells us it will be a best practices strategy in the near future:
35:04 — ReactEurope 2015 (July 2–3, um just recently):
So you get the idea. Fun stuff. It’s not all about pure functional development. If it is for you, just go to Clojurescript (Om), Elm or Cycle.js today. Until then, we don’t gotta leave Tracker behind. We should go digging for gold, looking to salvage whatever we can, and we may be pleasantly surprised. I know I was with TrackerReact, and same with basically everyone that has taken the time to give it a shot. This post wasn’t even intended to be a promotional piece for TR, but what more can I say: Tracker is the glue that connected Meteor’s server side functionality with everything going on within the Client. It makes whole swaths of things easier than the extremely explicit React/Redux/Relay approach, though once your app gets big, I do agree, it becomes hard to reason about.
So the question is how do we get the best of both worlds? Easy prototyping until we find areas that need to be “trapped” by a functional approach?? Just maybe, just maybe, we should give Tracker a shot, and invest some time into figuring out its place in the new Facebook Stack.