The Ruby Rogues

The Ruby Rogues podcast is a panel discussion about topics relating to programming, careers, community, and Ruby. We release a conversation with notable programmers and Rubyists each week to help programmers advance in their careers and skills.

Subscribe

Get episodes automatically

284

284 RR React on Rails with Justin Gordon and Rob Wise


00:55 – Why study React on Rails?

04:30 – Redux

07:40 – Using React on parts of an app and not the whole

11:05 – Jsx, Webpack, and Hot Module Reloading

16:05 – Integrating React with Ruby on Rails

19:55 –  Libraries

25:05 – Is React on Rails automatic?

28:30 – Server rendering

30:55 – Gaps between server rendering and page loading

34:00 – Decision trees: Angular or React

35:40 – Why choose React?

38:15 – Choosing a front-end framework

39:55 – Using React and Rails for production-level projects

43:00 – ShakaCode and Coaching

Picks:

The Autobiography of Benjamin Franklin by Benjamin Franklin (Jason)

The Lost Art of Finding Our Way by John Edward Huth (Jason)

Hacking: The Art of Exploitation by Jon Erikson (Jerome)

How to Build a Billion Dollar App by George Berkowski (Jerome)

Ghost in the Wires by Kevin Mitnick (Charles)

School breaks (Charles)

Boy Scouts of America (Charles)

Friends and Guests (Justin)

Play Bigger: How Pirates, Dreamers, and Innovators Create and Dominate Markets

(Justin)

Mast.ly (Justin)

The Paleo Blueprint by Mark Sisson (Justin)

Justin Gordon’s Twitter (Justin)

Dave Asprey’s podcast, Bulletproof Executive Radio (Justin)

The Tim Ferriss Show podcast (Justin)

Dr.Boolean’s Mostly Adequate Guide to Functional Programming (Rob)

Jafar Husain’s tutorials (Rob)

Tesseract – Of Matter (Rob)

This episode is sponsored by

comments powered by Disqus

TRANSCRIPT

Justin:       I’m out and now the team will help them out and don’t get to where they want to go but there are people that that sort of true motivation and love are pretty far and it needs training. When they do workout, we do hire them.

Charles:    Let’s go ahead and talk about this good taste that you’re discussing here. A lot of people that listen to this show would agree with you to the extent that Rails constitutes good taste or at least some Ruby framework, be it Sinatra, Roda, or something else. I’m just learning React right now. In fact, I’ve been watching Brian Holt from Netflix. He has a frontend master’s course that I’ve been watching. I definitely see some of the appeal but for Rails developers, why React? Why not Angular or Ember or something like that? Because Ember is structured a lot like Rails so it seems like it would be easier to pick up.

Justin:       Recently, in the last couple of days, I just published a blog article on where we stand with React on Rails when we take a look back, we’ve actually sailed past 2,000 stars. I’m pretty stoked on that. For people that are involved in Ruby open source, it’s actually no small feat. Would you say so Chuck?

Charles:    I don’t pay much attention to the stars so I don’t know. I’m assuming that it takes some doing to get to 2,000 stars.

Justin:       Anyway, I wrote an article and the history goes is that I needed to find a frontend framework. I’ve done the CoffeeScript of the jQuery stuff. I was given a task to build a dashboard where you got different knobs and dials and you can control a bunch of graphs and tables. It’s very obviously something that would be dynamic. It wouldn’t be any pages going back and forth to a Rails server. Where am I going to look at? Ember was my first choice. Looking at that, I was like this would take over the whole app. There’s already a Rails app there. It didn’t seem that really good of a choice.

The next thing I looked into was React and watched some videos on that. As soon as I’ve watched those videos on React, it just clicked. Then I go, “This is the right stuff.” It was almost like when I first started using Rails. I just started using Rails and wow, the stuff actually is built the way I want it to work. I did look at Angular for a little bit and mainly it’s just along the way of the Angular path then go, “Forget this one.”

Jerome:        Why did React click for you?

Justin:       It’s a really long time ago since I got into that. Now, it’s almost like it’s so obvious. You’re being asked questions like, “Why Rails?” There’s so many parts of it that are just absolutely clear. Why even do that? I’d say that probably the most important thing for me was just conceptually. How you actually go about and looking at React program. We talked about this, this is unidirectional data flow where we have a model of the data, you represent to say some JSON or Ruby hash, etc., and you have some code that will render it. The code that renders it, you break it up into components or it’s composed of other components and you know exactly the folder of the data and what is being drawn string. You’re not worrying about any asynchronous actions at all.

You don’t get this whole, “What’s happening in the DOM?” It’s like, “Okay, this event happened.” “This thing was updated in the DOM.” You just know here is the data, this is how it draws. And then you also know how to setup an event handler and then from that event handler, you’re going to run some code and you’re going to update the state in world. That’s pretty much it.

Jason: That’s why I said it, interested me. I’m coming from no familiarity with React at all. You said you don’t have to worry about async stuff or something like that. Can you explain that a little more? I’m curious about that part.

Justin: React for one thing, one of the huge advantage of it these days than was even a few years ago is a great ecosystem of libraries. Pretty much of newly settle something called Redux which manages your state. What happens is that you got this one concept which is Redux, which is a state that is there.

The only way the state can get modified is that you basically create a function that will modify the state and give you a new state. In this function, you typically set this up with Redux, is you’ll get some event has happened and you write some code and you modify the state. There’s ways that you can set this up so, when we’re designing a UI, you’ve got the issue that you’ve got both user inputs happening and you’ve got asynchronous calls you made out to a remote server. You want to make sure everything is all synced up and correct.

If you only had user input, that’s kind of easy to handle, it’s not big a deal. But as soon as you introduce having the asynchronous ajax type stuff coming in and you get a multiple ajax responses and you also have user input all of the same time, what the heck are you going to be doing? The way that we set stuff up with Redux and React is completely clear that when you get one of these events, it doesn’t matter if it was from the ajax request or it was from user input. You get some event and you modify some data in your Redux store. When the data is modified, React components are bound to the Redux store and it will redraw appropriately and then you know exactly where you’re going to be going into your React code into a render method. There’s actually some other life cycle events that will happen before the data is changed, after it’s changed, etc. You just know exactly what is happening in the code.

Rob:         For me, I’ve played around with Angular as well, specifically Angular 1.0. There’s a lot of setup that you have to do. There’s basically controllers but they’re on the frontend. You can also in your view code, you can then go make calls back. It’s like you can change it from here, you can change it from, there, it’s going both ways. I think it’s cool.

There are plain people who code on Angular and I’m not going to say one is objectively better than the other. For my personal preference, I like React a lot better. We also mentioned Ember. I haven’t done that much Ember but from my understanding it takes over your frontend. React is more opt in, it’s just the view only. Especially if you’re not talking about this thing Redux which is doing the model and controller part, if you will.

Jason:       Rob, what you said is an interesting point and it ties into something I was going to ask. Say that I’m sold on React and I’m like, “Okay, I want to try another application.” My familiarity with Angular and what I always tell people is you don’t pick Angular and Rails as your default stack for 100% of your projects because it doesn’t always make sense. It can add a bunch of overhead and complexity to your application that doesn’t really add any value for users. If you just have a super basic CRUD app, don’t put all of that stuff on it because you don’t really need it. But if you’re developing an application that’s more like an actual web application with deep functionality, then something like Angular could make a lot of sense.

The way that I’ve been structuring my applications is like a client server architecture where the JavaScript is totally separate from the API. If you do it that way, you’re really invested in the frontend framework that you’re using. Like you said, it takes over your app which is sometimes fine. But what you said about React is it’s kind of opt in. I’m getting the impression that if I choose to use React on a Rails app, I’m not going to be held hostage by the fact that I’m using it. I don’t have to use it everywhere. I can use it in the parts of my application where it makes sense to use it and then the other parts where it’s not going to add any value, I don’t have to. Is that the right idea?

Rob:         Yeah. Not only is it part of the application but parts of the page. For example, we’ve got an account page for our internal app and most of that stuff I don’t need the interactivity and like you said it’s overhead. Nothing is as simple as Rails. It’s just still going to be the fastest. But if you need that extra interactivity, let’s just say you’re trying to change your password and you want to make sure it needs certain validations and you want to send out the request and then wait for it to come back and that simple form render the thing, you want to hit those off before the client even submit, because it’s a better UX. I just need this password component, this change password component that has this interactivity.

I code that up in React and I put it inside of a bootstrap panel and then everything else on the page is still on Rails. Not only am I just doing it for that one part, I don’t need a whole single application. I don’t even need it for the whole page. I can just do parts of the page. What React does at the end of the day, it takes your higher-level language called JSX which allows you to write tags that are not HTML tags. You can name them whatever you want like change password component. And then you encapsulate all of the logic and interactivity logic that you want inside this change password component. You just render that change password component inside the bootstrap panel in your normal Rails erb view. And then there it goes.

If you’re using Gem like React on Rails, it takes over and it converts basically that React component at the end of the day under the hood. It all translates back to regular HTML tags, divs and inputs and stuff like that with event handlers.

Jason:       You mentioned JSX and I was watching some of Justin’s videos earlier and I saw some of the JSX stuff. Where in the code base exactly does the JSX stuff go when you’re using your React Rails jam, where do you put the JSX stuff?

Rob: For React and Rails, this is one of the selling points. React on Rails, we’re assuming you’re using something called webpack, which is kind of like a build tool. It’s very popular on the frontend especially basically if you’re doing React you’re using webpack. It has become the norm frontend devs. This handles all sorts of build pass. Kind of like the way like Rails assets pipeline does. It worries about getting your styles compiled, it can uglify your code, it can change your code from the newest, latest, greatest JavaScript standards, ES6 and beyond back to ES5 for browsers that can’t support it, stuff like that.

You write your code inside of a client folder, and to a normal JavaScript frontend developer who knows nothing about Rails, they can be inside that client folder and it’s exactly what they’re used to. If you were to co translate to some Node only app that’s using React, it’s exactly what you’re used to, it’s the same thing. Then just at the end, when you output your final disc files, your compiled output, it goes into the Rails assets folder. The React on Rails jam picks it up and puts it into your views. If you want to think of it like that.

Jason:       Okay. Is that only in production that it goes into the assets or does that happen in dev too?

Rob: It depends on how you set it up. You could set it up in dev to do like that. On our internal project, we have an even more advanced setup which we run what’s called hot module reloading. This is really cool. It allows you to change. If I just change one module, it’ll switch that module out on the fly.

For example, I’ve got a mobile open and I’m trying to style some text inside the model, maybe you’ve heard of the live reload where we reload the whole page. This hot module reloading will actually just reload that style. I don’t even have to go back to the page and reload the page and open the model again. The models stay open and I can see it changing. That’s the kind of thing that’s possible with React on Rails.

The alternative would be like Facebook’s React Rails. They’re going in, they’re changing a lot of stuff for about how advance this pipeline works. React on Rails is very lightweight in that sense. We’re not really changing much about what Rails is doing. It allows you to stay in that framework that the frontend guys are really used to. You get to use all the latest and greatest tools.

Most important of which is in my opinion the Node Package Manager system although there’s Yarn but you can use Yarn now too which is the Facebook. It’s like Ruby Jams basically but with Node Packages. You can use that. You can manage your dependencies with that instead of having manually copy down zip files, zip folders of whatever libraries you want to use.

Jason:       Few things, I want to just take a few steps back. First of all Rob, you mentioned stuff that we’re doing in our own app. We’ve got a lot of those techniques on the React-webpack Rails Tutorial. That’s the midlevel example of seeing how the stuff works, it’s got the hot module reloading, it’s a playground that we use to demonstrate what React on Rails is like in the real system. The very most basic thing of React on Rails is just run the generator. I just published a couple of videos on doing that. I think some of you guys on the panel watch those.

Charles:        Yeah they were really good.

Jason:           Yeah. That gets you the basic setup. One of the things I really want to emphasize is that React on Rails, I believe what makes it so amazing is that you can just plug it into literally any Rails app right now that’s running say jQuery in a whole bunch of other stuff like that. You can choose it just for one page. I’ve got React on Rails, I can setup my React component there, and the way it works is for the registration system. Your Rails page is asking all the name of the component and you can literally pass some data from your controller, and then you’ve got React inside your apps. Totally different than using say Ember system like that.

I think that drone system probably are setting up Angular as a whole single page app, that’s quite a bit more works at this app. You can literally run the generator and get React on Rails running in really app pretty much within minutes.

Charles:        I really want to hit this because Rob mentioned webpack. I’m sure that there are a few people in there going, “Webpack? Webpack’s not part of Rails.” You mentioned that you can pull stuff in with the NPM and you get all this awesome stuff; tools, you get libraries, you can get all of this stuff, but why not just go with the asset pipeline? I know you’ve explained this in your videos and stuff but I’m hoping you could just hit this for a minute because I think it’s important.

Rob: Yeah. Let me give you a little history. It’s really important because everybody listening to this podcast needs to know there’s two main ways to integrate React with Ruby on Rails app. One is the repo ReactJS/React-Rails, it’s part of the original ReactJS, it’s part of ReactJS so it’s sort of official. They came out with this two years before we came out with ours. That heavily integrates with the asset pipeline, what that means is that you’ve got to use the asset pipeline for getting your JavaScript in there in your libraries and all the stuff. You’re depending on someone taking JavaScript and actually putting it into the whole Ruby on Rails while handling JavaScript, which I tried to do that at first, I got setup. The first tutorial I wrote on these on my React on Rails blog was how you use React Rails Jam, cool, got these things set up, very nice.

Next thing I want to do is I want to add React bootstrap library, I always publish on NPM. Where’s the Ruby Jam? There is no Ruby Jam. What am I going to do? Then I start going down the rabbit hole, there is absolutely no way I’m copying and pasting all these files into my Rails project. I’ve been doing that for a long time. Imagine having to copy and paste all your Ruby files in your Rails project and you didn’t have Ruby Jams. That’s what it’s like not use NPM. It made no sense at all.

Next thing I got recommended by some Facebook people, “Hey check out webpack, start going down that.” That was a long time back. Couple of years ago I wrote an article on how to set this all up. The setup was a bit of work. You had to copy this, copy that, etc. If you go back and look in the history of the React webpack Rails tutorial, that’s where it was at first was a template for how to set this up.

We got to this issue was, how would if you want to do server rendering, the React Rails Jam can do that. Up with the React Rails Jam as go through the asset pipeline, I don’t want to do that. I finally hit the bullet and took a look at how React Rails is doing it. I leveraged the techniques that they had in there and we put it into the React on Rails Jam and the rest is history. A year later, we got many, many production apps running on it and quite a vibrant community.

Charles:        I’ve also got into the issue copying and pasting like you said, where essentially I pull in jQuery and jQuery UI and something else. It turns out that one of the jQuery plugins I pulled in just isn’t compatible with the version of jQuery that I pulled in or jQuery UI so I’ve got to go back and figure out all that dependency crap. The nice thing about using NPM is the same thing that’s nice about using Bundler. I just tell it, “Okay, I’ve got these dependencies,” and then it’ll figure most of that stuff out for me.

Justin:           It’s really insane how long most Rails developers, including myself, have gone not using NPM for JavaScript libraries. Because it’s really just crazy to manually handle all that stuff.

Rob: Yeah. There’s so much great stuff out there in terms of these libraries out there. To try to manually keep those up to date, it’s also the thing about the JavaScript community. I did Rails first. Coming from Rails and then going to the JavaScript community, the turn over and the rate of churn with these libraries is unbelievable. They’re just changing so fast. We also like to make them very modular. That’s kind of the trend right now. In order to get something working, you got to download four different packages because they all work together and they want them to be able to be switched out if you want to do something weird. To try to keep those up to date would be just a devops nightmare. You have to do it everyday for 20 minutes.

Justin:           Chuck, there’s a couple other really big reasons. The most obvious one is using NPM for all your JavaScript code. The next thing is the tooling. The really key difference is that  React on Rails, you’re in JavaScript Lan when you’re in the /client folder of the top level of your project. It’s sort of like Rails that you go to a React on Rails project, you know where everything is. Everything that’s JavaScript base is under /client, reset the webpack configurations and we have server for directory structure, and even in the React community. People come to a few different arrangements for how to organize the files. The really huge thing is as in now you get the libraries, but there’s a tooling. The number one piece of tooling that hit me early on was that now we don’t want to use NPM packages, I want to do ES6.

I got convinced early on of moving from copy script to ES6 when I was following what was going on with the discourse project and saw post by [0:21:50.5] that convinced the guys running discourse to switch over. I go, “You know what, makes sense,” so I switched over. That was one of the main reasons once the integration with what became as known as babble for doing that.

The next part is we use a feature in webpack called CSS modules, that allows us to put our CSS right next to our JavaScript files in these really small little chunks of CSS. It’s unbelievable how much more productive that is. It’s not like a basic setup but it’s something that you can look into React-webpack Rails tutorials to see how that’s done. There’s even other stuff that I’m not even going to mention that is more advanced webpack I’m saying, so we’re doing the optimized, the loading of the apps, there’s React router library that also works in with this which is like that’s essentially how stuff that’s happening in your URL, fetched your JavaScript app, and without request actually go into the server.

There’s so much more to this that by using the React on Rails Jam is that you realize that, “Okay, great, I’m going to be in JavaScript Lan. I’m going to do JavaScript stuff the way all the other JavaScript people do.” Really, there’s a very, very clear and small little bit of integration that connects you into the Rails app, you put this whole tag in the Rails page and oh my God, I can even server render my JavaScript code, it just works. Not only does it just work, you put a component there on the page, you can have five of these React components all talking to the same Redux store.

The amazing thing about that is we’re doing the headers of our app in React they can have interactive functionality like a counter for how many notifications you’ve got. We’re not doing the header with him or doing with React. The reason why is we have a header component in React and then we have a body component which is either going to be plain old Rails or it’s going to be a React component. They talk together through our shared Redux store. It just works right down the box with React on Rails. That lets you do the best to both worlds, mix and match or what technology is going to give you the most bang for the buck.

Charles:        I can still hear some people saying, “It feels like I’m managing two systems.” The React system and the Rail system. I can even just bundle installing, get the one for the other. Is the React on Rails pretty much automatic, you just putting your Gem file and it mostly just works, or there’s more to it than that?

Justin:           Probably Rob talked about that one.

Rob: We’re trying to keep the surface area, the API, and the number of things we’re manipulating down to a minimum which is I think the main benefit, like Justin was talking about. One of the things we are doing is we’re changing the assets precompile, rig tasks so that we’re ensuring that your webpack output files have been created so that you’re not trying to run the app without anything actually being compiled an output there.

Basically yes, it does add a step. You have to bundle install but you also have to install your Node packages. You’re also have to run webpack once and output those files. You need to make sure that you’re doing that.

We have helpers for doing that. For example, one of the things early on that I kept running into is I kept trying to run my JavaScript integration tests. Because I’m using copy bar with the JavaScript webdriver to test my Reacts components, which is really nice by the way. When I was doing that, I kept forgetting I’d make changes in the JavaScript code and then I’d run the test and it still fail and I couldn’t figure out what was happening. Every time, it was because I forgot to recompile the JavaScript again.

We actually made that kind of span the talk with Justin, we decided to make this asset test helper that ensures that you actually just looks at the update to the M time of all the files in the output and make sure they’re newer than the files that are in your client folder. If they’re not, that means you changed something, you forgot your output again. Your test when you’re running our spec or actually automatically recompile your webpack output.

We’ve included helpers to try and make it more idiot-proof so that you don’t forget. There is that extra step. You got to compile your webpack stuff out into the Rails assets folder before your app is ready to go.

Justin:           All that stuff is pretty much really easily explained, understood, there’s examples of that. We’re possible, we’ve added that’s a Rails code, that’s a JavaScript code to make it easy. That’s a philosophy of what React on Rails is, to take this idea of putting JavaScript in your /client directory and make it work seamlessly with Rails given our preferences for how you do this. It is definitely opinionated but our version of opinionated is work really well with the React and Redux communities. There’s just been thousands of man hours put into the polishing all these little things by getting on board our community, you’re able to leverage that.

Rob: By the way, the React Rails webpack tutorial that Justin mentioned, that has a live version that’s running on Heroku. If you’re worried about all how long going to make that work with my build tools is very simple.

Justin:           Just go to reactrails.com. That’s got links right to the repos and so much more.

Rob: Yeah. We’re demonstrating lots of techniques there too. I don’t know if you guys want to talk about server rendering or not but I think that’s one of the really cool things about using React with Rails stuff is that it’s not just a single page application that talks to some API. If you want them to be more of a unified thing, you can do that. We do that.

It’s what React and Rails does is you’re not just sending a bunch of JavaScript to the client browser, and then once the browser loads it, realizes you got to go ask back for all the data I’m supposed to need and show a spinner for 10 seconds while they’re loading the initial app. That doesn’t happen because you’ve got a code on Rails, you got the JavaScript code on the Rails, you can preload everything with the data it needs to get started and to be hydrated at first, which is the term I used to call hydrating. You actually send the already hydrated JavaScript code, just starts up immediately when you load the page, just like what if you’re using jQuery or something like that.

If you decide that you need the interactivity but you’d really like the search engine optimization because most web crawlers either don’t parse JavaScript or don’t parse it very well, I think Google’s the only one that have crawlers that parse JavaScript. If you still want the search engine optimization, you can turn on the special feature called server rendering which you use either like exact JS or you can have your own Node server.

Something evaluates the JavaScript code while it’s still on the server side and turns it into HTML. That’s what you send to the client. Everything’s already rendered in HTML by the time it gets to the client, and then the JavaScript picks up from there and listens for changes and interactions accordingly, but that kind of first render happens on the server. When a crawler from a search engine crawls and hits that site, they see all the normal HTML that it knows how to parse even though it can’t interact with the JavaScript, it doesn’t need to because that first render from the JavaScript has already been done for the system for it but on the server.

Jerome:         It’s important to note by the way, that’s a feature of React. I don’t know if Angular might support that, they might not, but it’s a feature of React that when you setup your React components, they can be server rendered and everything just works like magic.

Jason:           Yeah. Angular has something similar. I think it’s called Angular universal. The thing I always wonder about that is let’s say I have an application with a lot of JavaScript and it takes one second to load. We don’t want to make the user wait one second and so we render that server side rendered JavaScript so it loads immediately. What if in that one second period between the time that the server rendered stuff loads and the JavaScript stuff gets done downloading and all that, what if they invoke an event on the page or something like that in that gap, between the time when it loads and the JavaScript is actually ready? Hopefully, that question makes sense.  

Rob: I don’t even know if people are aware of this, I wasn’t aware of it first but there’s actually an onload event that gets hired for image tags. We were server rendering. The image tags was getting loaded on the page. If you had visited that page before that image was cached in your system, it happens instantly. We get the HTML with the image tag with the source in it so the browser immediately start power parsing the image tag. It will parse it and realize it had the cached version and load the image before React could initialize, we missed the onload event handler. That’s the only time I’ve ever run into that issue with server rendering. Otherwise, it usually just happens too fast. It is a concern but that’s the only time I’ve ever run into that problem.

Jason:           Got it. I always wondered is that an issue, how do you deal with it? It sounds like it happens fast enough but it’s not an issue in practice.

Rob: Yeah. It’s the same. Under the hood, it’s still the same thing. They’re using JavaScript to put event handlers on stuff. It’s just a nicer language for doing it. It’s just a much more organized way to do it. At the end of the day when you compile these output stuff, it’s all just normal JavaScript, it’s not JSX anymore. That was like a precompiled dozen languages that was pre-JavaScript. And then it gets converted into normal JavaScript. It’s just HTML with normal quick handlers and no change handlers, and stuff like that. React that’s taking care of that for you.

You’d have the same problem if you try to initialize something with where jQuery is going in and adding an event handler with jQuery. What happens if you click on that before the jQuery is the time to initialize or something like that. It would be the same kind of thing as that.

Justin:           Just taking a step back Chuck for some of your audience here. I think you can almost put together a decision tree here that you reach the point in your app, you need something more than jQuery. The next thing is are you going to go with JSON’s method of Angular, or are you going to go with React. There’s issues, there’s questions there, or maybe it’s even Ember but maybe then you’re going to decide, “Okay, we’re going to go with React and how are we going to put it inside of Rails.” Then you get to pick, “Okay, I’m going to use React Rails and we’re going to use React on Rails.” That’s a different flows of where you can be going through this decision process.

Once you get to the point where, “Okay, I really like React, I like the community, I’m going to get on board ES6, I’m going to do all that stuff.” If you do get settled on React on Rails, we’ve got a Git book of documentation, we’ve got articles, we’ve got videos, and we’ve got a community, we got a Slack room too where we chat about it, if anybody wants an invite they can send me an email at justin@shakacodecom.

Jason:           One pretty serious consideration when you’re making a choice is if you go with React, you hurt my feelings, and if you go with Angular, you hurt Justin’s feelings. Keep that in mind.

Justin:           Yeah. I don’t think my feelings are going to get hurt too much but I might pity you. There’s a few other reasons actually why React, we touched on these. The very first one which none of us actually mentioned the words as a virtual DOM. The whole point of the virtual DOM is that this whole phase of rendering the code with some data is handled by React. You can make 10 different data updates, your store data, but your React is only going to draw the stuff once, it’s highly optimized to only change the parts of the DOM that need to be changed.

We touched on server rendering as the key benefit, the JSX files I really like, I like having the Java, I like having this HTML notation right inside of the JavaScript files, it’s worked really well for us.

There’s something that has come out the last year, that’s probably more than a year, it’s gotten really popular and that is React Native. When you’re investing time in learning React, you can very quickly get up to speed React Native and you have essentially superhuman powers now to build iOS and Android apps.

ShakaCode, my company is just about finishing up with big time consumer production rewrite of a website, mobile website, we converted it into a React Native app, we did it in about two and a half months. That will all be available, I’ll be sharing that with shakacode.com website once it comes out. It’s my first experience, heavy duty experience using React Native besides just playing with it a little bit. I got to say that I’m about as stunned using react Native as I was using React in terms of how good the system works and how much I’m able to leverage my experience in building web apps to building mobile apps.

Charles:        Yeah. I also want to just shout out that there’s a Devchat.tv podcast called React Native Radio that you should definitely be checking out if you’re looking at that angle of things. My understanding is that there’s a lot that you can leverage from your knowledge of React that gets you long ways toward writing mobiles app without needing to know a whole lot more in React Native.

Jason:           I do want to raise a question that Justin touched on a second ago which is like when you’re choosing a front end framework, how do you think about that? I guess I will ask like Justin and Rob both, how did you approach that, what made you choose React as opposed to anything else? Sometimes people ask me, they’re like, “Should I use React or Angular?” I’m like, “I don’t know, I just picked Angular kind of flipped the coin almost.” Kind of what you said Justin in one of your videos where I’m not going to go into what’s better than anything else. I’m assuming you’ve already made the choice to go with React and same with me, I’m teaching Angular people who have already made the choice but it is a question I get a lot that I don’t know how to answer so I’m curious how you guys think about that.

Justin:           If you visit my last article I put on medium.com with React on Rails, I think 2,000 stars. I listed two videos there from Pete Hunt’s conference talks that absolutely sealed the deal for me. There’s no way that I could do better than what how Pete explained it. One of the videos Pete does talk on a bit about just where the foundations of React and the other video he talks about comparing React to Angular and Ember. That’s all I can say. Watch those two videos, check out my articles, it’s got a link to those two videos. They’re entertaining, they’re quick, and regardless of whether or not you want to go and switch over to those, it’s well worth your time.

Jerome:         Random question for Justin. Because you got ShakaCode works in regards to like you guys work professionally in React on Rails so I wanted to know what are you guys seeing the adaption on the web when it comes to using React and Rails for projects? I’ve been able to extently go from actually looking for Angular and Rails sites, just stumbling upon Angular and Rails sites tags but I haven’t really seen that the Rails app, they feel like you don’t have that React so I just want to know have you guys seen a surge or uptake in Rails apps that have React as the frontend?

Justin:           How about product content Airbnb at the same stack that we have essentially?

Jerome:         Alright, that’s cool.

Justin:           I’m quite sure that Shopify has abandoned their old DOM, I think it was Batman and they’re moving into React. WordPress has switched over to React. Those are a few names you probably heard of.

Jerome:         I wasn’t really speaking in popularity, I was more speaking of growth on the web. Are you seeing more companies adopt React and Rails?

Justin:           I really don’t have any data on that, I don’t even know how we’d figured that out. I just know anecdotal stories, I know our community is growing and the amazing thing about open source, open source really is probably one of the most game changing things that ever actually really happened in my life I think. I think probably for the software world. Just like today, I had somebody sending a four class to make the React webpack Rails tutorial, have a dock for example, things like that. We do stuff like that, we’re using dock for all that stuff. It’s just an example of how the community getting around a project really turns that project into something special. That it’s going to be better than any commercial software you’ll ever buy.

Jerome:         Yeah. I definitely agree on that. I just wanted to see if there was any information or data. I was researching, Shopify, people tend to post that type of stuff. I just want to see how fast the production on most React and Rails.

Justin:           We do list a number of projects that are on there, that are using it. We do have a projects page, we also have another page in the repo where we just kind of put little strange ads. People telling me that they love the approach, I’m pretty stoked about that, I think it’s probably the number one pay off you get as an open source creator is some people telling you they love what you’re doing. It’s probably better than anything else in the world, almost.

Charles:        Alright. I’m under a little bit of a time crunch so I’m going to push us over the picks. Before we do that, if people want to hire ShakaCode to build them something, or I also noticed on your videos you mentioned you have a coaching option for people getting React and Rails going, where should people go to check that stuff out?

Justin:           Yeah. Go visit us at shakacode.com. We’ve got links there to everything that we’re doing. Just go reactrails.com, you’ll see example of React on Rails running live. From there you can click off and go see the Git repositories.

One of the things we started doing this last year, in the past we’ve always done really big development projects. We had some people and said, “Hey, can you do and just help out my start up. We just really want to get going to your system.” We figured out a start up coaching plan for $1,500. It really lasts a very, very long time and we’re there for you providing technical support not just how to use React on Rails, but how to use the entire ecosystem of React, Redux, React router, webpack.

What I find in doing development, it’s not how fast you are, it’s just about not getting stuck. If you can just not get stuck and have someone there to help you go in the right direction always, it’s amazing how much more productive you can be. Rob has been absolutely instrumental in helping out with our coaching program. What can you say about how people benefited from it?

Rob: We go beyond just React on Rails stuff because the React and Rails API is actually the surf server is pretty small on purpose. A lot of times, we’ll get into stuff like best practices and how to organize your application, how does Redux really work under the hood, what is React really doing, how do you solve these types of problems. On full Stacks, if they want to know how do I have Rails do this to talk to it or how do I write my copy bar test to help with that. Everything’s game, I’d help people with all that type of stuff and I code it everyday for our production apps.

Justin:           These guys stopped doing the production app is just next level but it’s not like stuff that we can just necessarily share with the world because it’s just complicated. It’s not like it’s secret, it’s just complicated. It’s always changing, that’s just the way the world’s going. There’s just some articles from Asmani on just how do to these new types of apps, how to use a server rendering, that use dynamic routes, and do all the stuff. We’re working on putting that into our production system as well.

One thing I do mention on the open source pages is that we do support the funding of React on Rails in helping out people with coaching. By hiring us to do coaching, you are supporting this open source effort. Same thing goes if you choose to have us right project for you as well to do a project. I think that we put the same love into all the production code we write that we put into the open source. If you’re going to get code that looks great that works, someone’s going to be able to pick up, they’re not gonna go, “Who wrote this stuff?” They’ll go, “This looks good,” and just get to work.

Charles: Alright, sounds good. Let’s go ahead and do some picks. Jason, do you want to start us off with picks?

Jason: Sure thing. I got two picks, both of which are books. One is one of my favorite books of all time, The Autobiography of Benjamin Franklin.

The other one is, I don’t even know how I found this book but it’s a book about primitive navigation techniques and it’s called The Lost Art of Finding Our Way. I found out from this book that I thought I knew why earth has seasons and I didn’t know and this book told me. Check that out. You might have the same experience as me because I talked with other people, I’m like, “Do you know why we have seasons?” They’re like, “Yeah.” But what they taught you in school may not be right. That’s pretty interesting.

It’s one of those books you read and you’re just like, “How can one person know all this stuff?” I found out that the guy who wrote it is a professor of Physics. It’s like, “What is your deal, guy?” That book just totally blew my mind. Those are my picks.

Charles: Alright. Jerome, what are your picks?

Jerome:         I have two picks. They are also books. My first book is Hacking: The Art of Exploitation. You guys know frontend, we had a huge DDoS attack on the entire East coast. If you use Twitter at all, you notice that this was just part as a millennial that was born era of internet. It just hurt me all day. My favorite sites were down.

I decided to pick up Hacking: The Art of Exploitation to just see how things like these was done and to learn to protect myself and others. I definitely recommend this book to anybody that wants to actually get to a level where they can start building some programming, depends on programming measures.

Second book is a Billion Dollar App. I think Billion Dollar App is a really good book in general, just whether you’re doing web apps or mobile applications and it helps you get on that thought process of what does it really take to make a successful product. Those are my definite two picks for the show.

Charles:        Awesome. Have you read Ghost In The Wires by Kevin Mitnick?

Jerome:         Negative.

Charles:        That’s another great hacking book. I guess I’ll throw that one out as a pick.

The other pick I have, I get crap sometimes and I pick these things like some crap out pick. My kids have been out of school for the last few days and just spending time with them and hanging out, watching movies. Kid’s school breaks, just a lot of fun, so I’m going to pick those.

The other one that I’m going to pick is if you’re deep in the bowels of working with boy scouts, there was what they call a commissioner’s college. I’m a commissioner, I help with the Round Table which is the training for scout leaders. In particular, I work with camp scout leaders. That’s training for them. It’s just really great to get some awesome training on how to lead, how to train, how to teach, how to help people do better at what they do.

If you are an adult looking to get some leadership training, then I highly recommend that you go and see what the boy scouts have to offer. Go be a boy scout leader and then go get the training for absolutely cheap. It is amazing training.

I mentioned Wood Badge a few months ago, it’s kind of the top of the mountain training for leaders and it was incredible but then just go for a Saturday for a few hours and again, get some refreshers on some of the topics that I already knew and then get some other training on some areas that I haven’t really thought much about. It was terrific. I’m going to pick the Boy Scouts of America and in particular I’m going to pick their adult training programs. Justin, what are your picks?

Justin:           friendsandguest.com, that is cycled on React on Rails. You can check that out. We’re just coming out of beta in that so it is pretty young.

There’s a book I just read that’s pretty awesome, Play Bigger – How Pirates, Dreamers, and Innovators Create and Dominate Markets. That just came out June 14th this year on Amazon. The guy, KC Penton of Couchsurfing recommended that to me. KC is actually involved in my start up operations in the sense that he created a product company called Mast.ly. That gives a way, it’s an alternative to do traditional VC funding. That would definitely be on one of my topics, Mast.ly. If you’re a startup founder and you want to do something where you don’t have to do the conventional VC route and give your team members a slice of the equity, we do that for Friends and Guest.

Finally, last pick I’d say is just it’s going to go without saying is nothing like a healthy lifestyle especially working for remote first company in the state of Hawaii. If you can do that, get a standing desk, recommend some things like bulletproof coffee as well, and get off too many cars, get some exercise, get a good night sleep. Follow me on Twitter and stuff, I tweet about some of that stuff and that’s it.

Jerome:         You’re into file hacking?

Justin:           Yeah, a little bit. Dave Asprey, Tim Feriss are some of my favorite podcast, and Mark Sisson’s book, the Paleo Blueprint.

Charles:        That’s a good book. All right. Rob, what are your picks?

Rob:         Since we’re talking about JavaScript related stuff, the first one is DrBoolean’s Mostly Adequate Guide to Functional Programming. This guy refers to himself as DrBoolean, I think he’s pretty cool, he actually has a frontend masters course. This thing is a free book, it’s on GitHub, he’s got PDF versions, all the different ebook formats. It kind of goes through using JavaScript examples, kind of like a primer on what functional programming is and how to do it. It’s about this whole idea of not having state in your application, you can’t get rid of all those types of bugs where I thought this very bold app, this data at this point and it didn’t did. Those type of things, starts you off slow and talks about stuff like curating and then dips into some of the advanced stuff that maybe is more theoretical than practical. I definitely at least prefer seven chapters like a must for JavaScript programming because it’s just made my code so much better, I feel like. That’s pick one.

Pick two, it’s kind of a tutorial I would describe as that, or exercises really by a guy name Jafar Husain, who’s a developer over at Netflix. Specifically, they’re meant to teach you how to use something called RXJS which is kind of functional reactive programming.

That’s not really why I’m recommending it, I’m recommending it because it’s such a good way for explaining and understanding how to use map, reduce, and filter. Everyone knows how to use map or reduce. It blows mind how powerful just a couple of these functions are. Stuff like flat map and stuff like that in the ways you can put them together and it’s just so improved my understanding of how to use those types of functions and do those kinds of things to my apps, it translates to Ruby, it translates to any languages kind of map or reduce function. Those have really helped my code a lot. Just yesterday, I had to help a guy do a Cartesian product of two arrays. You’re able to do it with one expression, just by nesting flat maps, it’s really cool.

The third thing is a YouTube video, that’s one about this band that I’m just obsessed with called Tesseract. They have the album called Altered State and this is a portion of that album called Of Matter. These guys got play in three different time signatures at the same time. They’re listening to click tracks in the right different tempos, like 4/4, 7/8, and even a 1.2, 12/4. It’s just a great performance. I like to listen to it while I code.

Charles:        Very cool. Thank you both for coming and talking to us about this. This is really interesting. I’m also going to put out there that Justin did a Rails Remote Conf talk on React on Rails. He’s got some awesome videos up on YouTube that we watched in preparation for this and there’s a ton of information out there that he already shared before we did picks, so go check them out.

Justin:           Thanks a lot, Chuck.

Rob: Thanks.

Justin:           Thanks a lot Jerome and Jason. Awesome, let’s be in touch.

Jason:        Yeah, definitely.

Jerome: I’ll be joining the Slack channel this week so I’m looking forward to it.

Justin:         Awesome. Good talk, see you guys.

x