Sign up for JS Remote Conf!

 

03:22 - Andrew Clark Introduction

03:39 - Dan Abramov Introduction

04:03 - Flux

09:36 - Data Flow

22:52 - Conceptualizing React and Flux

27:50 - Documentation 

30:38 - The Elm Programming Language

32:34 - Making Patterns Explicit in Frameworks

36:31 - Getting Started with React and Flux

42:42 - Where Flux Falls Short

58:23 - Keeping the Core Small; Making Decisions
On YouTube
181 JSJ The Evolution of Flux Libraries with Andrew Clark and Dan Abramov

Picks

Strange Loop 2015 Videos (Jamison)
Typeset In The Future (Jamison)
Open-source as a project model for internal work (w/ speaker notes) by Kevin Lamping (Jamison)
Explanation of Zipf's Law (Dave)
Will Conant's talk at UtahJS 2015 on Flux (Dave)
The Legend of ZERO (3 Book Series) by Sara King (Joe)
Camel Up (Joe)
The Elm Programming Language (Joe)
Boundaries: A talk by Gary Bernhardt from SCNA 2012 (Aimee)
Nodevember (Aimee)
TV Fool (Chuck)
RCA Outdoor Digital HDTV VHF UHF Yagi Type Antenna (Chuck)
The Michael Vey Book Series (Chuck)
BusinessTown (Dan)
Elon Musk: The World’s Raddest Man (Dan)
Professor Frisby's Mostly Adequate Guide to Functional Programming (Dan)
Abiogenesis (Dan)
react-future (Dan)
The Righteous Mind (Andrew)
lodash-fp (Andrew)
Inside Amy Schumer (Andrew)
dataloader (Andrew)
Careers at OpenGov (Andrew)

Special Guests: Andrew Clark and Dan Abramov .

 

I was actually – in honor of Halloween month, I was actually thinking about doing a Dracula. Let us do the podcast.

Hey everybody and welcome to episode 181 of the JavaScript Jabber Show. This week on our panel, we have Aimee Knight.

Hello.

Dave Smith.

Hey, hey, hey.

Jamieson Dance.

Hey, friends.

Joe Eames.

Hey, everybody.

I'm Charles Max Wood from DevChat.TV. I just want to do a quick shout out. I just launched the JS Remote Conf website. So if you are interested in attending that conference, go to JSRemoteConf.com. You can use the code ‘Jabber’ to get 25% off.

Another thing to point out is nobody [inaudible] Joe at Dave's like we have stone faces.

Yeah.

We're professionals.

That's right.

You have no idea how hard that was.

Or you have no sense of humor.

I just didn't get to my unmute fast enough. [Laughter]

Yeah, it's almost like you need a cat joke.

Do we have any guest today, Chuck?

We have two guests today. We have Andrew Clark.

Hi, everyone.

And Dan Abramov.

Hi.

Do you want to introduce yourselves quickly? I know, Dan, you were on a couple of weeks ago but…

Sure.

Yeah. I'm Andrew Clark. I work at a company called OpenGov. I've been doing web development for about like a year and a half. And I was the creator of a Flux library called flummox and I have a few other libraries and I help out Dan on Redux.

Yes. So, my name is Dan. I'm mostly visible in React ecosystem. I started doing JavaScript a few years ago. I'm known as creator of React Hot Loader, the [inaudible] for React and Redux which is a take on Flux but is not exactly Flux.

Alright. Well, I don't even know where to start so, somebody else help me out.

We talked a little bit about Redux a couple of episodes ago but I don't think we ever sat down and talked about Flux. And Flux is a broader idea. Can one of you give us an explanation of what Flux is?

Flux is a solution for doing data management in a JavaScript application. It was released about in May of 2014 by the folks at Facebook as an accompaniment to the React Library. React is unique from these other libraries like Ember and Angular. It doesn't really have a built-in solution for doing data management like typically you use a Model View Controller and Model-View View, some kind of system like that. It's really an alternative to one of those types of systems. In a way you can think of it as an inversion of MVC whereas in MVC, you have these views that will update these models directly.

Flux is a little bit of an inversion where the stores update themselves. They broadcast the change event and then the views reflect whatever state the stores are currently in. And all the data goes in a unidirectional flow so it goes really well with the unidirectional data flow that in the React model is not necessarily tied to React. But effectively, it is the unofficial way to do data management in React applications.

For people that aren't familiar with it still, do you think there's any benefit in explaining it by contrasting it with MVC or do you think that that is, it's just too different? I've heard some people explain it in those terms and that for people who've only done MVC sort of helps a little.

Yeah. So, I come from an interesting point of view because I actually haven't done that much application development before I did application development with React. I made an IOS app so I was familiar with MVC that way. It's probably not like if you're coming from it without any knowledge of Flux at all, I don't think it's all that helpful to contrast MVC. I would maybe just think of it as an extension of the unidirectional flow of React.

So, if you're familiar with the way data flows in React app where things start at the top component and flow down as props to the down component tree, it is just an extension of that flow where if you need to store data in an external system that's not just local to a component, that's the best way for me to think about it. There are some charts out there which personally I think are a little bit confusing. But you'll see there are basically three main parts, there's the dispatcher and we'll talk about the dispatcher.

First, Redux has a dispatcher. But if we're talking about Flux in general, usually there's a dispatcher, there are stores and there are views. Those are the three main areas of a Flux application. And then you have these things called actions which is if we're going to compare it back to MVC again, those are basically like events. All of these events flow through the dispatcher, go to stores and then the views update with the stores and it just goes in this circular unidirectional flow. I've just been realizing that. It's hard to explain unless you are actually looking at it. Dan, you have a better way of explaining it?

I would just say that I don't fully agree that it doesn't make sense to compare Flux with MVC because actually when I explain Flux to people, I usually compare it with MVC. And the way I compare it is that I explain what Flux doesn't have and this helps people get up to speak with it. So what I say is that Flux does not have models because in a way, yes, you have stores and they're like models but they don't have setters, right? You can't set things. You can't modify them from outside. This is big important thing about Flux.

Another important thing is that you don't have a bunch of objects that you call methods-on. In MVC, you have models and usually they're like active records. They have some methods that you call them and they modify the state. But you don't have that with Flux. So, this is one thing that falls apart. Another important aspect of Flux is that it doesn't have different kinds of change events. So normally in any MVC application, you have this field change, this other field change and they are all different events. But in Flux, you get just one change event. There are no other change events.

So, that's what helps people understand some aspects on Flux architecture that come from MVC.

That's a good way of putting it. Yes, stores don't have direct setters. Another thing that really helped me was when you think about how a view reacts to a store update. The store updates receives an action. It updates themselves and then it makes a single change event. It doesn't have different levels of granularity for those change events. They basically just broadcast to the world, "Hey, I've changed." And then the views just reactively, they reflect, they always reflect whatever the truth is inside the store.

Yeah, that's the reason, sorry for interrupting you.

No problem.

I just want to say that that's the reason why Flux did not exist before React because we didn't have view framework that can just update the view just to reflect some model. You always have to do something…

Very imperative.

Yeah, yeah.

All right. So, I heard a couple of things that I want to go back to and talk about that you guys said. So, Andrew, you'd said when we were talking about Flux and the one-way data flow. You compared it. You said it's a natural extension of React's flow from the top level component down to the bottom lower component as data flows from that top level component and down, which I find to be a very interesting statement as talking about that as the one-way data flow.

Everytime I talk to people about one-way data flows versus two-way data flows, it's not so much where the Components are also a representation of the DOM tree. So it's not a matter of where it flows in relationship to the DOM, it's where it flows from changes to your model through rendering then into the DOM versus top of the DOM going on down. So, I find that to be an interesting view, one that I've never heard anybody take before. So, I don't know. Was that just my ignorance?

Well, do you mind me asking do you use React often or which framework are you usually using?

Well, I'm far more experienced with Angular than with React.

Okay. Well, in React at least, I don't really have that much Angular experience. But in React at least, the main way that you… when you're talking about just the view part or the component layer, when you're passing information from a component to another component, the only way to do that in React… well, there's this big asterisk here but we'll call context but we'll ignore it. The only way to do that in React is via props which are analogous to like attributes on a DOM node like that you’d write in HTML. The only way to pass information is via these props. And they always, they can only go one direction.

You pass the prop from the owner node down to its children inside the render method. That is the only way to pass things. It's a really nice part about React because it makes everything very predictable. It means when you're looking at a component, you always know exactly where all the data's coming from because it can only come from its props. You always know where it’s passing data to because you're passing it via the props to its children.

If you ever want to do any mimic, any two-way data binding - in React, what you have to do is you have to do things like pass a callback down to the child. Then the child will call that callback and that allows the parent to access some new information. So for instance, that's how you implement an input field or a form in React is you have to pass these callbacks; these change handlers down to its children.

So if you're just first learning React, that's a little bit different than to how some other frameworks have done it in the past where you have two-way data binding. There is a little bit more, I guess, boilerplate involved or that might be the wrong word but there's a little bit more steps that you have to do to get that to happen. But that's the essence of unidirectional data flow is that data always flows from the top down to the bottom.

Flux gives you a way to extend that looping model where rather than passing a callback to the child, if you're using Flux, you can fire off an action which goes to the dispatcher which is completely separate from the component tree. Then the dispatcher sends it to the stores and then stores go back to the view. It just makes that loop a little bit bigger and allows you to do things that aren’t mapped so tightly to the component tree. Sometimes data doesn't necessarily need to flow in the form of that tree.

What I interesting that you consider the flow of the data through the DOM to be a salient point here as I see and read and discourse with people about this topic, it seems to be that the focus is on the data flow through its changes and not necessarily through the DOMs. So for example, when you say React has a one-way data flow from top to bottom in the DOM, yes, it does. But I don't consider that to make it… well, most people would consider it to be the one-way data flow. One way data flow, as I see it is a matter of I've made changes to the data. Now, I've got to completely render that out. I can't during rendering make other further changes to the data. And that's…

Well, you're correct and I don't think that's wrong. I don't know if necessarily if we even disagree here. I will just say that I would make a distinction between a component tree and the DOM tree because at least personally, I've stopped thinking of my React's Components as just mapped. They don't necessarily always map to a DOM node, right? They're just ways of encapsulating different parts of the application.

Yeah, normally you have DOM nodes at the leaf part of the tree. So, most of your app, you express as Components passing props through other Components and DOM is at the very bottom of that.

Right. Right.

Right.

This might be a good time to introduce this article you shared with us before the show called Why a FluxComponent is Greater Than FluxMixin because I think this is some of the context where you're coming from, right, Andrew?

Yeah, there's another one right next to that that Dan wrote called, what was it called again, Dan? It was…

Mixins are Dead.

Yeah. Mixins are Dead. Long Live Composition. And this is an important concept. We're getting away from Flux here a little bit. But this is an important concept in React in that the primary way of scaling your React app, the primary pattern that you use is Composition not Mixins or inheritance or anything like that. So, that's why maybe without some confusion about the term unidirectional data flow is you have to think about data passing down through these Components.

So, that article I wrote Why FluxComponent is Better Than FluxMixin, it’s a weird title. It was specifically a document that I wrote for my library called Flummox. This was back in a time when there's this explosion of Flux libraries since Facebook never really released an official Flux framework. A lot of them were coming out with solutions for how to integrate with your React Components in a not terribly repetitive way. Because what people were doing before these frameworks was they would just manually subscribe to these Events. They would use these life cycle hooks and call set state. It was just a lot of boilerplate.

So, these libraries started coming out with these Mixins that you could apply to your React Components to do all that stuff for you. And around the time I wrote this article, I was realizing with React you don't really want to use these Mixins. It's much nicer if you can use a component-based interface for describing how to subscribe to store updates. So, this is an article that's just showing how Mixins, they're very popular in other types of libraries. People might feel comforted by them. But if you're going to use React and take full advantage of the React's component architecture, you want to use Components whenever possible in preference to Mixins.

This is also related to this another link that I put in that document describing what higher-order Components are, another very important concept in React especially recently where rather than using Mixins, you describe these functions that will return a Component. In that way, all of your abstractions are just based on your Components and rather than having to inherit from all these different things using Mixins.

Sorry, if I could just interrupt for a very quick statement. I wanted to say that just to clarify about the top down data flow, the important part is that in React, any state is owned by some component. So, if there is an input state, it means to be stored in some component either this component or some component of the tree. Only this component can change it.

With Flux, what happens is that we store that state somewhere outside of Component and we need an entry point for that in Component tree. So, this is what this Flux Component does. And previously, people use Mixins to make other Components in their application, these entry points for data or sideways data from flux to all.

So, do you guys consider the flow of data from a top of a component down through child Components to be what people owe the key point of one-way data flow versus the flow of data through like Flux through action creators, dispatchers, stores and then into render?

Yes, so basically what I think happens is that you can just go… both are one-way data flow. But with Flux, you add more predictability to it because instead of having some root component that updates the state in response to callbacks, you move that logic into a separate place outside the component. You describe every mutation as an object, as an action. So it is possible to record and play them for example or to log every mutation there and that will be part of the callbacks. So Flux is just making this pattern more predictable.

So, do you consider Flux to be basically an extension of how React via itself is a View library works or is Flux an entire… React by itself is one-way data flow. And Flux just canonizes it a bit more. Adds a little bit more ceremony and structure to it or are they entirely two separate things? I don't know if that question makes sense to you.

Yeah. I think I see what you mean. If you look at the websites for either React or Flux, they're going

to talk about unidirectional data flow. They're slightly different in that. React it is very Componentspecific when it's talking about where the data flows. But honestly, I don't think it's all that different. At least in my head when I'm modeling in my head, to me it's an extension of the entire flow of data as it moves toward your application.

The data moves from an older Component down to his children and then the children might fire an action. Then the action goes to the dispatcher and then to the store and then back to the component. To me, it's all part of the same unidirectional data flow. I don't see them as two separate things.

You see React by itself as sort of a mini Flux?

I wouldn't say that.

I would. And that if you saw recent tweets by Sebastian Markbage who is one of the masterminds behind React, I think he's a little disappointed with everyone having to use Flux. He sees it as a shortcoming of React state model. So perhaps in the future…

Who's this?

Sebastian Markbage.

Ah, okay.

Sorry, I'm not sure how to pronounce his surname.

I think that's right. I put that tweet in the document as well.

Yeah.

So Joe, I think I know where you're coming from with this because basically when React came out but before Flux was really being talked about, no one really talked about one-way data flow. That wasn't really in the vernacular that I observed anyway. So Flux came out and everyone started talking about one-way data flow and it was great and stuff. Now, one thing that people did say early on with React was two-way binding is not part of React. And so, it's a one-way binding. So, you hear that.

But one-way data flow, the term really came out when Flux came out. What I've been seeing is that the concept of one-way data flow has leaked out of Flux and back into your component architecture in React applications themselves. It really permeates every part of the app. Not just how you pass data between dispatchers and stores and views but also how your Components themselves receive their data and send data around is all one-way as well.

So, I think that's probably why you're wondering because you haven't early heard it in the context of the React component model itself. Does that sound right?

Yeah. Well, and another piece of this is the idea of one-way data flows in a simple explanation that makes sense to people that haven't been dealing with React is challenging, to say the least. I deal with a lot of people who work with Angular and trying to explain what the difference is, what oneway data flow truly is and how it's different. But in my mind, I'm always thinking about the circle. I've got experience with Elm as well as Angular and a little bit with React, my mind is always a circle of a change moves over to some action creator, dispatcher, store or whatever the flow is based on the framework you're using.

If it's Redux, it's different. You got reducers. If it's Elm, it's different. But that flow of data, so I'm trying to explain that. That's actually fairly difficult concept to explain to somebody that's never… I mean, Dave Smith, you actually had the most awesome slide at React Rally explaining your version of Flux in your sprinkler system.

Oh, boy!

Yeah, I was going to ask you to talk about that.

You mean where I just like deleted 80% of the boxes and said, "This is what I do."

Yeah, where it's like Flux is not a library. It's a pattern and I don't know, you had an interesting way of pointing out your impressions of Flux.

If anybody hasn't seen that talk, you must see that talk. That's talk this year.

You should ask the React Rally organizers when it's going to be posted online.

Soon.

Anyway, know that if you do see that talk, it might be out by the time you get this, I don't know, no pressure, Jamieson. But basically you got to keep in mind, it was a joke. The whole talk was a joke.

That's all I'm going to say about it.

I think there's a kernel of truth in some jokes though. My impression of the talk was really, really funny but I think there's some truth to your implicit criticism that Flux can seem like just a bag of words. If you have done MVC for a long time, there's a really explicit place to put everything. You have a lot of ingrained training. Now, when you take that…

[Inaudible].

Yeah. I guess the explicit place is where the framework that you use has to put it. But with Flux, there's so many different frameworks that even though they share common ideas, I still found for a long time like I don't have to sit down to write an app and be like but how I've read that diagram a thousand times. I see the little square that it makes and what code do I actually type to make it work.

Yeah. So Dan and Andrew, what do you say to people when they say I just can't get this in my head. I'm having a hard time conceptualizing.

Oh, I totally agree with everything you just said. I remember the first React app I ever made. It's also the first Flux app I ever made. It was terrible. It was the worst code ever. I shattered it. I mean, the app ended up being not so bad but the [inaudible] awful. It almost made me not want to do React.

I mean, I like React itself so much that I kept pushing forward but I agree. I think one of the reasons why there were and there have been so many Flux frameworks, just an explosion of libraries, everyday there's a new pun on Flux and a new library to go along with it. I think one of the reasons is just that it is just like a bag of concepts and there wasn't a lot of clarity over how to put all these ideas into a coherent framework.

And nobody was sure what's important or what's not.

Right. If you look back there was a talk at React Conf in February where they got Bill Fisher, I believe he was the moderator. He's one of the creators of Flux. He had a panel with six or seven people from different companies. Some of them were different people internal to Facebook and each person was describing how they do Flux on their team. They were just totally different. Everybody had a different way of doing it. Some people were doing data fetching inside of the store. Some people were saying that we don't do that at all. We do all data fetching in the action creators.

I remember watching that and going this is bananas. That was one of the motivations behind when I made this Flux library called Flummox was I was trying to distill down all of these weird crazy concepts and find okay, what's actually important. What can we get rid of? What can we abstract away from the user? Just try and find an API and a library that got rid of all these extraneous stuff and really focus on what was actually important. So, I think I got pretty close [inaudible] made some mistakes.

Redux, I don't know how much you guys talked about Redux with Dan on the last podcast. But I think Redux is if you noticed there haven't been that many Flux frameworks since Redux. I jokingly caught the Flux framework to end Flux frameworks. I really think it's like it's the last one of this family that I can foresee existing. The next library that replaces whatever is going to be something substantially different I think. Because I really do think that Redux is what we were searching for, for that year and a half with all the upstarts and the different failed libraries and all that.

Do you think we'll see a convergence on the Redux?

I think there already has been. Dan, don't you think so?

Yeah, I suppose. I mean of course it doesn't do things like Relay does but that wasn't the point. But for what it can do, what most Flux libraries can do. Yeah, I think there has been some convergence. I'm actually super surprised [inaudible] because I didn't expect that to happen. I only did this library for my talk and it was going like crazy.

Yeah. So, if anyone who's learning Flux today, if you want to learn Flux, don't read about the dispatcher. Don't look at those diagrams with all the 50 boxes on it. Just go read the Redux docs because that explains to you what's actually important about Flux and what is actually valuable about it without confusing you with a bunch of concepts, which either are irrelevant now like the dispatcher or just a distraction.

So, this actually closely relates to a question I had. I read an article or a blog post somebody wrote about Flux. And they talked through the lessons that they learned. They said as they first learned Flux, a couple of big questions immediately came up at them as they started trying to write a real production app. They were things… two examples I can think about at the top of my head was, can stores make AJAX calls and can dispatchers access state. I'm pretty sure I got the questions right.

It would be even if [inaudible]. Does Redux eliminate some of this ambiguity that exists in Flux?

Yes, it does. It's interesting because Redux limits you in a way because it removes the dispatcher and prevents you from making manual. It just totally prevents you from making manual updates to the store because you don't really have access to the store. You express everything in terms of these reducer functions which if you don't know what that is - it's the function that takes a previous value or it takes an accumulated value and a new value. It returns a new accumulated value. If you do array.reduce then you know what the reducing function is.

So, because it proposes those kinds of limits on you, it's impossible to do an AJAX call from a store. You just can't. There's no way to it in Redux. You have to do it and there is no dispatcher so you can't access data from the dispatcher. You have to do it in an action creator or into something that is dispatching an action. That's the really beautiful thing about Redux is that it removes these kind of questions in your head. It was like, "Oh, I can't do that." And it guides you toward a solution that will probably lead to better success.

So, are you guys aware besides just the democratic process of anyone who's trying to close what I would call a documentation gap on Flux because right now we have lots of competing libraries. I mean, you yourselves just said, if you use Flux, just ignore these parts of the documentation. You'll be great.

Is anybody working on this problem and say you know what? We need like not necessarily like a grand unified Flux but something so that people can jump into Flux and actually do it right and have success without having to like trim parts the documentation or just know people who know the right things.

That's why we made the Redux, right? It has the documentation like lot of it.

Yeah, it has excellent documentation.

I really tried to when I was working on the docs for Redux, I really tried to not just describe the API because the API is small. I wanted to dive into some specific questions that pop up in your head as you try to implement the Flux application. So if you go to Redux docs, you have a pretty good idea of what to do and what not to do.

Yeah. And another thing I'll say is that when I said earlier that just ignore these parts at the docs, I don't mean that because just don't worry about it; it all takes care of itself. It's more that Redux is shown that like a lot of these concepts that we're throwing around at the beginning about the dispatcher and all this other crazy stuff, it's not necessary. When you use Redux, it's not that you're just ignoring the dispatcher. There literally is no dispatcher.

So, if you go through and I know we might be a little myopic here but I really do think that if you read through the Redux docs, there's tons of really cool example projects around it, too. You'll get a full view of Flux even if you don't necessarily learn about the dispatcher because we've learned at this point that you don't really need the dispatcher. It's not necessary. We can talk about why but that's a relic. We don't need that anymore.

Yeah. And I wanted to add because I always have to put the disclaimer is that Redux architecture is really similar except for some parts to Elm architecture. This is the tricky part because when I was initially working on Redux, I think I've read Elm architecture document. But I didn't fully understand it because with the Elm syntax and the first version of Redux was not quite like Elm architecture.

But later actually Andrew Clark wrote this explaining how I don't need the dispatcher and that I can do reducer composition to the full. Now Redux architecture is a lot similar to Elm. So, if you’re interested in how to make really cool abstractions for this really reusable parts then you should read elm architecture document even if you don't understand Elm because that's just a huge learning experience.

So, I'd like to get your thought s on Elm.

I actually haven't used it. I mean, I've meant to use it for so many times. I even installed it but I was always distracted by some, usually it’s a poor request and I never got around to actually fooling around with it. But I really like the architecture and the libraries for it. For example, the Redux undo library which lets you implement easily undo/redo for your Redux reducers was inspired by Elm undo/redo library. So, there's a lot of cool software. Even if you don't plan to use it, you should check it out.

Yeah. I'm on the same boat. I think Elm is super cool. I haven't actually used it though, hard to find a, I need to find like a side project or something because I can’t exactly use it at work. I think it's really exciting. I've never really used a fully functional language like closure or something like that for any significant project. I've only just dabbled on it.

Most of my functional program experience or if you can call it that has honestly just been like writing Redux code or writing pseudo functional code in JavaScript. But Elm is basically exactly like in the area of the type of language I want to use if I got to choose today.

Yeah. I think there is a point in JavaScript where you start to feel weird about writing too functional code and you back off. So, Redux is like Elm architecture until the point where it gets weird in JavaScript.

You can't do everything that Elm can do in JavaScript alone because you just don't have types. You don't have these guarantees that Elm has that make the experience go to the next level. There's a limit to what you can do functional programming wise in just JavaScript. But I think Redux gets a lot of that stuff. It gets you really close now actually 100% getting you there.

So, we touched on this issue a little bit of making patterns explicit in frameworks where the ideas of Flux were out there and people are talking about them. Everyone had a different approach to how they did it in practice. I was watching this talk that Tom Dale did at TXJS. He was talking about Ember obviously. But one of the things that he mentioned was that Ember tries really hard to make things really clear to developers where this is how you do a certain thing. And they believe that developers are more productive when they're not figuring out how to do these basic underlying architectural things. They just want to build stuff.

So, if you have to invent your own framework for managing data, that's time you're not spending working on features or refactoring code, writing tests or whatever. It seems like the approach in the React land is the opposite where it's like let 1,000 flowers bloom. Do you think that's a weakness of the React community or is it just a trade-off?

It's just too early. I mean React, the change, how we interact with the DOM. So, obviously all the things like interactions with data are going to change, too. We haven't completely figured it out yet. So, it's normal. It's just age thing. I come back in five years and I'll be…

I think that's part of it. I think another part of it is if you want to, there are two ways to accomplish. I haven't seen that talk by the way by Tom Dale, but it's definitely true that React and Ember…

It's a really good talk. Just check it out.

I'll definitely check it out. It's definitely true the Ember and React are at the opposite ends of the spectrum in terms of telling developers how to accomplish things. But I think if your goal is making things straightforward and simple for the developer, there are two ways to do that. One is to have a bunch of conventions and frameworks and libraries and API calls for how to do very specific things. That might be an exaggeration. I'm not saying that's exactly what Ember does. So, just solving it by adding more API and more conventions.

The other way to do it is just to make your API really, really simple and straightforward. Finding the right abstractions to problems and letting people build on top of that. So, there's a really cool talk and I know Dan's in favor of this talk, too that Sebastian Markbage gave. I think it was like…

Minimal API Surface.

Yeah. It's called Minimal API Surface Area. I think that's the title of that. I can't remember what conference [inaudible]. Where he talks about how the React team has really taken an opposite approach where they try and get rid of APIs. They're trying to simplify APIs and get rid of the ones that aren't working and trying to find the most ideal, smallest API surface area possible. One example of this is they haven't gotten rid of Reacts.create class but they're deemphasizing it more recently.

They haven't gotten rid of Mixins but they're pushing higher order Components which is really just a function that returns your Components. So it's not really a new API. They're pushing that as a pattern instead of Mixins. They're making it simpler as they get toward 1.0 rather than adding more and more crafts. It makes some thing, yes. It doesn't mean that maybe sometimes you have to do a little bit more extra work yourself. But it also allows the right abstractions to emerge in the community. It makes it easier for people to innovate on top of a really solid core with projects like React Router or Redux or what have you.

Yeah. I just want to add and this is a common sentiment that React forces you to action on JavaScript. I'm not saying that as a bad thing towards Ember or Angular because that's not what I mean. But I think React actually forced me to properly learn JavaScript because I don't have these million convenient APIs. I can call like [inaudible] but I have to actually structure my application and think about it. But once I get past this stage, I feel much more powerful. So, it's like React teaches you how to fish instead of you knew the fish. Does that make sense?

Now, you just made me hungry. [Laughter]

This is more for people who I guess are like first trying to get started with React and Flux. Everyone talks about React and Flux being more functional and it is more functional but you can still use ES6 classes in it. So, we talked about this a little bit but for people getting started, would you advise they try to stick to as much functional concepts as possible or start with classes?

I would. I would tell people to not to use classes but I might be wrong. We have some new team members on my team right now. I don't know if you know this but in the next version of React, there's a really [inaudible] now. You can actually just use the stateless, I'm sure you guys talked about this in the last podcast, but you can use just pure function stateless Components which don't even have classes. It's just a function that maps some props to React elements.

In the code I've been writing, in the code I've been pushing, some of my teammates to write, I write, I start and I write, try and write everything with these pure function Components. And if I

need to use that state or if I need to use a life cycle method for instance because that's another [inaudible] you want to use a class, I try and extract that into a higher order component. Then wrap my pure function with it. This goes back to this idea of separating between dumb Components and smart Components. Dan wrote a really good article about that.

It's a concept in React where you try and put your stateful stuff and a lot of your logic inside of these instead of your smart Components. Then those Components just render these DOM Components which really just are about… they are your leaf nodes. They're just rendering straight to the DOM. So yeah, I tried my best to avoid ever using set state or classes or life cycle hooks. And the cases where I do need to use them, I try and write some sort of abstraction around it and use higher Components. Dan, what about you?

Yeah. If I can clarify this little bit, I would say that I do use classes but only for React Components when I need the life cycle methods and stuff like that. You can't really get around it right now. There are proposals for classless module style Components but these are just proposals. You can find them in React feature wrapper. You should Google it. It's really cool.

There is also [inaudible] that we’ll never see the [inaudible] but it's really interesting to read about. But if you're talking about like should I use classes in my regular JavaScript code, I would say no. I haven't written it for ages and I feel just fine and I feel better than if I was using classes.

So yeah, classes often request a feature in JavaScript. Okay, we have it but I don't really think it buys me much in terms of application logic because my models are plain objects. My transformations of models are pure functions. So, the only use for classes I have is for React Components that less cycle models. I don't think it's evil to use class in this case because you do not actually create in them or doing something to them. It's just a way to express a component that has life cycle hooks.

So, I don't think it's a problem to use class in this case. I don't really understand why people go to like extra links to avoid using classes. In this case, I think it's fine. Just don't inherit, don't use inheritance. Don't create class hierarchies. That's the biggest problem is caused.

Yeah. And one more thing I'll say is that I don't use classes in my normal JavaScript either anymore. But I think when you're using react, one of the weird, more awkward things about it is you got this functionally inspired library but then you've got this object-oriented state API with set state and you've got this littered everywhere. Sometimes it does feel like a little bit of an amalgam of two separate… it feels like this weird marriage between two conflicting ideas. I think part of that, if you listened to the React authors and maintainers is just them compromising and realizing that in the interest of friendliness to the wider JavaScript community, they've made a few compromises and given a more friendly object-oriented API in some cases to everybody.

But I think going forward in the future, you're going to see those, you probably see this awkward object-oriented APIs shed and will get to a more functional feature. The biggest example of that so far is Mixins are now not favorite anymore in favor of using composition and high order Components. And I think that if you look at that React feature repo, we're only going to go more and more in that direction.

Yeah. I think in many ways…Sorry, I interrupted you. I just want to say in many ways it's like React is like a joint force for functional programming in JavaScript.

Yes, exactly. That's interesting because I know that when we were… when VDex was kind of young, we had a lot of discussions on GitHub and elsewhere talking about how far do we go with this functional concept? Are we going to scare everybody off if we use reducers instead of stores?

At one point, what we now call a reducer is we we’re calling stores is just for friendliness for people who used other Flux libraries.

And eventually, I think for the most part we realized hey you know, we're just going to call it. We're going to use whatever API feels most natural to us. People will pick up if we document it well and explain it well. It's a good API. That's worked out really well for Redux. And I think as React moves in that same functional direction, people are going to pick up on it fast and it's going to make them better programmers. It's made me a better programmer. That's what I've thought about this stuff with Redux.

Aimee, what were you saying?

Oh, I was just going to say like I agree. I have not done very much with React but that's what I do in the frontend with Angular. I just, I don't know. I think I was excited to see classes in JavaScript but the more that I've dealt with them in ES6, the more they're really not that great.

It is better than if you're going to like manually copy things over to like an object prototype and do all that type of stuff. So, it is better than something but it's not better in my opinion. They just go in full, just using functions and using per function whenever possible.

Yeah, I agree.

At least they're classy. [Laughter]

Somebody had to go there, right? [Laughter]

So, the future of Flux. No, wait. Where Flux falls short. Let's talk about that. In what ways do you guys think Flux is weak?

Ah, okay. So, I wrote a few things down. I think Flux is… I've written several Flux apps now. I've written two apps or one and a half, I guess because we're still in the middle of another one; written two apps in Redux. I wrote that really terrible, horrible initial, that first app I wrote with like this normal, trying to make my own Flux library solution. So, I've made a bunch of Flux apps and what I found even with Redux is that it's really good at synchronous stuff. But anything stuff can still get pretty messy unless you go full reactive and you start using something like RxJS just because I

think stuff is just inherently more complex.

Data fetching with Flux, which is what a lot of people use it for is good. It's good. It's way better than Redux than it ever was than Flummox or in any other library I used. But it's still very imperative and complex. I'm at the point now where when I'm working on a map, most of my time debugging or trying to figure out a problem with my code is not spent in React itself.

I'm at the point now where React does basically exactly what I want it to. I rarely am confused by React itself. It's always something with data fetching or caching or pagination or something like that. So, even with the really good Flux app, data fetching is still pretty complex and there are other solutions out there. Maybe there are here yet to exist that I think can do data fetching and async stuff in general in a much better way.

The other point which Dan brought up earlier was that the one downside to moving some of your state into these [inaudible] Flux stores is that now your state isn't. If you're putting component state inside of a Flux store, now you got your state in like two separate places. Maybe you've got three different files like an action creator's file and a store file and a component file. It just makes it a lot harder to follow what's going on. I noticed that we went overboard in this current project we're doing with moving stuff into reducers and into Redux where sometimes you just… Sometimes yes, that state is a little gross but it is a lot more convenient when you're just trying to get a feature to work than having to make like three separate files.

So, that's what I believe Sebastian Markbage was talking about on Twitter. Part of it is just exposing a failure of React right now, maybe not a failure of React. That's really harsh. Maybe a shortcoming of React right now where the state model or the state architecture could be a little bit better.

If I can add my complaint about the original Flux is that it's so hard to reduce this tool logic across different sources. So for example, if you have pagination and you have [inaudible] that all want to paginate but in response to different actions and they have some optimistic updates that are unique to each store, it's really hard to reuse that logic. I have a project called Flux React Hot Loader example and it has pagination there. I think nobody really understands what's happening there and I don’t understand either.

So, this is something that I wanted to solve in Redux and I think it actually provides a good solution in terms of you have these reducers in which you just function. That means that you can create functions that create functions. And there was an example in Redux called Real World example that shows how you can create reducer factories or if you're using the word factory, how we can create a reducer factory that implements pagination and then if you use it in different places of your reducer tree.

So, some things that were harder to reuse in Flux, they can actually be libraries in Redux. Another example is undo/redo which is there is a library called Redux undo which works with any Redux application. You just plug it in and you have undo/redo for free.

So, this is something that was bugging me. The original Flux but I think Redux solves it. But I agree that async is brittle. It's hard to do which is why Redux actually doesn't have any async solution. You are supposed to do it yourself.

And I think if you have complex async APIs, complex async dependencies, you should use something like RX or I've seen James [inaudible] use in channels. You just use whatever abstraction that makes sense for you and you feed it into Redux. This is why Redux does the concept of middleware which is your customs [inaudible] that runs between dispatching an action and the time where the action comes into reducer.

Yeah. That’s another really nice thing about Redux and it's highly expansible just because everything is a pure function. So it's really easy to compose functions and to create function and return other functions as Dan said. And the evidence for that being an effective approach is in just how many, there's just so many Redux third party are usually in Redux extensions out there. It's really cool.

But I wanted to add that of course another really big problem with Flux and Redux is lack of declarative data fetching which is exactly what Relay resolve. So, anytime you move a component that depends on some data across the component trees somewhere else, you actually change all these places where you call action creators to actual location of data. This was the biggest issue from Flux I think because it was just so frustrating to change that all the time and to avoid under fetching and over fetching. But it depends on your app because if you make something as complex as Facebook, yes definitely, you need declarative data fetching.

But if your app is relatively simple or if you don't rely on servers much and most of your mutations are local like a complex post editor or whatever then probably Redux is not such a bad idea.

And actually at OpenGov right now, we're working on a new app. We’re only like two and a half sprints into it. We started full Redux but now we're… it's like a mediumish-sized app. I don't mean the website medium. I just mean the size medium.

No, no. Thanks for the clarification.

I noticed that immediately. Yeah. So, it's a moderately, how about that? It's a moderately sized app…

Not to be confused with moderately.com [Laughter]

But go ahead.

Right. Okay. So, it's an app that's a little bit bigger than small. We already have like tons of action creators, reducers. Redux has worked out really well so far. But we've been experimenting with using something like Relay or maybe Falcor for doing just the data fetching part. So, I've been working on that, this sprint. And right now we're like this hybrid Redux and Relay state. It's actually working really well. Relay is really good at data fetching. There are few areas of our app where we're doing some complex local stuff that you can't really use Relay for, at least for right now. Redux is really working very well there.

I mean the nice thing about React is it's really easy to mix and match these types of approaches for different parts of the application because everything is nice and organized into these components. So I'm really excited about the potential for Relay but we haven't abandoned Redux by any means.

I really wonder what a legacy React code is going to look in five years. Like are we going to look at the [inaudible] roads and think like, "Oh, my God! That was horrible.

I look at what I wrote yesterday and I think, "Oh, my God, that’s [inaudible].

I mean, think of your backbone code today, right? Backbone code now is probably an awesome code.

Yeah.

We hope. We can only hope that our code today five years from now looks terrible to us.

Yeah. That'd be a horrible future if we're still writing the exact same code as we're writing today.

We’ve figured it out. So, do you guys see a future where people can use Relay type semantics on the frontend without having a Relay backend? And by semantics, I don't mean necessarily the query language but just like the ability to easily pass data into your components without having to go through a bunch of set-ups.

Oh, yeah. I totally think the types. I know that the Relay team is actively working on that. I went to a meet-up thing at Facebook a few weeks ago and I was asking them about this exact question. I asked them how is… well, actually the question I asked them first was how has Relay changed the way that you write Flux because I just assumed that they still write a bunch of Flux. They still do. It seems like but they're moving toward, they're trying to move towards a future in which they can describe all of their data updates and dependencies, whether it's local or on the server as GraphQL queries in terms of Relay. So, whether it's Relay or something very similar to it, I definitely think there's a lot of potential for declaring your data dependencies…

And mutations.

and mutations using something like GraphQL versus having to, even with Redux, you're still imperatively giving the steps of what needs to happen in order for this thing to update and how to know about it. So, yes was my answer, I guess.

Good.

Dan, do you have any experience with Falcor because I feel we should talk about Falcor as well.

But I don't know quite as much about it as I do with Relay.

No. The problem is that right now, I'm not working on any application. So, I really have been out of touch for everything. But you wouldn't use Falcor if you are writing a library.

Right.

So, because I'm writing just libraries right now, I have no idea what's happening. I haven't checked out Relay yet. I haven't checked out Falcor. I'm just the most clueless man in the world.

Well, we're all grateful for your cluelessness because we use those libraries.

Would it be fair to call you a librarian?

I think that substack, was this James Halliday? Isn't that part of his Twitter handle? Someone has a Twitter handle like that?

Oh, yeah, maybe.

A Twitter description.

I think one shouldn't spend too much time doing that because it really pushed you out of touch with the world. You just sit in your library cave and do your own thing. Everybody's moving on to something more modern. So, I think you should write an application. Solve some specific business needs and then realize, "Okay I'm doing it for money to write the library." Write a library. Make your own copy and then jump back into developing applications you have.

You wish you could jump back and then all of that users coming to you, "Fix this. Change that."

Yeah.

That's what DHH says, right? He says that good frameworks come out of used cases not out of people just sitting in caves thinking about them.

Yeah, exactly. And I think this is why it's really important that you limit your scope. This is something I tried to do with Redux. I think this is the one place where actions succeeded in that. I really wanted to finish Redux like I really wanted it to be done at some point. I think we are pretty much close to that. The only thing that I find lacking right now is lack of support for Flow. Is that a jargon? But after we get that, I think it's pretty much done. That's important because if it's never done then you will be out of touch at some point.

Yeah. I would consider Redux essentially done. Plus of course it would be cool. But honestly, if you write a Redux, the thing I think is really cool about Redux is it's done today for the most part. The docs are huge part of that. Honestly, I think the docs might be more valuable than the actual code itself because the code itself is like… what was it like, 50 lines Dan? Something like that?

Yeah. I removed the comments and so I need to check. So, it was 99 lines.

What?

Yeah. So, the code itself is, I encourage everybody to go and read through it because it's incredibly simple. It probably seems like it must be many lines just because of the number of stars it has on GitHub. But yeah, Redux in its current form basically existed like four months ago for the most part. You could use the 1.0 version of Redux or even slightly before that was some of our like alphas and betas and stuff. It's basically the exact same library minus a few like developer conveniences and stuff like that. Almost all the work that Dan does on Redux and other people do on Redux nowadays is responding to issues, updating docs, creating new examples. It's an incredibly minimal library. It has to have broken some sort of record for ratio of lines to code, to number of stars, to link that's existed. It's really quite phenomenal.

That is. Although I guess when the original Flux library had zero lines of codes so you know…

That's true. The dispatcher's larger than the entire [inaudible]. [Laughter]

That's why you didn’t put the dispatcher in there.

Yeah, yeah. We have…

I have a hundred-line budget, guys. I can't put a dispatcher in this thing.

Another thing is like in that 100 lines that James is talking about, it also includes stuff that isn't necessarily, I don't know, core of Redux. Like yeah, applied middleware is pretty fundamental to Redux but if you just look at just like the core API of Redux, it's probably something. I remember mocking it at one point in like a test or something for a library I was writing, it's more like 20 lines really. Really. It's really, really tiny.

Yeah, it's just marketing.

It's all marketing?

And the docs.

We really should have just read it out loud for this episode. I don't know why we bothered to talk.

Yeah. That might have been more valuable. [Laughing]

Dramatic reading even.

Open curly brace. [Laughing]

I think it's a little underrated. I mean, I'm not a fan of line contrast where you brag about how tiny your library is. But I think the minimal API surface area is what is important because it lets people build stuff on top of your stuff. And if you have a lot of stuff looping then it's going to rot at some point. People are going to have better solutions but they're not in your library.

So, what we try to do with Redux is what is the minimal API and minimal implementation we need to encourage people to build their own stuff on top of it and it'll still be powerful. For developer tools, hot reloading, this all should just work but need to be outside.

Yeah. If you look at the trajectory of Redux from its initial versions to now, it's really about removing things because there was a point when like hot reloading was kind of built in to Redux. Having multiple reducers that combine together was built in to Redux. There was a pseudo dispatcher thing with middleware that was built in to Redux. Redux-thunk which is now a third party or is now an external, a separate project. That was at one point built in to Redux.

There are other examples of stuff like that where we realized if we can design an API in such a way that we can move this stuff outside of the core of the Redux project, if we can implement these core extensions outside of the core then it means that anybody will have the ability to write these really cool things. So, it's taught me a lot about good API design. It's, I think a really good example of in the wild of Sebastian Markbage has talked about reducing API surface area and it's made me a better programmer, and when I write libraries, a better API designer.

Sorry, I just want to give huge claps to Andrew because he actually came up with the middleware design we have. So, this is his creation.

It was a group effort. It was a lot of back and forth. And the other big one was you don't talk about as much in the docs as the store enhancer pattern which we use for the dev tool. That was really cool and it's one of those instances where the API might not exist the way it does if the dev tools weren't the thing that Dan was actively working on. So, that's another…

Yeah. I plan to write an article about that because that's really interesting pattern that people overlook because most people just go look into dev tools. They are too mysterious. But this pattern is really interesting. I need to write about that.

I want to push back a little bit. You've been talking for a long time about the amazing…

Yeah. Sorry.

benefits of keeping the core so small and all I hear over and over again is look at how many decisions you have to make now to use it. Like it's a two-edged sword, right? It enabled you to keep the core small and to build a really clean, powerful API. But instead of using a framework, now I have to use a library and grab all these little pieces together. Those are things I have to know about. I have to know how they work together and I have to configure them myself. I don't think it's as clean-cut of an unadulterated good as you make it out to be like. There is a cost to it. It's not just like, "Look how smart a code is. We're amazing." Someone has to write the other code that's not there.

Yeah. That's an excellent point. Dan and I are probably biased a bit because we are so intimately familiar with Redux. We want to be able to extend it and I want to be able to do whatever crazy thing that I want to do with it. We're biased because we know exactly how it works, right? And not everybody is going to have the time to read the, I mean yeah, it's only 100 lines but not everyone's going to have the time to learn all these things about it. There is a cost to having all these different modules. You got an MPM install 15 things just to get a basic example working. And then…

That's not fair. I mean …

I know. I know. I agree. I agree with Dan. I'm still on your side but yeah, there is a cost. We can't pretend that it doesn't exist. But look, like you could make a Redux wrapper or some project that bundles up like common middleware into a single middleware and bundles up some common extensions. It'd be really easy to make something like that. And if that were valuable, honestly I think it would probably exist already. But if you think that's a good idea then yeah, come out with the Redux framework that has the built-in promise middleware and thumb middleware and logger middleware and all that type of stuff. It'd be totally really easily possible to build that stuff on top of Redux.

The difference is we're not building it directly into Redux. If we build the stuff directly into Redux then the power users or anybody else is going to have to figure out ways to work around it. It's much easier to put stuff on top of a small core than have to rip out stuff from a really bloated, complicated core. So yeah, there is a trade-off. But I think the approach that we're taking or that we have taken with Redux is generally better because if those things need to exist on top of it then people will put things on top of it.

Sure. Makes sense.

I think it's similar to webpack and Browserify debate where people are like, "I want to customize everything or I want a single tool that works." And it's kind of funny because I'm on the webpack side. I actually like that I have a kitchen sink that does everything for me. I guess this is because I don't want to customize webpack but I do want to customize Redux. So, this is where I'm coming from. I think a lot of Redux users become proper users really fast because the API is small. They want to build stuff on top of it. But with something like Browserify, it's more complex and so likely you want to write your own plugin for that. So, this is why I don't want to learn how to compose it with something else.

And go look at the source for Redux-thunk. It's like eight lines and it's a very useful extension.

Are there any points that we should have touched on that we didn't?

Let me just go over this document. I feel like we touched a lot. Yeah, there's some like other historical stuff that isn't here that isn't all that important. I've put in here because I thought it was a little interesting. Like the relationship between Flux and series side rendering perhaps or how everything used to be singletons but they're not. The idea of where the concept of replaying actions and recording actions came from but I think we basically covered everything

All right. Well, let's go ahead and get to picks then. Before we get to picks, I want to take some time to thank our silver sponsors.

Jamieson, do you want to start us off with picks?

I do. I have, let's see. How many picks do I have? I'll just do two picks today. Actually, I'll do three. My first pick is the Strange Loop Videos. They have been posted online. Strange Loop is a magical place where the cutting edge of academic and industry come together. It really feels like the future. Not everything at Strange Loop will become popular or widely-used but something is there that's going to take over. So, I would encourage you to check out those videos. There's a really good talk on Elm that came out. There are a couple other ones about some distributed system stuff.

My next pick is this website called Types in the Future or Typeset in the Future. It looks at the typography of classic sci-fi movies. So, there's a really good one on 2001Space Odyssey. They just look at the fonts and how they are used to enhance the story. I'm not one of those like font-nerds, some people really geek out on like the difference between Arial and Helvetica. I can't tell the difference. But it was cool to see how much craft went into these little details that I only notice on the periphery kind of. It's really well-written.

And then, my last one is this slide deck from a talk about how you can model building software internally for your company after an open-source project. Yeah, those are my picks.

All right. Dave, do you have some picks for us?

You betcha. I have two picks. The first one is a video from a YouTuber whose name is Vsauce. He recently put out a video about a concept called the Zipf's Law. It’s hard to pronounce because it's spelled Z-I-P-F, Zipf, I guess. The Law says that in any written body of text, you can order the words by frequency and take the most frequently used word, put it at the front. The secondly most frequently used word will be used half as much as that. And the third most frequently used word will be used one third as much as the most. And fourth, one fourth. And fifth, one fifth and so on, all the way down, even down to like the tens of thousands. We tried. That was really cool. Anyway, he's got a really entertaining style. Cool video. I'll post it in the show notes.

My second pick is a talk from the recently concluded UtahJS Conference which is an annual conference held here in Utah by the organizers of the UtahJS meet-up. It was the final talk by a guy named Will Conant who talked about how he and his company are using Flux. It's a really good real-world questions and answers. He shared how his team evolved using Flux from start to finish and how they resolved questions or answers to questions that they had at the beginning. And I really enjoyed it. So, it should be posted online on the UtahJS website here within a week or two. So, look for that. Will Conant at UtahJS.

So, those are my picks.

All right. Joe, what are your picks?

My first pick is a series of books that I've been reading and I've actually picked them before. For some reason, I just got the urge to go back and reread them again because they are so amazing. The first book is called Forging Zero and it's a sci-fi series. So, there are three of them and there's supposed to be a fourth coming out at some point. They're like some of the most amazing books I've ever read. So, absolutely love them. And I highly recommend them if you're looking for some books to read.

My second pick is going to be a board game that I've been really enjoying for a long time, Camel Up which is a game where you bet on a camel race. It plays, the base game plays eight people. They just came out with an expansion that plays 10 people. It still plays pretty quick and it's really fun. It’s just one of those games that's like a classic. It's fairly easy to learn. Everybody has fun with it, the plays. And crazy things happen. So, it's a fantastic board game.

And for my final pick, I'm going to the language Elm because I've been really digging up lately.

All right. Aimee, what are your picks?

Okay. I have two. So, my first one, I think this is an older talk but some mentor I've been working with recently told me to watch it. I thought it was pretty good but it's Gary Bernhardt and it’s called Functional Core, Imperative Shell. We've been talking a lot about React but most of my day is node and Angular. So I've been kind of trying to think of ways that I could write my code in this way in Angular. I don't know. I think it's older but worth to watch. So, that's my first pick.

And then the second pick, I often pick this off and on but it's the Nodevember Conference in November in National Tennessee. So I think they're pretty close to selling out tickets and they're still looking for sponsors. So, go buy a ticket and if you're interested in sponsoring, you can get the information for that on the website. There are a lot of really cool speakers speaking. I'm going and I'm speaking but National's awesome. So, if nothing else, go to National. That's it for me.

All right. I've got a couple of picks. I have gotten complaints about picking the same thing on multiple shows in the same week. But this is what I've been doing today. So, we cut the cable to save some money. Anyway, when we were trying to figure some of the things out, my wife realized that not all of the TV shows that she wants to watch are on Netflix or Amazon…

Are you about to pick Piracy Joe? All right, Chuck, I'm ready. I'm ready for you to pick just straight up pirating stuff. [Laughter]

Are you going to go after me for it?

No, no. I just want to grab some popcorn.

So, we went down to Lowe's and we bought an antenna

Lame.

How disappointed are you?

You're the lamest pirate ever.

Is it a pirate antenna?

Yeah, if that makes you feel better.

Does it say aaarrrr?

I feel better.

I'll go hang the Jolly Roger from it after the show. Anyway, we bought one of the antennas. They looked kind of like piece of plastic, kind of a little thicker than a piece of paper, about the same size. We just weren't getting any channels at our house. What we got, four channels and two of them were in Spanish and one of them was something weird. I don't remember what it was. So there was only like one channel that was even moderately interesting. Anyway, I had to look for quite a while and finally found, if you're in the U.S. and you're looking for what TV channels you can get over the air with an antenna, go to TVFool.com and look it up.

Everybody tells you to go to antennaweb.org I think and the problem with them is that they only listed the channels that I was getting. TV Fool said the channels that I could see that were, it color codes them. So green and yellow means that you can get them with the kind of antenna that I bought. You can get it at Wal-Mart or on Amazon. And then it had like 15 channels which were all the channels that incidentally my wife wanted. There were about 15 channels that were in red. Those are the ones that you have to have the big directional antenna. It's the kind of antenna you're thinking of that sits on your roof. And so we went out and we put that up there.

We had cancelled Dish network so we just took the coax off of the dish and hooked it up to the antenna and it worked great. Then we got a little signal amplifier or signal booster and we bought both of those at Lowe's. The whole package costs about a hundred bucks but that's way cheaper than even a month's worth of our cable package before. Anyway, all that to say TVFool.com is my pick. And I'll also pick the antenna that we got just because if you're looking. But most areas, I think in most urban areas, you can actually just get one of those smaller antennas and you're fine.

Then, another pick, I've been using fiction to kind of unwind and so I'm going to pick a book series. The latest book just came out in the Michael Vey Book Series by Richard Paul Evans. So yeah, I'm going to pick those because they're young adult books. I have to put this caveat on there if you're looking for like some sophisticated fiction. This ain’t it. But it's kind of fun fiction. Like I said it's young adult so the plotline stayed pretty clean and pretty direct. So anyway, I've enjoyed them and the fifth book is Michael Vey and the Storm of Lightning or something like that. I'll put a link to that in the show notes as well.

Dan, do you have some picks for us?

Yeah, sure. I have five picks actually.

Oh, wow!

So, my first pick is going to be a Tumblr blog BusinessTown which is described as an ongoing project attempting to explain our highly intangible, deeply disruptive, data-driven, venture-baked, gluten-free economic meritocracy to the uninitiated. So, it's really good. You should check it out.

My second pick is a series of articles about Elon Musk companies. It's on waitbutwhy.com blog. It's really a good blog and I really like how this guy, he approaches his article like with deep detail. So, he wrote a series of articles about Elon Musk companies, about SpaceX and Tesla. He goes into like what is energy? What are force of fields and why are they running out? How is that related to dinosaurs and anything and when will we go to Mars. I found it when I was sick and I think I spent the whole day in bed just reading each of them because the second article is actually split into five parts itself. So, it's very good reading. I suggest you go ahead and read it when you get time.

My third pick is called Mostly Adequate Guide and it's a really good introduction to Functional Programming. So, if any of you are interested in functional programming in JavaScript but can't really get into it, you should check out Mostly Adequate Guide. It's really nicely written and it's very accessible to JavaScript developers.

My fourth pick is a Wikipedia article called Abiogenesis which is about the origin of life, about different hypotheses for the origin of life and the common ancestor [inaudible]. It’s very interesting.

And finally, my final pick is react future repo which is a collection of possible ideas for what React could look like in a few years. So, it's not all actionable. Most of it is probably aren’t going to happen but take a look to get inspired. This is it.

All right. Andrew, what are your picks?

Okay. So, I have four picks. The first is a book that I actually read, 2012 when it came out, but it's a non-fiction book. I've picked it up a few times since just because it left an impact on me on a spiritual way. That sounded like little hippie dippie but it stayed with me. It's a book on moral psychology by a guy named Jonathan Haidt, I believe is how you pronounce his name. It's H-A-I-DT. And it's called a Righteous Mind, neglecting to remember this. It's the second part of it. But it’s something like The Righteous Mind: Why Good People are Divided by Politics and Religion. I believe that's what it is.

And it's a very interesting book about moral psychology and this theory about how our morals, where our morals come form called Moral Foundations Theory. It's a really interesting blend of kind of science and psychology but also just being aware of how we make our decisions. The core takeaway that I took from it, there are a lot of take-aways, but the core take away I got from it was that we tend to vastly overestimate the degree to which our decisions every day are based on rational or are rationally decided. Most of what we consider reason or rationality is a lot of post talk justification for our initial intuition or initial moral response to something.

So, it's really interesting. It might sound a little weird. It definitely challenged some of my assumptions for how reasonable of a person I am. But it's very fascinating to me and something I always come back to whenever I encounter a heeded political argument or a heeded religious argument or any kind of Twitter flame war, Apple versus Google type of thing. It applies to a lot of things. So, I really liked it and yeah, you should pick it up.

Another one of my picks is lodash-fp. It's basically just lodash but it has a wrapper around it so that you can, it switches the lodash API so that the data comes last and it's auto-carried. So if you like lodash but you also like to do some functional programming type stuff, it works really well with composing high order Components for instance. I've used it in several areas. Actually one way I've used it is if you've ever written a GraphQL schema which I've started to do and you have a lot of repetitive resolve functions. If you don't know GraphQL, I'm sorry but you have a resolve function that tells you how to go from the parent node to the field node. A lot of times, it's just a simple access or you go from like user=parent. user or yieldsparent .user. So, the really easy way to do that is just use the get method or the get function from lodash-fp. Anyways, it’s cool, neat little library. I'm a lodash fan and I also like functional programming so I've been using that lately and it's pretty lately.

Another one of my picks that I'm probably three years late on this and everybody else has already seen it but I just recently watched Inside Amy Schumer which is a really funny sketch show. There are about a billion sketch shows nowadays but I really liked this one. She's really, really funny. I think they just won an Emmy for writing or something like that and they won a Peabody or something earlier this year. Really funny sketch show. I really appreciated that it was a sketch show from a more female perspective because I personally don't think you see that very often or enough of that nowadays. So yeah, Amy Schumer, she's really hilarious. If you liked the Trainwreck which actually I haven't seen, you might like Inside Amy Schumer.

Another pick is dataloader which is a cool library from Facebook which they released like two weeks ago or something like that, really simple library. Basically what it does is it allows you to batch. It does batching of I think network requests or database requests, any kind of data loading operation. It does batching and caching of those requests in a really simple, intuitive way. It's particularly ideal for constructing a GraphQL query or GraphQL schema which is how I've been using it. I'm sure there are other use cases for it. But it works really, really well for doing a GraphQL schema because a lot of times what you have in a GrappQL schema is you have a field that resolves to another field and that just resolves back to the same fields. So that kind of a circular graph dependency and you don't want that to cause two separate fetches. So if you use that dataloader it's really easy, simple way to insure that if you do the same fetch twice, they'll get batched and you only end up with one fetch.

And then my last pick is OpenGov which is where I work. I'm not sure if I'm allowed to plug where I work but we're hiring right now for all skill levels. If you really like JavaScript and React and Relay and Redux and Node, I think you'll really like working here. I started her in May. I've just had a really great time. We're in Redwood City and we're about three years old. We have some apps for servicing local and municipal and state governments. They're cool apps. I have to do a financial accounting, multi-fund accounting. They may sound like some boring stuff but I'm really excited by it. We were servicing an industry that historically has not been really part of the whole tech revolution. So yeah, if you have any JavaScript experience, we're particularly looking for senior guys but junior guys or gals are totally welcome to shoot me a tweet on Twitter or an email or just check out our website.

All right. If people want to follow what you're working on or find you guys, where do they do that?

So, I'm on Twitter and on GitHub @acdlite. Yeah, it's a terrible screen name but it's acdL-I-T-E. I’m probably going to switch it soon. I just can't think of anything to switch it to. Unfortunately with a name like Andrew Clark there aren't very many straightforward options. But yeah, you can find me both on Twitter and Github at that handle.

I'm on Twitter as dan_abramov with underscore so it's like dan_abramov, A-B-R-A-M-O-V. You can follow me there. I have an unpronounceable nickname on GitHub so don't bother. Go to my Twitter account and you can click there.

All right. Well, thank you, fellows and thanks to our panel. We'll wrap up the show and we will catch everyone next week.