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:

If you listened to talks such as these, you’re probably scratching your head right now, or ready to send an angry comment my way. But pay close attention: the React team has decided that libraries are bad, polyfills are better, transpilers came next, and now we’re reverting to a stage where they want their code to look as much like standards-based javascript as possible (thank you Babel!). Their stated goal is to be able to deal with upgrades gracefully — because they don’t have to switch out an entire abstraction that they eventually decide they hate. But more importantly, the hidden message is they want to make it easy for abstractions to be built on top of what they are building because they are explicitly built on javascript standards! Regardless of whether doing that goes against their internal best practices.

They may not present it this way in their talks, nor the various javascript gurus that regurgitate their perspectives. The way they presesnt is: explicit functional immutable unidirectional code based on standards not abstractions is the only/best way to write professional maintainable applications that you (especially larger teams) can reason about as your app grows. But the reality is they are stating their own internal goals. If you can write something that does exactly what you want in 10 lines of code via one options instead of the 100 lines in another option, which option are you gonna choose? There’s a reason Wordpress is still in business, limitations to its customizability and all. There’s a reason novice and intermediate developers settle on high level, but leaky, 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.

So I don’t buy that because Facebook representatives give a few talks a few times a year about their philosophy that it makes any business sense for us. When you get to the level that you “overstand” every piece of software they’re pumping out, have studied Elm, have studied and put to use Clojurescript, are writing your own Relay abstractions, you begin to earn the right to say what’s truly for you and what is not. Ahem. Everything they are doing is truly for me, for example. I’m not a naysayer. But I’m not sure it’s truly for you. lol, just messing wid you. But you get what I’m saying — we need to simplify these awesome tools to broaden the target audience. My hunch is that the audience that can access Relay, Redux and GraphQL is about 10% of the audience that Meteor today is accessible to, which is basically anyone who just leveled up from HTML and CSS and has started to play with javascript. You can be that much of a newb and start using Meteor! In fact, I think Meteor is the precise best place to start learning javascript. That certainly is not the case if you want to setup Relay containers, Redux reducers, bind em all to your component, (have I missed anything?) and send them over the wire via webpack.

So this is a tough point in time for Meteor because we have to support all this stuff too. We just need the training wheels version as well. If Meteor can continue to get right what they’ve always gotten right (distilling workflow into its simplest form) during these fast-paced times, they are gonna go very far. It’s harder than ever now, given simply that the latest round of Javascript tools are more complicated true pieces of engineering than the Javascript community has ever seen before or had to contend with. So that’s why this is a defining time for Meteor. Just looking at all this stuff, it’s clear it’s going to take an act of god to wrap it all in sleek facade layers that add the necessary sheen for novice developers. However the harder part is than reconciling that with the upgrade path that the advanced developer wants to take — making it natural to start out with the easy pub/sub abstraction and refactor your code into the advanced GraphQL/Relay version. That means that elements of Relay/GraphQL should be in the basic pub/sub approach — making it so it’s a natural progression to explore more features in it until your code looks like the real thing. That’s as opposed to 2 separate versions: the easy approach and the advanced approach. There has to be a gradient; the easy approach has to allow you to evolve it over several optional steps to eventually become the super advanced approach. I know that’s kind of abstract what I’m saying without examples, but try to imagine what I mean and if you can’t, this article likely isn’t for you.

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:

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.