02:25 - Dan Abramov Introduction

02:43 - Dan’s Background and Journey Into Building Stuff with React 

05:48 - redux and React    

10:07- The Elm Programming Language

12:19 - Reducers

14:04 - Hot Reloading 

17:50 - “React makes you a better JavaScript developer.”

22:10 - Time Travel

28:26 - Storing Data and Managing State

34:43 - [Patreon] Support Dan Abramov Creating Redux and React Hot Loader

36:24 - react-transform

41:34 - Using redux outside React

43:52 - Editors and Programmer Productivity

45:35 - Future Plans
On YouTube
179 JSJ redux and React with Dan Abramov

Picks

The OAuth2 RFC (Aimee)
Michael Ries: Hiring Apprentices (Jamison)
@sebmck: "Sometimes having email history isn't always a good thing..." (Jamison)
Metal Gear Solid 5: The Phantom Pain (Jamison)
Firefly (Joe)
The Elm Programming Language (Joe)
Google Keep (Dave)
15 Minute Podcast Listener chat with Charles Wood (Chuck)
Pebble Time (Chuck)
100 Days of Burpees (Chuck)
Broad City (Dan)
Jamie xx: In Colour (Dan)
Cycle.js (Dan)

Special Guest: Dan Abramov .

 

Hey everybody and welcome to the JavaScript Jabber Show. This week on our panel we have Dave Smith.

Hello.

Jamison Dance.

Hello.

Aimee Knight.

Hello.

I'm Charles Max Wood from DevChat.TV. This week, we have a special guest and that's Dan Abramov.

Hi. This is me.

Do you want to introduce yourself?

Yeah, sure. My name is Dan. I've been doing React stuff recently and you might have seen my talk at ReactEurope called Hot Reloading with Time Travel. I mostly work on developer tools for React and its ecosystem.

I have so many questions because I think the stuff you do is as interesting as the path you took to doing it. Can you talk to us about how you got into programming and your journey to building stuff with React?

Yeah. I think it was when I was about 12 years old and where I lived, we didn't have computers in every home at the time, so I got it really late, I think. We had a computer class at school where we had assignments like creating PowerPoint presentations, stuff like that. When I got a computer, my favorite software was Microsoft PowerPoint because I really liked how I could create animation steps. You can say that this thing goes from this corner of the screen to the center then something else happens, then something else happens. So it felt really fun to me for some reason.

One day, by accident I discovered Macros. There was a record button, a play button and I could record my actions and then press play and they would repeat. I could actually press edit and see some lines of nonsensical English words. If I change the numbers inside, different things would happen.

So this got me hooked and I asked my grandma who was very supportive too. Every weekend she would take me to a bookshop where I would pick the thickest book on Visual Basic because that was a Visual Basic for Applications and I would learn about Visual Basic. So that's how I started and I just went from there.

I'm so glad you were able to recover. [Chuckles]

Yes. I mean honestly, I know people love to bash on Java, sorry not JavaScript, Visual Basic.

That too.

[Laughs] Yeah, but I may have not started programming if it was not for Visual Basic because it gave me immediate connection to what I was doing. Because I could just drag and drop some buttons and I have this window which I see in development mode. It's the same thing that runs in production mode. So I interacted with it directly and I really like that.

I tried several times to start from Pascal or C but I never could do it because I didn't have this kind of connection. So yeah, that was a big thing for me. I'm grateful to Visual Basic.

So this is kind of tangential question. Do you think there are tools that are like that, that are just so easy for beginner or easier for beginners to get into, that also scale up more that you'd be fine building your career on? Or is it these tools that make it easy to get into programming then once you're more experienced, you switch to something else?

I haven't really seen a tool, a visual tool like this that scales. But I don't think it's because they are inherently unscalable, I think it's just the right tools haven't come up yet.

Sure.

So why don't you tell us, Dan about what you've been doing with Redux. What kind of tools you've been building for the React ecosystem?

Yeah. I actually didn't intend to write Redux. It was just a by-product of me working on my talk. I really wanted to go to Paris when ReactEurope was announced and I knew that there was a call for proposals where I needed to describe what I was supposed to talk about. People would choose like, "Hey, okay. Yeah, this guy is [inaudible]. Let's get him here."

So I needed to come up with something. I knew if I just, at least that's what I feared. I thought that if I proposed something like Hot Reloading, people would be like, "Yeah, we've seen that already all right," because it was on React Conf. There was Ambidex which users React Hot Loader internally. I thought that I'd be showing the same thing. It’s kind of boring. So I felt I needed to add something to it.

I decided to write Hot Reloading with Time Travel because Time Travel is something that interested me a lot. Then I was working a lot on the application where it was very stateful. I would spend a lot of time tweaking Flux stores and they're not hot reloadable. So it was a big issue for me productivity-wise. I just thought, “Okay, maybe I can try that.” Even if they approved my talk, I'll come up with some way of actually implementing it.

So I proposed it and the talk was accepted. I was in panic mode. [Chuckles] How do I actually, what do I do now? So I slacked off for a while. I just procrastinated. Then I was doing a different library. I was working on React DnD. I decided to postpone this ReactEurope stuff. But then it was June already. I had just one month and I had to do something.

So I've been thinking about it in background. I decided to create a small Flux-like framework on my talk. I like a proof of concept. The main idea is that like in Flux you have actions, you have these objects. Instead of me changing the data, you describe mutations as objects like in Flux. Every mutation, for example if you press like button, it's an object with a type pressed and user ID, some ID and so on.

So if you replay these mutations in the same order, you're going to end up with the same state. The difference from Flux is that in Flux you have many stores which are objects or classes depending on the implementation which will listen to these actions and modify their internal state according to them.

But my problem with Flux was that because the sta te is inside these stores then if I change the store logic, I can't really hot reload it because if I replace one instance of store with a new instance, a revalidated instance with a new code, it's going to wipe out the state. So all I did was turn Flux tools into functions and later I realized it's exactly the same thing as Elm architecture. So if you're interested, you can go check out Elm architecture. It describes the same ideas.

One thing I was afraid of is that I won't be able to finish it in time so I decided to open-source it before the talk and maybe somebody would help me out. It turned out that people really enjoy the API which is really small and solid. I received a lot of help from everyone and especially Andrew Clark of Flummox. But really the only reason I built it is to have this time travelling debugger with hot reloading of logic that I demo to the talk.

That is the best example I've ever heard of talk-driven development. [Laughter]

Yeah, it is a talk-driven development exactly.

That's great.

And what better year than 2015 to invent time travel, huh?

I mean whenever you invent time travel, hasn't it just always been invented?

That's true.

So had you played with or heard of ELM beforehand or did you just realize the parallels afterwards?

Yeah. There's been this, I'm feeling guilty about it because I had this Twitter exchange with Evan. Evan was a bit uncomfortable with me not mentioning Elm as much as he thought I should. I felt that yeah, he's probably right because I read about Elm a few times before actually creating Redux. I'm not sure if… when you get inspired by something but don't fully understand it and later you kind of reproduce it but you don't really get this connection and you only get it later. So I think that's kind of what happened because I distinctly remember reading about ELM architecture but I was thrown out by the syntax, so I didn't fully understand what's going on there. Later after some initial iterations of Redux, Andrew Clark actually showed me how it's similar to Elm if we changed some things. We did change them.

Yes, I have not actually played with Elm yet. I've seen other people playing with it. I've seen some demos but I have not actually played with it myself. I really want to but I'm stuck in maintaining and GitHub issues and I can't find the time. I don't know. Maybe I'm just afraid it's going to be so awesome that I'll just try the JavaScript development.

The line between inspiration and like just porting something is kind of tricky. But I mean, I think the JavaScript world is better off. There a lot of people that will never get into Elm just because of the syntax and the type system and stuff. I think it's valuable if you can expose them to the ideas about state list architecture like this. So it seems like a great thing overall.

Yeah, but just to clarify, Redux is still a long way from Elm in terms of we can't do a lot of things because we're in JavaScript land. So Elm is a lot more powerful. These concepts are a lot more clean in Elm and are more expressive. So what we're doing in Redux is just a pale imitation of Elm.

So in Redux, you're reducers are supposed to be stateless, right? Like they just take in data and return data?

Yeah, These are just functions. It's like you have React components that if they're simple enough, you can express them as pure functions. They take the data and return the React elements. And in Redux, it's similar because you have these other pure functions, the data and the action and return the next data. Just like React components are composed in a tree, you have this tree of functions and your whole application is expressed as one tree of functions.

It's exactly the same way in Redux where you have reducers calling each other and there is this tree of reducers. It's like React for data but not really because it's not like Relay. Relay is awesome. I really look forward to playing with it. Redux doesn't try to solve the problems that Relay solves. So I'm in this part where I have this immensely popular library but there are so much better things out there that, I don't know, I feel small but it's good. It's good.

I think you're being too humble. I didn't use any of the Flux-ish libraries until Redux because it felt like they were all… no one had quite got it right and Redux is the first one that seems like it's just super solid. Maybe solid is the wrong word but it fits my brain well. So I love it. It's great.

Thanks.

I actually had a question along those lines and wanted to kind of back up for a brief second. I have two questions. The first question, for people who may not be exactly familiar about Hot Reloading, I think there is some confusion between that like hot swapping. There's something confusing between that and just like reloading your browser. So if you can maybe clarify for people that aren't familiar with that.

And then my question which was more along with what we were just talking about was you retweeted something recently that you just said that React led to better code quality. So I feel like everybody knows React at this point but maybe talk about that a little bit more for people who haven't done a ton with it.

Yeah, sure.

Are you saying that Hot Reloading is not just hitting command R like really fast? [Laughter]

It's surprising that people think that just like live reload.

Yeah, yeah, it's confusing. I've seen this confusion. [Laughter[

Sweaty reloading. [Laughter]

I think they hear this and they're like, "Okay, so but then no, you don't understand." [Laughter]

Yeah. That's a really good question.

Yeah.

You don't understand what this actually is.

Yeah, that's true. I've seen it. I’ve talked to a guy who said that. I don't know if you know him, Sunil Pai. He works at eCommerce company in India and they are starting to use React a lot. Every time he tells somebody about Hot Reload and they're like, "Ah, yeah, hot reloading." And he says like, "Come over to my desktop. I'm going to show you." And they're like, "Oh."

They don't even understand what's going on. Yeah, it's different from a live reload which I think is live reload is a thing that is like a server and a client. The client can access server and wherever there is a change in code, it just like hits refresh button for you, so live reload is that.

But hot reloading is a different thing. It's when you're able to change the code and have it magically change in your running application. In some cases the specifics are different. Like if you use React, there's some trickery to proxy methods so React component methods start pointing at their new versions. But you don't really see this. This is all machinery hidden away from here by React Hot Loader.

So what you really see is that you make a change to your Render Method and it's just that the DOM doesn't go away. The state of the components doesn't go away. It just changes in your browser. The first time you try it, you become so addicted to this.

I tried to work with other libraries a little bit and I found myself, “Oh, I have to hit refresh.” Or even, “Oh, it reloaded, it messed up my scroll position, my state, my current input,” and so on. It's just so harder to iterate. So I think even if React Hot Loader itself is not very impressive piece of [inaudible] because it has a lot of hacks, it isn’t really pure like some ClojureScript tools for the same hot reloading.

But I think it elevated the expectations of people as to what web tooling, what development tooling, what is the baseline for development tooling, what do we agree must be included. So yeah, I think that was important in terms of what React Hot Loader accomplished. Did I answer your first question?

Yes, you did.

Okay. The second question was regarding me re-tweeting somebody who said that React really makes you a better JavaScript developer. Is that correct?

Yep, so it's a popular sentiment and so people, if they haven't done a lot with React, maybe you could talk a little bit more about that because I definitely think it's true too.

Yeah. I would say React definitely made me a better JavaScript developer. I'm not sure why. It's a mystery to me too. I haven't really thought about it. I think maybe it's because React has really little API surface, whereas in Angular for example and I don't mean to bash Angular but it's the same thing for Ember and many other frontend libraries. They have a lot of APIs.

If you look at Google trends at the popularity of React and Angular searches, it looks like Angular is 100 times more popular than React. But I think maybe one of the reasons people don't Google React so often is because it has very little API. Because once I was developing an Angular app and I had to Google APIs every day because they have many classes, methods, directives or whatever.

So what React forces you to do is to build your own abstractions and build your own tools with very little that React gives you. But it turns out that this is actually enough to create complex user interfaces. So I think it's just the focus that React provides you and it just forces you to think as a

trusted developer I guess.

It doesn't have any template syntax that is again is magic syntax you have to learn. Then it is compiled by some JavaScript functions into actual JavaScript functions. You have none of that. If you need to write for reach or iterate over something, you just use map. If you don't know how to use map, you have to Google it. You have to learn about JavaScript array methods. I think this is why React pushes you to be a better JavaScript developer because you have to actually learn about JavaScript APIs. So I hope that helps.

That's good.

Yeah. I've had the same experience and heard several people say that as well. I think that's the answer.

Maybe another reason it helps you become a JavaScript developer is because the unit of composition in React is the component so it makes it easier to break things apart into pieces. Where in Angular, if you're building a quick app, you can have one controller and throw everything on scope. And it's so convenient. It's just like so fast to get stuff done.

And in React it feels like, "Do you have to do that?" I feel like the framework encourages you to break things into smaller pieces which is maybe a little more annoying in small applications but I think maybe better overall. I mean if you build a huge Angular app, you don't just throw everything on scope in one controller.

I beg to differ.

Yeah, so that's not a criticism of Angular, just more like the default lay of building things. React encourages you to do good things, maybe.

Yeah, yeah. It also encourages you to use a build system and to have modules.

It does.

Actually, a lot of frameworks don't.

Although like a spoiler alert or to pop your bubble, I am proof that you can write crappy React code. [Laughter]

React will not save you from bad code.

Congratulations!

Thank you. I asked on Twitter if anyone had questions for you, Dan. The hardest hitting question was from Jordan Scales. He asked what product do you use for your hair? [Laughter]

I don't remember. I don't know. But it's got two… there is a drawing of two guys there. I think it's the same guy but with two faces, two different faces. One is like, more like lover mode and the other is like more fighter mode. I think it says that it's like thick and something else.

Okay.

Well, anyway it looks fancy. I like it.

I think that was a sneaky compliment about your hair.

[Laughing] Yeah, I'm like Craig Federighi.

Okay, so we talked about Hot Reloading. Did we talk about Time Travel like really in detail? Should we go into that some more?

Yeah, we can. What would you like to know like how it works?

I just want to know how I can go back into my childhood and fix all the mistakes that I did.

[Laughing] Sorry, can't help you here? [Laughter]

Well, what can you do for me then, in my code at least?

Well, sometimes people get confused about it a little bit because there are some flux libraries that have Time Travel but as far as I know it works differently. When people usually see Time Travel what they mean is the ability to select any previous state of your application to like jump there and to stay there. Once you've satisfied your curiosity, you can jump back somewhere or you can drag a slider and see how it changes over time.

But what Redux, it’s developer tools. It's opt-in feature. It is not enabled by default because it weighs memory and performance. It's only for development. So what Redux dev tools does is a little bit different because it doesn't just let you go back to the past states like snapshots of the past states but what actually happens is that it remembers not the states but the actions. It remembers what happened.

Remember I told you that every mutation in Redux app is caused by a plain object called action. So these actions, they can be serialized, deserialized. You can restore previous sessions. But what's important is that these are not just state snapshots. These are action snapshots. And what's the difference like what's the matter? So the difference is when you combine that with Hot Reloading, you can change the logic of your reducers, the functions that actually tell how state is influenced by the actions and recompute the states anytime you change the code.

So what happens is if I have a reducer that says anytime a to-do is added, it's added at the end of a JavaScript array. I have this piece of code, this function. With the Redux dev tools, I can go back. I can cancel actions like cross them out as if they never existed. By doing this, I effectively go back in time.  But what's really interesting is that I can change the code of the reducer and say, "Okay, I want this to do at the beginning and not at the end of the array." When I change the code, Redux dev tools is going to recalculate all the states based on the same actions. And now my to-dos are going to be in the opposite order. So that's the whole point. It does not just let you jump to states. It lets you actually interact with the whole history of everything that happened in the app.

This is useful when you have some scenario where there is a lot of actions going on. You want to make sure that whatever order you process them in, they're going to evaluate you something, to the correct state. Then you can go back, go forward. But it's not just about jumping. It's about interaction with what happened in your app.

It sounds really good and it looked really good in your ReactEurope talk. But I wonder in practice, how does it really work out when you have big apps with lots of actions and lots of reducers? Do things get too complicated to manage in your Redux dev tools?

Yeah, of course. I mean it's just me and a bunch of folks helping out. But of course what I'm showing is a proof of concept that this is possible. I know a lot of people are actually using that in development so it's better to ask them like is it working out for them? I know that there are a lot of issues you'd have in a real world app where it's just more complicated and it doesn't fit on the screen or it happens too fast. But my point was to show that this is solvable.

You can take some time off your job and make a pull request for a Redux developer tools to have filtering because they are just a React component. And bam! You have filtering. You have, I don't know, filtering of state or filtering of actions. There is an issue about an alternative user interface for them, a suggestion where instead of showing all actions at once, when you want to work on a particular part of the logic, you just select the actions you care about. They are going to be like a

GarageBand loop.

They're going to replay it anytime you change the code but the rest of the actions are going to be ignored just so you can focus on this piece. And if ajax requests that is unrelated to what you're working on comes up, it's going to be ignored because that's not your focus. But it's not implemented yet. But you can go ahead and try because everything is there for you to help me make it a better tool. I just don't have enough horsepower to get to create an amazing productionready developer tools. I could use some help with that. But I'm showing that it is possible. There is no obstacle except time here.

To me that was the main, almost the main takeaway from your talk is that it's actually really valuable to spend time making your tooling better. I can sometimes just get my head's kind of, I can just put my head down, get stuck in a rut where I'm just cranking so hard on the individual problems that I'm working on, that I don't step back and think is there a thing I could build that make any kind of problem similar to this easier? It seems like there are some classes of problems that are really well-solved by having the time travelling debugger. But it's more like the inspiration to build other tools similar to that that will solve any kinds of problems, too.

Yeah.

Dave, you talked about the time travelling debugger thing not scaling or maybe potentially having scaling problems in large apps. I know Circle CI. I have that blog post I did a while ago around some dev tools they built. They're using Om so it's not Redux. But it's kind of a similar approach where you have a centralized place for all your data in your app. They added a thing to just export the data and then paste it back in so they can easily debug weird states in their app.

If a QA person gets in a weird state they just hit a key command. It dumps the data out to the console. They can copy and paste it inside.

I think I saw that. That's like an instantaneous state snapshot, right?

Yeah, yeah. So maybe that's a good thing to talk about. One of the assumptions Redux makes is that there's a central place in your app for all the data. Can you explain that a little bit more and why you did that? And talk about kind of the advantages and disadvantages of it?

Yeah, sure. Redux is nothing new because it borrows extensively from Om and from Elm. I think it's not that similar to Om because it has the first class concept of reducers and actions and Om doesn't really care about that, almost more like more low level in this regard. It's more similar to Elm.

But anyway, the idea is that if you don't hold your state in a single place, you're going to end up with inconsistencies. This was the problem that Flux was also trying to solve. Like if you have a bunch of Backbone models that reference other Backbone models. And at some point you're going to have collections of Backbone models. You're going to have duplicates like when a reader responds from server and you have this graph of objects that they reference each other. But there is this movie object representing some movie. There is another movie object representing the same movie because it was de-serialized and they are not related to each other. So if you change one, the other is not going to update. You end up with an inconsistency.

It's just prevalent in Backbone apps because it's so hard to make sure that there is a single entity cache, that everything is when de-serialized resolved through it. I know SoundCloud tried to do this. But Flux model is much easier here that you have this route straight. In Flux, there is no concept of route straight but it's presumed that these stores have single tones. So you can think of them as straight tree because it's essentially the same thing.

You have several Flux stores and each has its own straight tree so how is this really different from having just one straight tree? For Redux takes this approach to extreme just like Elm and Om because there's no real advantage to having many stores when you can just have a single tree and subscribe to updates at different levels of the tree. Of course the advantages of this approach is that your state, first of all, if there is a single state tree, then your app is more deterministic because you can't really have one thing update without the other. Every update comes through the same central place. It's similar when you have React components that call such state everywhere. It negates the benefits of React. It's very hard to trace when there is a lot of setting state.  So it's better to have less components that are stateful.

This is the same idea that it's better to have one entry point for any state change because then you can log it. You can have this Time Travel tools. You can restore it or persist it. You don't have to do anything fancy to accomplish this because you have one method that changes the state.

If something is wrong, you're debugging procedure is super easy. Put in on sole log before and after the state change. You can see where exactly the problem occurred because with Backbone models, it was a mess.

If there is some straight ajax request that came back and change the model and you don't have a break point there because you don't know which model exactly was changed, so you don't have the single, centralized way of mutations. This is the only reason we have this single state tree in Redux for predictability. That's why it's called predictable state container. So I'm not sure I can think of many other benefits here. I think I fully transition to just thinking about a single state tree all the time so I kind of find it weird not to think about any other ways of managing the state.

It seems like when you first hear it, it just feels weird because it’s so different from how you often manage data.

You have one component tree, right? Now how is that different from – I mean, you could say that it’s better to have many views that call each other but exists separately. But I think we’ve all learned from React that it’s not. It’s better to have a tree that is governed by the clarity of nesting. So it’s the same idea here. You have a component tree and you have a state tree. You have two trees that sync with each other.

Yes, it’s like for most web apps, you’ll have one database or one point where you talk with all your backend data store stuff and it’s not that different conceptually either. People are fine with that, this giant global variable that holds all of your data. For some reason when you do it in the browser, it’s seems weird at first.

Yeah, it’s like a database exactly.

Yeah, I guess it would be like having 12 different servers. You have to talk to, to get different pieces of data, which obviously doesn’t make sense.

Yeah and you mentioned that they don’t have databases that they hold everything in global variables on the server.

Sounds like my code. [Laughter]

Database is a good idea. So database on the client is just a reflection of trying to get it more sophisticated and needing that kind of control and a log in.

I saw a while ago you launched a funding drive to help people fund your work on the Redux stuff. Is that your main employment right now? Are you employed by a company?

Yeah, that’s the only thing I do. I promised a lot of stuff and I have to actually do it. [Inaudible] Screencast, I know [inaudible] people hate me because they delivered the equipment to me. I’m actually speaking in their mic right now.

I’m supposed to make these Redux videos. I kind of got started. But I promised I will get started. It went really well. I don’t do any contract work right now. I don’t review anybody’s code. So yeah, it’s amazing. I didn’t expect it to actually happen so fast and so well. It was just a crazy idea at ReactEurope because I was thinking, “Oh no! I can’t go back to contracting right now because I have to finish this stuff.” So yeah, it’s temporary only. I intend to run this campaign for three months and it’s going to end in October, I suppose. But it’s been really helpful and helping me get in. I don’t know if you saw react-transform which is the replacement for React Hot Loader that I haven’t really talked about much yet.

No.

But it’s the new thing. It tries to address the flaws with React Hot Loader. I intend to write a medium article soon. But anyway, it wouldn’t be possible to release that without help from companies and individuals who sponsored Patreon. So thank you to everyone. I really appreciate that.

Can you talk a little bit more about the react-transform thing. Is that something you’re not ready to talk about?

No, sure. I am ready actually.

This is the first I’ve heard of it.

Oh okay. [Chuckles] So I don’t know. [Inaudible] bubble because lately anytime I released something, people retweet and favor it like crazy. I’m like maybe I don’t have to explain it. They seem to have gotten it. [Laughs] But then I realized no. It’s just a bubble. So what it is, is that a React Hot Loader is a webpack tried piece of [inaudible]. It’s a compiled time transformation for webpack. So what it does is it looks at you module exports and it wraps everything that looks like a React Class into its special transform. So the problem with React Hot Loader is that it’s impossible for it to find any classes that are not exported.

For example, classes inside functions or for example classes that are wrapped with high order components like you connect something to a Redux store and then the component inside the connect React Hot Loader doesn’t see it. So it can’t preserve its trait whether you change the code. So that was a big problem for me.

Also a lot of people are skeptic of webpack and I understand where they’re coming from. The last several React Hot Loader like projects for Browserify and other tools and what I wanted to make easy is they all have some portions of code that are similar but they can’t share it. So what I wanted is to turn React Hot Loader into infrastructure for such projects that does not depend on webpack. So what I came up with I split React Hot Loader in three or four different projects. I didn’t just do it because I love modularity, but it’s very practical.

So one of these projects is called and it’s the lowest level project, it’s called react-proxy. Reactproxy is just a library that lets your wrap a React component class and it lets you update it on the fly with new versions of it. But it exports a proxy class that acts as if nothing happened. So it’s like React Hot Loader’s proxy logic, the heart of React Hot Loader but that is not tied to any build tool. Of course you won’t use it directly but it’s logic. So if somebody’s writing a Browserify hot reloading tool, they can use react-proxy for that.

Another project is react-transform and it’s kind of an umbrella of projects. In fact, there is no project called react-transform. It’s just a placeholder right now. But there is babel plug-in for reacttransform and there are several transforms. The main idea is to have a shared API that can potentially be implemented with different build tools like webpack, babel, or Browserify, or some combination of them. The idea is that there is some way of extracting React components from your code.

For example, I have a babel plug-in that does it but you can potentially write the webpack loader that inspects module [inaudible] exactly like React Loader used to do and wrap component classes from there. But what is important is that it finds all React classes in your code base and it runs arbitrary functions on them. That can do something with them.

One example of doing something is and I call these things React Transforms so one of such transform is react-transform-catch-errors which wraps random method into a [inaudible] statement. Through an error, it’s going to return a special component saying hey you have an error on this line. Like in React Native, you have this red box of death. So that’s kind of similar thing. The idea is that you can apply today with my babel plug-in, babel-plugin-react-transform. You configure it to use react-transform-catch-errors. But you can write custom transforms to do something else. One such transform is react transformer webpack HMR, which stands for Hot Module Replacement which does exactly what React Loader used to do. So I ported it to be a transform for React Transform. Potentially you can write something like React Transform Browserify Hot Loader or something. That does it in a different way. It can use react-proxy or it can use something else. So the idea is to split the projects that I created so people can use just the software that they’re interested in and develop on top of them.

Super cool.

There seemed to me some interest in the community for creating some libraries to use Redux outside of React. Can you talk about that for a minute?

Yeah, sure. I’m not super familiar with that. I haven’t investigated any of them closely. But Redux is literally, it’s very small. Why I’m saying that is that it doesn’t make a lot of assumptions. It doesn’t include any React helpers inside of it. So React bindings are a separate project. There was this other project called ng-redux, which are Angular bindings for Redux. I haven’t worked with that but it has a similar API to React Redux. The idea is that Redux is just a state container. If you have a framework that can efficiently re-render its views based on a change in a state Tree, then you can use it with Redux and have all the ecosystem of Redux available to you. In fact, I’ve seen people using Redux dev tools inside an Ember application because Redux dev tools is a React component. But that’s an implementation that they do. I mean, who forbids you to monitor React components somewhere in Ember app?

What happens is that they use Redux with Ember but they have React power developer tools which is kind of fun. I enjoy this kind of mixing and collaboration between frameworks because one thing that really prevents us from moving into future is how we stick to our little silos like, “Hmm, they’re use Angular. I’m not going to look at their code.” Even if there are really great ideas that React doesn’t pick up, people don’t even notice them. It goes both ways. So I’m really happy that in the past year, I think, there has been a lot of collaboration between Angular, Ember, React, and other developers. It’s really cool to see that finally happening. So I’m not sure if I answered your question. I kind of got into a different thing.

Nope, you did. That was good. Okay, and then my final question – you are like the ultimate in programmer productivity. So everyone likes to fight about [inaudible]. I want to know what you use because I’m going to switch to it tonight.

I’m afraid I’m going to disappoint you in this because I’m afraid to check Atom because if it’s really fast enough now, I’ll have to migrate and I hate migrating to something. So right now, I’m still using the Sublime Text 3 although it is pretty stable for me. I don’t use any plugins on purpose because I’m going to be sad when I’ll have to abandon them and search for their counterparts in Atom world. So right now, I don’t know. I’m just waiting for my Sublime to break like refrigerator, when refrigerator breaks, you have to buy a new one. So that’s kind of what… [Laughter].

That’s it though. I’m still switching to Sublime.

It keeps the code cold.

If I switched editors every time my editor broke then I would [inaudible] long ago.

I really enjoy Spacegray UI theme for it with oceanic next color scheme for JavaScript and Babel JavaScript Sublime package because it just is a set up that is most friendly to ES6 code. Spacegray was actually created by a co-worker of mine. It’s crazy popular. It’s like 6000 stars. I’m still catching up with Redux. Redux is not yet as popular as his theme. So it’s really great. I love it.

I’ll miss it if I switch to Atom.

Do you have anything that you wished we would have asked you that we didn’t.

Maybe I don’t know. Future plans or something.

Yeah.

The problem is right now, I’m in the middle of something that I might join a company but it’s still in the process. So yeah, I’m not sure I’m ready to talk about it yet.

So you announced that there might be an announcement, just now.

Yeah, kind of. I’m going to move to another country. Again, if it works out well because I’m always panicky. Now there is such a word, right?

No, no, that’s a word.

Okay, I’m always panicky about paperwork and visas and all that kind of stuff. Once, I had to fill four forms which is not a lot, right. But in my mind, it felt like I had a nervous breakdown. So my wife had to call me and say like, “Hey, I’m going to show you what I went through.” I was showing these four forms and I realized, “Oh wait, I just filled four forms. It’s not a big deal. What am I whining about?”

[Laughter].

But it felt like I don’t know like a mountain of paperwork. Anyway, I’m trying to move to another country because it doesn’t feel very safe in Russia right now. I certainly like to live in a different place. So I might be moving in the coming few months and I might be joining a company.

That’s sad to hear. You’re so nice. I don’t want you guys to feel scared. [Laughs].

I’m sure Microsoft would love to have you. [Laughter]

Yeah, sure.

All right, let’s get to the picks.

Before we get to picks, I want to take some time to thank our silver sponsors.

Aimee, do you want to start with some picks?

One of my picks is not really anything… a library or anything like that. So I’ve been working this mentor and he’s really encouraged me to start digging into some natural RFCs. So as a newer programmer, this seems maybe a little bit scary at first but it turns out it’s actually been immensely helpful. It hasn’t been as bad at all as I thought it would be. That is my pick. If you’re newer and you haven’t dug into some of this like the OAuth1, maybe that’s not the best one to start with. But even that one hasn’t been so bad so far; or the http one. I’d highly recommend people go and actually look at this because it will really help you understand everything more. That’s it for me.

Alright. Jamison, what are your picks?

I have three picks. One is a blog post by my friend Michael Ries. He works at a company called MX. They just started an apprenticeship program. His blog post is about how they started it and kind of their goals for it. The parts that I really liked are when he talks about the struggle he had when he first started professionally programming. How there’s a gap from where you get your training, whether it’s a bootcamp or a school. You still don’t learn all the skills you need to actually build software full time professionally. He said he spent about a year struggling and getting stuck and then unsticking himself. Part of the goal for their apprenticeship program is how can they produce that time it takes to come up to speed. So his goal is to make it take three months instead of a year if they consciously provide mentorship and guidance for these apprentices. It’s a really cool idea. I’m jealous with it. I might steal it depending on company circumstances. But it’s a good read, if you’re new or if you’re looking to hire or if you just kind of want to think about improving education and software.

My second pick is a tweet by Sebastian. We had him on the show a few weeks ago to talk about Babel. He’s one of those young wizards that started programming when he’s like in diapers or something. So he has all these emails saved from when he was like 11. Just emailing people about how awesome he is at programming games and how smart he is as a little kid. It’s a pretty funny tweet. He’s like laughing at himself. It’s all good fun.

My last pick is, oh my gosh, Metal Gear Solid 5. I haven’t played Metal Gear Games very much before but this game is ridiculous. It’s a stealth action game, big buff soldier man sneaking around in the wilderness beating people up. But it has all these little twists that just make it weird and game-like. Like you have a home base and when you knock cards out, you can hide their bodies or you can attach this balloon to them. Then they get sucked up in the air and let out this loud like Wilhelm scream, they get picked up by a plane and taken back to your base. And you brainwash them to join your army. There’s all these like weird, goony things. It’s a really fun open world systems game. It has a lot of little touches then they get more fun like that. So those are my picks.

Joe, what are your picks?

Alright. So I have recently been watching, for me [inaudible] watching with my daughters who are teenagers, Firefly. I’ve been introducing them to the awesomeness that is Firefly. It’s been, I don’t know probably a couple of years since I’ve watched. I’ve watched Firefly many times but it’s been a couple of years. I'm just, yet again, amazed at what an amazing show Firefly was and how we, as a society, are less because it was cancelled early. [Laughter]

It’s not coming back.

I really can’t think of a tragedy greater in human history than the cancellation of Firefly. So I’m going to pick Firefly as my first pick.

Then as my second pick, I’m going to pick Elm because I’ve been doing a lot of Elm lately. It makes me happy to know and those are my picks.

I'm jealous.

Why?

Because I want to write Elm.

Just do it.

Yeah, yeah, yeah, more in my free time but yeah, I need more free time for that.

Just do it at work and then when anyone asks you why you’re not writing Angular, just tell them it’s Angular.

[Laughs] I’m sure that will go very well.

Elmgular.

[Laughs] Awesome.

Dave, what are your picks?

Well first of all, I just want to point out that if you look for Metal Gear Solid 5 YouTube videos, you can see balloons attached to cute, little dogs, horses, sheep.

What on earth is this?

That’s the beauty of the game. It’s just bonkers.

But it looks like a serious military fighting game but it’s got balloons and puppies.

Yup.

Okay, alright. I don’t really feel like I need to pick anything now. But I will give you one pick. This is a pick that probably many people are already using. It’s a little tool from Google called Google Keep. It’s basically to do MVC on steroids. It’s just a checklist app but it does have one nifty feature which is if you have a special person in your life who likes to give you lists of things to do that never end and share them with you, you can do that with Google Keep.

You can make checklists, share them with people. Then they can check them off and you can see them get checked off which is great. Maybe you used to do this on paper. Now you can do it on your phone. That’s all.

Alright.

Oh and you can hook balloons to it, I think. [Laughter]

So I’ve got a couple of picks. The first one is just a reminder that I have been reaching out to people who listened to the various podcasts that I’m involved with. You can get on my calendar and have a 15-minute chat with me. I felt a lot of people say, “Well I’m new to programming.” I want to talk to you anyway. Go to JavascriptJabber.com/15minutes. It will let you pick a time on my calendar and we’ll talk over Skype. I’ve been meeting just the awesomest people who listen to the shows. I want to talk to you. So go sign up.

The other thing that I’m going to pick, I backed a kickstarter campaign back in January for the Pebble Time watch. I got it yesterday. It’s one of those smart watches. I’ve seen a few people with the Apple watch. I don’t think it’s quite as nice as the Apple watch. It’s also not quite as expensive as the Apple watch. But it has been really fun to have something on my wrist that tells me when somebody’s trying to reach me on Skype.

I only have a few different types of notifications and if they get too annoying, I’ll turn them off too. But it’s really nice. I can also control my phone from my watch. So for me like the ultimate combination is to put Bluetooth headphones on and then on my watch, when I’m running and stuff, it’ll send me the notification to stop running and walk and then to start running again and stuff. It just vibrates on my wrist. If I need to control the music or anything else, then I could just do it from my watch. I don’t have to pull my phone out and look at it while I’m trying to jog. So anyway, I’m really digging that.

One other pick I have and this is something that Jonathan Stark on the Freelancer Show brought up because we were talking about things that you should be doing on a regular basis as a freelancer. We talked a bit about fitness. There is a Facebook group called 100 Burpees or 100 Days of Burpees. The idea is that on day one, you do one Burpee. On day two, you do two Burpees. On day 100, you do 100 Burpees. Anyway, so there is a Facebook group where you just post where you’re at. So if you’re interested in that then you can probably find it. I’ll find the link and put it in the show notes. You have to ask to join but it’s a public group. So I’m sure they’ll just let you in unless you’re being a jerk.

So anyway, those are my picks. Dan.

Wait a second. I have to add a pick. I found a Metal Gear Solid 5 video of where he uses his horse’s droppings to stop a jeep but it spins out and then he puts the whole jeep in a balloon. [Laughter]

Oh no! So you put all the guys go up in the balloon because they ran over this horse poop.

Oh man!

You’ve understood it. I can see. This is why I’m so in the game.

I’m so buying this game immediately.

Okay, I’m watching the video now

[Inaudible] show notes.

You just Google Metal Gear Solid Five horse poop jeep balloon. [Laughter]

It’s actually horse poop game play.

Oh man. I saw it. It just come up with that search on my own. [Laughter]

Now everybody’s wondering why I thought to Google.

That’s right

It’s the top result.

I’m sure it was. Alright Dan, what are your picks?

All right. So my first pick is a TV show that I’ve been rewatching lately. It’s called Broad City. It’s about two girls in New York who are opposite personalities. It’s really hard to describe what it is about because there is nothing really happening. But I’ve had tremendous amount of fun watching that show. I guess it’s comedy for millennials but I’m a millennial so yeah, that works for me. It’s really great.

My second pick is a new album by Jamie XX who is from the band called The XX. He released an album called In Colour with British spelling, as far as I remember. It’s a really nice album. I don’t know anything about rave culture. It’s inspired by rave culture, I think. But it’s just so good to program to. I just keep it on repeat all the time. So yeah, there is that.

My third pick is going to be a JavaScript framework which I was sure should have been… I looked for the picks on the website because I was sure somebody was going to bring it up but I didn’t see it there. So I’m picking Cycle.js by André Staltz. It’s a library that it uses virtual domain site. It’s a library that aims to find the fundamental abstractions for building UIs. So it’s trying to, I don’t know, find better abstractions than React. It is based on observables, on Rx. It is very functional. Even if you don’t plan to use something like that in the near future because it’s still immature, its ecosystem is immature, you just subscribe to it. It’s repository and read through its issues because the discussions happening there are really interesting and you can gather a lot of ideas just looking through them. So those are my picks.

Alright. Well thanks for coming, Dan.

Thanks for asking.

If people want to support your work, to check out what you’re doing, where do they go?

They go to patreon.com/reactdx, all without dashes or anything, just patreon.com/reactdx. Dx is developer experience. So that’s my patreon. You can still put some money there before it’s too late and it’s over.

Awesome!

Thanks Dan!