MJS 022: Cory House

00:00 2791
Download MP3

My JS Story Cory House

On this Episode we have another JS Story, and this time it’s with Cory House, a Pluralsight author, software architect for Cox Automotive, and a consultant with a focus on React. Listen to Charles Max Wood and Cory discuss a bit about how Cory got into programming, how learning how to learn is vital to being a talented developer, as well as using documentation as your development environment to ensure your code’s documentation doesn’t fall behind. This and more right here. Stay tuned.

How did you get into programming?

Cory starts his story as a business major in college but had interest in computers. He spent time around various computers and machines, giving him experience in various operating systems and platforms. On any given day he would be using any of three different operating systems. His interest in computers inspired him to double major. He started learning Cobalt and Visual Basic and C++. He talks about being interested in web development, including Flash. He specialized in Flash throughout college, as well as early on in his software development career. He also talks a bit about that the open web seems to innovate in a way that keeps it relevant. He talks about using Flash to make websites with entering screens and animations and now that is obsolete. Charles mentions that it’s interesting that his main interest was business and computers became something he was interested in later on and that you don’t have to be someone who started young to be proficient. Cory talks about being driven to catch up, being around people who knew things off the top of their head while he was still asking questions and looking things up.

Learning How to Learn

Out of college Cory found that he had a degree, but what he had really learned was how to learn. He never used Cobalt, C ++, or visual basic after school. Learning how to learn combined with being able to create a focus on a specific technology are vital. Charles adds that he would hear often that it took being a natural in programming to get it, and that maybe being a natural was really just being someone who has learned how to learn and to focus.

Getting Good With Your Craft

Cory mentions that working with someone who head and shoulders ahead of everyone else. They were working in Unix and seemed to know every single Unix command and flag. He found it inspiring to see someone take the craft so seriously and to learn a specific technologies tool with so much dedication. Some technologies will be so important that they will be key technologies that will still be useful many years later. Cory suggests that one of those tools seem to be JavaScript. JavaScript is almost mandatory in frontend web development. Additionally, JavaScript is reaching into other new technology types including IoT and VR and other places, constantly expanding.

How did you get into JavaScript?

Cory talks about how it really all got started when Steve Jobs killed Flash. He opened his mind to other technologies and started working with JavaScript. Remembering learning jQuery, he found himself really enjoying it. He started building online business applications. Browser inconsistencies were a huge issue, making it so that you’d have to check your work on each browser to make sure it worked cross platform. Things are moving so quickly that being a full stack developer is becoming less and less prevalent, to the point where he considers himself primarily a JavaScript developer. Being an expert in a single technology can make you really valuable. Companies are running into issues with not finding enough people that are experts in a single tech. Cory suggests that employers should find employees that seem interested and help allow them to focus and learn whatever that tech is. Charles talks about the split between developers that tend to lean full stack and plug in technologies when they need it versus developers that work exclusively in front end. He suggests it may be a case by case situation.

Service Oriented Architecture

Cory suggests that service oriented architecture movement has moved us that way. Once you have a set of services set up, it becomes more realistic to turn on the front end. If there were a good set of services there, Cory adds that he doesn’t think he would be able to build services faster using a server side framework like Rails, Django, or ASP.Net MVC than he could in React today using something like create React app. The front end has become much more mature. Cory mentions that he has had good experiences with ASP.Net NPC and Visual Basic being a Microsoft stack developer. He adds that he doesn’t feel like he has given up anything working with JavaScript. He adds that with the nesting of different models together, he gets to reuse a lot of code in server side development. NPM makes it easy to stand up a new package. If you are planning to create an API, it becomes much harder to use a server side rendering stack, with so many APIs available, it’s a logical move to go client side.

Possible Future for Front-end and Back-end Roles

Charles brings up that the development of things like VR are making changes in the roles that front end and back end development play. The front end will more to taking care of the overall application development of apps, while the back end will become supporting roles as services and APIs. New technology like VR and artificial intelligence will need a high amount of computing power on the backend. The front end will focus more on the overall experience, display, and the way we react with things. Charles talks about how the web may move away from being just an HTML platform. He says that it will be interesting to find where JavaScript and frameworks like React will fall into this shift into this next generation. We already are seeing some of this with the capabilities with canvases, WebVR, and SVG and how they are changing how we experience the web.

Reasonable Component Story

Cory brings up being interested in the Reasonable component story. Sharing code from a traditional web app, to a native app, and to potentially a VR app as well is exciting and he hopes to see it flesh out more in the coming years. He talks about going to conferences and how much we have built and how much we don’t have easily sharable innovation. He hopes to see it solved in the next few years.

What contributions have you made to the JavaScript community?

Cory mentions working on the open source project Slingshot. He was trying to solve issues that many found in React. React isn’t very opinionated. React is for writing reasonable components for the web, but it doesn’t have opinions on how you structure your files, how you minify, bundle, deploy, or make API calls, etc. He realized that telling people to use React and to deal with those issues wasn’t reasonable. He created React Slingshot as a development boilerplate. He put it to use in many applications and it became popular. It’s easy because it did things like allow you to run NPM to pull independencies and pull a file, it would fire up a web browser, watch your files, run tests, hot reloading on save, and had a running Redux application build it. It allowed people to get started very quickly. He talks about how he wasn’t the only person trying to solve this issue. He says that if you look now there are well over one hundred boiler plates for React that do similar things. Most popular being Create React App. Contributions outside of this, he talks about editing documentation on open source projects being part of his biggest contribution, writing it in markdown and then making pull requests.

What are you working on now?

Cory adds that he just finished his 7th or 8th Pluralsight course on creating usable React components. At work they create their own reusable React component library. He says that he realizes that it’s a complicated process, where all decisions you make, in order to have a reusable component story, you have to make a lot of decisions. Things like how granular to make the components, reusable styles and how they are packaged, how they are hosted, will it be open or source, etc.

Publicly Closed - Internally Open Source Projects

Cory talks about the idea of having it as a closed source project, but treating it like an internal open source project for the company, having many people feel invested into the project. He found creating the documentation story was the toughest part. Having solid documentation story that helps with showing how to use the components and it’s features and behaviors. He spends much of his type looking at other documents to help him come up with ways to create his own. He talks about generating the documents automatically with the updates so that they are always in sync. Charles adds that documentation syncing often happens right in the comments, which are also acceptable to being outdated.


Cory adds that a useful way to allow for well documented and safe pull requests is to make a pull request template in GitHub by creating a file called pull-request-template.md so that any time someone makes a pull request, that .md template will populate the pull request. Cory has a checklist for a pull request like making sure there are tests for any new components, the file name should have an uppercase character, is there a ticket open, etc. All of the basic things that should happen in a pull will be in the pull-request-template.md. Charles adds that documentation is one of the things that gets ignored. Having a standard process is very important, more so than getting the job done faster. Also having an outlined expectation for how it’s delivered is important as well.

Documentation as Development Environment

A useful trick that Cory uses, is using the documentation as the development environment. Anytime they are working on a new component, they start with a documentation site, making changes within the documentation and then it hot loading your changes live. This way your documentation is front of mind and keeps the documentation fall behind.

Why React instead of the other frameworks?

Cory says that he can sum up React in a single sentence. He says that your HTML sits right in the JavaScript. Which usually sounds bad to a large group of developers. He expects people to react negatively when he talks about it. What he has run into as a common problem, is people separating concerns by filetype and technology, but with React he seems the common problems in terms of components. Cory says that components are the future. Industries that have matured utilize components. For example car manufacturers or even electronic manufactures build things in modules and components. Things that are reusable should be encapsulated into a component instead of trying to hold it in our heads. This makes it so things look the same and reduces many mistakes. You can create components in different frameworks, but React co-mingles markup and javascript with something like JSX. You’re not writing HTML, you’re writing JSX that boils down to HTML. That one element is fundamentally what makes React easier to Cory. For the most part, React can be learned by JavaScript developers in less than a day because many of the things you need to do in React, is just basic JavaScript. Charles adds that components are a concept coming up in various frameworks and is becoming more popular.


Cory’s React Courses on PluralsightEssentialism the book


Get a Better Job CourseAngular Remote Conf (now Ruby Dev Summit)React Podcast Kickstarter


Cory’s Twitter


MJS 022 Cory House

[Music]__[Have you ever felt that you are falling behind? Or that the programming world is moving so fast but it is impossible to keep up? Then there’s the issue of where to go to make sure you’re up-to-date. The answer is to join the community dedicated to discussing the latest in JavaScript. I mean wouldn’t it be nice if you got JavaScript Jabber all day? Well, you can! Kind of. We’ve set up a Slack community for JavaScript Jabber that you can join. That means you can connect with our listeners and guests on a platform you’re most likely you are already using. Plus, we set up a keeping current channel that pulls stories from across the web to help you know what people are talking about. And coming soon, we’ll be holding monthly webinars and roundtable video chats to connect with experts in the community and with each other. So come join us javascriptjabber.com/slack.] CHARLES: Hey, everybody and welcome back to another My JS Story. This week we’re talking to Cory House. Cory, do you want to introduce yourself? CORY: Hi there, guys. Yeah, Cory House. I am a Pluralsight author and a software architect at Cox Automotive. I also do independent consulting focusing on React these days. That’s keeping me busy since everybody seems to be wanting to talk about it. That’s me in a nutshell. CHARLES: Super cool. And you’ve been a panelist on JavaScript Jabber for a few months. CORY: Yup, I’m enjoying it. CHARLES: Oh, good deal. Yeah, so we thought we can get you on and see if we could kind of tell people your story. Let them know where you came from and how you got in to programming in JavaScript. CORY: Sounds good. CHARLES: Right. So the first question I usually ask people is - how did you get into programming? CORY: Well, I was kind of strange. I mean I was a Business major and I was enjoying that but I knew that I also have a lot of interests in computers. I had always… growing up, I was one of those lucky kids that had experience with all the platforms. At a pretty young age, I was somebody who had a very early RadioShack computer. And I remember I had a friend across the street who had a Commodore 64. And then, one of my other good friends had an Apple II. So in any given day, I was mucking around with 3 different operating systems. For the longest time, that was just, you know, a hobby. I think that I really saw that it got to be a career for me. But in was in college that I decided to double major. I was actually majoring in Marketing because I was interested in Advertising. Not really realizing that Advertising and Marketing are different things. Nonetheless, I decided to double major. And so I found myself in this odd position where during school, I was learning COBOL, Visual Basic, and C++ but during the evenings, I was really interested in web development. I remember I was in school in the early 2000’s, right when the web is really taking off. So it was a pretty exciting time. My interest at that point was Flash. For those that didn’t… they were lucky enough not to be doing web development in the early 2000’s. The thing about Flash that is awesome was you didn’t have to deal with the pains of cross-browser usage. Getting IE and Netscape to do what you wanted to do back then was really painful. And the story of JavaScript was, “Hey, if you made a typo, you just get an alert that says, ‘Sorry, you had a syntax error.’” You wouldn’t even know the line that you’ve made that syntax error on. So the dev tooling was pretty much non-existent at that point. And that’s part of why I felt like Flash is going to be the future to the point that I really ignored the web platform itself early on. I was a Flash specialist throughout college. And then, early on, in my software development career before I shift from there… I mean, it’s funny because back then, I made those decisions because I felt like clearly we would, as an industry, choose something that makes life easier. But since then, I think ever since then, I recognized the importance of getting on the open web and the fact that it seems to continue to innovate in a way that keeps it relevant. So ever since then, I haven’t gone down the road of the proprietary side. Largely ignored even mobile development because I like the open web and the constant innovation that we see there. CHARLES: Yeah, it’s really interesting. I remember… man, how long ago was that? It sounds like we went to college about the same time. I remember the Flash. I mean, you’d find them at all of these websites because it just gave you different level of interactivity and user experience. And then, yeah, it’s interesting how things have changed. And now, Flash is the devil. CORY: It is, yeah. Oh, there’s this little weird era where it was important to have a front door to your website that would often do some kind of flashy animation, place a music, and then, you’d click to enter. I remember building those sites and getting paid to do so. At the time, that made total sense to me but it is interesting how it shifted very much to the opposite mindset of minimalism, flat design, and getting rid of skeuomorphism. Those sorts of things are not just useful because it makes things simpler but just also helps improve performance as well. We’re not wasting time on things that people don’t actually need. The spurious has largely been, well, that has really gone out of vogue, which I admire. CHARLES: Well, it’s also interesting… one of the things that I’d just like to kind of call about your story thus far is… you mentioned that you’ve had a RadioShack computer and that you’d played with it. But ultimately, we hear a lot of stories right where people are, “Oh, when I was 8 years old, we got whatever computer. And that’s why I’m in computer just because I learned it as a kid.” It sounds like there was some of that to your story but your primary focus was actually business and advertising, and not necessarily computers. You know, you kind of came into, okay, this is something that I want to do. And I think a lot of people just think that the people at the top of the field in programming, they just came in and they always knew they wanted to be a programmer. And they had done it as a kid. And so unless you had a total nerd fest from the time you were 4, you just can’t be a programmer. I am really trying to debug that because there’s so many people that come into it these days. It’s okay, well, I was doing this thing and that I realized that I really want to spend my time and make money in programming. CORY: Yeah and it’s interesting because I’m a big fan of the book Outliers by Malcolm Gladwell. It tells that story of so often that people end up being stand-outs in their industries had a combination of luck but also putting in a whole lot of time very early on. I don’t know. I think for me all that experience with different computers although, I wasn’t sitting writing programs… I didn’t write any significant programs, although, I coded in high school al little bit. My first significant program, I was 23 years old. I was probably 21 or 22 years old. And that was working with Flash and then, also just doing coding in college. I think I was probably junior in college before I really started taking programming classes so I was late on that front. I think there’s no denying that there’s an advantage to getting in early but there are so many examples to people that started later and then, just really made up for lost time. That has definitely been me, which driven me. One of my first jobs, I landed it… in retrospect, in sheer luck, I just knew the right person and happened to hit it off. And they helped me get in. I don’t believe I was even close to the best candidate but I felt very fortunate to be given a chance. The thing that drove me was having all these people around me that were very clearly, they knew all the stuff up the top of their head that I would have to search for. I really admired that. And I realized, okay, yeah, I’m clearly the weakest person on this team and that’s not a very comfortable position to be in. But let me see how quickly I can teach myself to swim. So I found myself reading in the evenings, practicing, and you know, doing the work. There’s no shortcut for that. I did find that it was 5 or 19 years before I felt like I hit across that bar, where I felt like, okay, yeah, now, I really feel like I can come, do a team, and be a leader, rather than somebody who’s constantly asking questions. It takes a long time to get to the point that you feel comfortable, especially in a world where everything is shifting so rapidly. I found myself out of college. And in fact, I come to think of it, this is probably true for a lot of people, you got to college, and you got your degree. But what you realize is, what they’ve really thought you is how to learn. Because most of what I went through on school, I never touched COBOL. I never touched C++. I never touched Visual Basic. The only technology that I learned but continue to use it is relational database concepts. There’s this recognition now that the most important skill that we need is the ability to… well, 2 things – to be able to pick a technology because there’s constantly new things coming out so you have to be very careful about what you pay attention to. And you have to effectively default to ignoring things so that you can be relevant in increasingly smaller slice of this technology world. And then, once you can do that, then, having the ability to teach yourself. I think what’s really helpful for me is getting really comfortable with reading other people’s code with manipulating it and then learning by example. And then, finally, in my last few years, I’ve decided to teach others through blogging, through speaking at conferences, and through Pluralsight. CHARLES: Yeah, there’s a couple of things there that, you know… And I felt this way when I was getting into programming. I had some friends that just seem to have this intuitive grasp with things that I just didn’t. And a lot of people, yeah, they’re like, well, you know, you have to kind of be natural in order to be a good programmer. I think, now, the thing that I didn’t see there was they’re putting in the time like you’re saying. And that they have all those fine-tuned skills to know what to learn and how to learn all this stuff quickly. CORY: Right, yeah. And I think that was very early on in my career that I was around somebody who was head and shoulders above anybody I’ve ever met in programming. I felt like he was one of those people… we were working on UNIX at the time. He seemed to know every single UNIX command and every flag that you’d possibly pass to it just by heart. He could instantly type all of these out. I found that just fascinating in a way that I thought I don’t know if I could ever get there. But I find it inspiring to see somebody that has taken their craft so seriously. And taking the idea of, “Here is my core toolset.” These tools are really lifelong tools because there are very few technologies that you can learn early on that could truly be relevant for your entire life. But getting good at the UNIX command line, most likely could still be useful decades from now. It’s hard to imagine UNIX going out of favour at this point. It’s just so mature and so ubiquitous. I think another really useful thing that he taught me was trying to find what those core technologies are. In fact, that’s why I’m talking to you today and why I like being a panelist in JavaScript Jabber. It’s because JavaScript is another one of those things that’s become so ubiquitous, I have a hard time picturing a world without JavaScript a decade from now. The JavaScript skis that I learned in early 2000’s have continued to make my life easier all these years later. CHARLES: But yeah, I feel the same way. I think JavaScript’s one of those technologies to where if you really want to avoid coding in JavaScript, you probably can in the foreseeable future. Of course, web development, you have to have somebody else doing some of that because there’s just some level of web development stuff that has to happen on the front-end in JavaScript. Even then, JavaScript is becoming a thing in IoT, VR, and all of these other places. And then, you got single page apps where it makes sense to do those kinds of things. Yeah, it’s huge area that’s just constantly expanding. You know, as much as people are excited about ES6, ES7 or ES2016, ES2017, I don’t know what the… anyway, they’re years. But whatever those are, ES5 is still kind of a standard thing in the browsers. And I don’t know if that’s even going to go away. In ES6 and ES7, those principles still apply. You’re absolutely right. Picking those ongoing useful tools makes a lot of sense. CORY: It’s something that I’ve also looked for in my jobs. I’m disappointed by how often I hear people in interviews, say, “Well, I’m really excited to work here because I’ve always wanted to learn technology X but my current job wouldn’t let me do that.” You’re always free to learn these things. Nobody’s going to force you not to. Now, I understand the whole - I want to learn it on the job. And I can also appreciate some people just don’t have the free time on the side. Sometimes that’s really hard to carve off. But I certainly look at, in my own job, hopefully, I have a fair amount of autonomy where I can help encourage moving into new directions, experimenting, and trying new things. Almost certainly, if you’re using a technology that’s been out for a few years, there’s probably something that’s objectively preferable in some specific ways that would allow you to sell it to your boss and try that new thing. CHARLES: Yup, absolutely. Well, let’s get into the next question because we’ve kind of talked our way around a little bit… that is, how did you get into JavaScript? CORY: Well, my moving into JavaScript came right around the point when Steve Jobs made moves to make sure that Flash wouldn’t ever exist on iPhone. I remember that being a very clear… for Flash. Okay, if it’s not going to be there, it doesn’t have a future. It’s actually before that that I had started doing traditional web development in earnest because I was in a position where we’re doing both flash development and traditional web dev. I realized that I was being close-minded that there is a bigger world out there to try. Early on, I was building line of business applications and really enjoying that too. Although, continuing to feel the frustration, I remember when jQuery was finally released. I was thinking how amazing that was and how much easier my life was going to be after that because I spent so much time trying to get simple DOM manipulations to work. And that was largely because back in that day, before the time of jQuery, there were so many browser inconsistencies that I remember getting something to work. Then, okay, let’s start checking cross-browser. You think you were 80% done but you were really just 20% done because cross-browser is so, so painful. So I continue to feel like life has gotten pretty luxurious since then. Anyway, I found myself doing pretty standard line of business apps. And I have since then gotten to do more and more with JavaScript. To the point now, I would never have guessed it but I consider myself mostly a JavaScript developer, not just a front-end dev but particularly focused on JavaScript. I think that’s one of the oddities of the new world. Here it’s a recognition that things are innovating so quickly now that it’s becoming less and less realistic to be a “full-stack developer.” People have thought for a while that the term “full-stack” was problematic because how far does that stack go? I’m recognizing now that there is enough interests and enough churn happening just in the front-end development space that being an expert there can make you really valuable. That’s the direction I’m headed in my current role. I went from being full-stack working in C#, working in JavaScript. At the time, we were doing a knock-out in Angular. But since we’ve made the shift over to React, I’ve decided just to be a front-end architect. It’s just a strange role. Just a few years ago, that would have sounded like a pretty absurd thing to say. CHARLES: Oh yeah. CORY: At client side, development has swallowed up much of the complexity that use to sit on the back-end. That’s becoming pretty realistic. And I see a lot of companies right now, as I’m consulting, that they’re struggling with that very thing. They’re saying, “We have a hard time getting the front-end right because we don’t have anybody that’s really focused on it.” So I think, one thing that a lot of companies could do is either find somebody or take somebody who’s currently doing full-stack work but interested in the front-end. Allow them to merely focus on the front-end story and innovation that’s happening there because there’s so much goodness out there in the open-source community that every week, I find new things that can make our life easier. And the great thing is, we don’t pay a dime for it. We just leverage this good open-source… these good open-source projects and life gets better. CHARLES: Yeah, I think it’s interesting too. I mean, it’s funny because I’ve had this conversations with a lot of my Ruby friends. There’s still the opinion that it’s like, you know what, I don’t see the need for all of this front-end craziness. And so, you know, there’s still doing server-rendered pages that are backed by the back-end. Then, they just kind of plug-in whatever they need – jQuery or what-have-you on the front-end, where they actually need it. And then, you know, we have these other people that are more in the position like, Where you’re in, where they’ve focused a lot of time and effort into becoming good at the front-end, I get asked sometimes by both groups. Who do you think is right? It’s kind of funny getting to a place where it’s, “You know what, I think both groups are right.” I think, sometimes, using something like Angular or React, that’s probably overkill for whatever you’re doing. And sometimes, it makes a ton of sense to have a single page app and just really nail the front-end the way that you want to in your application. I definitely see where you’re coming from with your point of view. I don’t know that it’s necessarily the case for every case on the internet, though. CORY: I think part of it comes down to… what pushed things to that direction is the whole sort of architecture movement that once I have a set of services set up, it becomes a lot more realistic to just go ahead and turn on the front-end. I would say, if they were a good set of services there, I’m not sure that I could build that set of services any faster using a server-side framework like Rails, or Django, or ASP.NET MVC than I could in React today, using something like Create React App. In either case, I got to spin up a front-end, I have to write the HTML. Those models… the front-end has gotten mature enough now that I don’t feel like I’m giving much up. And that’s a strange place to be as someone who really enjoys also Microsoft stack developers. I’ve enjoyed ASP.NET MVC. Web API, Visual Studio – those are really nice experience. But I don’t feel like I’m giving much anymore sitting in VS Code, working in JavaScript because I have the testing story has gotten very mature. The beauty of hot reloading of hitting save and instantly seeing my changes, not waiting for a compilation, and then, that whole… whether you’re in Angular, or React, or Vue, having this component model, being able to nest different ideas together, I find that I get to reuse a lot of code in that space in ways that I typically didn’t do when I was doing server-side development and ASP.NET MVC or Web Forms. And that’s maybe partially because the stories for sharing code are just so good today in JavaScript that NPM makes it so painless to stand up a new package. I don’t know. To me, I think what’s largely comes down to is if you are planning to create an API, then, it becomes a lot harder to justify using a server-side rendering stack. Since so many people are using API’s now, or creating API’s, or already have them at this point, it becomes a pretty logical move to go client-side CHARLES: Yeah, I think you’re right. I think in some ways, though, I mean, if you’re comfortable in a certain paradigm, I think it makes sense to stick with that paradigm. And then, yeah, go out and learn some of these other technologies, some of these other ways of doing things, and then, see where things apply, see where things make easier and where they don’t. I think the idea that the front-end is going to move more and more to take over sort of the over-all application development on any of these apps and the back-ends will become kind of the supporting role services and API’s… I think it’s going to be more and more of a thing. Though, I really do believe that it’s going to be interesting over the next few years to see what the capabilities are for the web platform. Especially, when we move into things like virtual reality, we have like web VR and different areas like that one where new technologies are coming into being. And then, essentially what we have is we have these back-ends that need a high amount of compute power because they’re processing large amounts of data or performing other functions that we now currently lump in with Artificial Intelligence. I think the back-end is going to move toward those kinds of things and the front-end will move toward the over-all experience, display, and the ways that we interact with things. I don’t know what the web browser is even going to continue to just be an HTML platform. I really think that a lot of the things that we’re seeing with web VR, for example, and just some of these other capabilities with canvasses, SVG, and the ways that people interact with things on their phones, and see the world through the lens of whatever we call the web - I think that’s going to change. I think it’s going to be really interesting to see what JavaScript’s role is in all of these. And where the frameworks like React, Angular, or the next generation of those are going to take us with regard to all of these capabilities of the browsers that are going to give us. CORY: Yeah, it’s really hard to picture what dev is going to look like in 10 years. Even in 5 years, it’s very hard to predict. I find it interesting… right now, I’ve been really fixated on this reasonable component story and when you’re talking about there, thinking about how I can share code between my traditional web app and my Native app, potentially some VR app, as well. That, I feel like there’s another story that I hope to see flashed out more in the coming years. We have this whole reasonable web component story but we haven’t seen that standard take off like I hope it would. It continues to frustrate me that I go to these conferences, and I think about all the different things that we built and our inability to share our innovations with each other when it comes to… well, if you involve HTML, there’s a very, very low chance that you can hand me what you built and I can put it to use on my application. It would end up having to be, okay, you and I chose the same front-end framework, the same sort of bundling stories, and we have compatible views about how we view styling. So that piece is a big open area that I love to see solve in the next few years. CHARLES: Yup. I kind of want to get in to this next question. You’ve talked about Pluralsight a little bit, and some other things that you’ve done. What have you done in JavaScript? What contributions did you feel like that you’ve made to the community? CORY: Well, the most popular open-source project was react-slingshot, which has been up there since the fairly early days of React. What I was solving was the same problem that a lot of people felt in React, which was React wasn’t every opinionated. React is a way to write reasonable components for the web but it doesn’t have any opinions about how you do testing, how you structure your files, how you minify, how you bundle, how you deploy, how you do API calls, and the list goes on and on. I was sitting there at work recognizing that one thing that really wasn’t tenable was for us to just tell everybody, “Hey, you can use React and then, all of those things I just mentioned go to side on your own.” We certainly didn’t want every delivery team going in and making their own decisions in making a bunch of bespoke applications with completely separate opinions in this area. So I created that slingshot as a development boiler plate, a very opinionated way for us to do React development. And that worked out really well. We put it to use on multiple applications and it was nice. I mean, I put a lot of work into it. It became popular because at the time when I released it, there wasn’t many options quite like it where you could literally just go in and say npm-install, pull all dependencies, and say, npm-start. And it would fire up the web browser for you, it would watch all our files. It would run your tests every time you hit save. It would do hot reloading. It include working a Redux application built-in with all of the example code there. So people could really get started very, very quickly and they wouldn’t have to spend… I literally spent months learning all of these to get this to work in a way that I felt like was reliable and scalable. Fast-forward awhile, I was far from the only person who had this idea today if you go out and search around, you’ll find there’s a hundred React boiler plates out there that are doing similar things to what I described. The most popular being is create-react-app, which I highly recommend. Facebook’s done a wonderful job on it. It is really covering essentially the same story that I had but a lot of other little things that they’ve added in that I haven’t even listed here. That’s my most significant contribution as far as stars go. I would say, as far as open-source goes, the place that I often contribute is strangely an open documentation. I tend to find, when I’m reading documentations and I see it efficient, I often read documentation in the marked-down view so I’m literally editing the documentation as I read it. In that way, I’ll just put in a pull request when I’m done. And then, usually, they’ll be a half dozen things that I put in as I was reading the docs to help them prove it. I feel like if more people did that, then, documentation would radically improve over time for all just making documentations a little bit better, as part of our way of saying thank you as we’ve used some open-source projects. CHARLES: Yup. What are you working on these days? CORY: Well, for these days, I just finished my 7th or 8th Pluralsight course, which is on creating reusable React components. This has been on my mind for the last years because at work, we’ve created our own reusable components library. And I just came to realize that it’s a wildly complicated process that I didn’t think was that hard. But you have to step back and realize that all the decisions that you make in order for your company to have a reasonable components story, you have to bake in a lot of decisions. You need to decide how granular to make your components. You have to think in terms of how we are going to create reusable style, how we package these styles into our components, how we distribute them, or how we host them. And also, what are even are simple model of contribution? …where we run it as an open-source project, or we run this as a sort of closed-source project, which I find is an interesting idea. This is the idea of basically having or creating a reusable component library but treating it like an open-source project that’s actually managed in-house. So nobody public can get to it but otherwise, it’s treated like an open-source project. Anybody in the company can submit a pull request. Lots of different people can feel vested in the project and help contribute to its success. And that’s a good way to help get things rolling. That’s a model that we found really useful. The piece that I found that is perhaps most challenging was creating a good documentation story. Recognizing that if you create reusable components, one thing that’s really important is having solid documentation that shows how to use them, show us what knobs and switches you’re providing, ways for people to… data and get different behaviours. I spent a lot of time looking at dozens of different open-source React component libraries and seeing how they did their docs. I finally came up with the way to generate all the documentation using a combination of different open-source projects, which is pretty cool. Because now, our setup is we create these React components, we put some comments in that are a lot like JS docstyle comments to describe the properties that they have, to describe the examples that we have created. And then, all of our documentation is just generated automatically. We don’t have any kind of worry about our components and the documentation itself. That’s bitten a lot of people before. Say, “Okay, yeah, we updated the code but we didn’t keep the docs updated.” So I’m a big believer that your documentation should be generated automatically. That way everybody’s assured that it represents the real world. CHARLES: Yeah, I mean, that’s definitely something that I think is a universal problem with the documentation especially if it isn’t generated automatically. But yeah, the way that I usually see docs generated automatically, is basically comments right on the function or method in the code. And so, those comments get out of date too. CORY: They certainly can. That is true. That’s a risk with our setup. I think it’s probably as good as you can get them. I don’t know how else you got to have some kind of human-readable verbiage about these things. So I found encoder views, that’s what we look for. That’s one of the things on our checklist. And something that I found really useful is creating a pull request template. So you can go into Github, assuming you’re using Github, and create a file called pull-request-template.md. And then, every single time somebody generates a pull request,     that template would populate the pull request. So what we’ve done is we’ve created a checklist that contains about 12 different things that we look for in a code review, things like, “Hey, if you created new components, you should have a test for each one of those components.” Your components’ file names should start with an uppercase character. We look for, “Hey, is there a ticket open that’s tied to this work?” All the sorts of basics that are easy to forget, and of course, one of those other things would be, “Have you reviewed the documentation to make sure that it’s rendering appropriately, that  it still represents the real world, that those comments are updated?” Because you’re right, if it’s not on your checklist, it probably won’t get done. It’s really easy to overlook. CHARLES: Yeah, I think that’s really the answer to a lot of the other problems that we run into in software in general. And I think that’s also ties into the conversation about documentation because documentation is one of the things that sort of gets ignored a lot of times. I feel like process… just having a process, standard process, it’s more important for us that you follow the process than that you get it done. Right? But if you have these processes in place and this is the expectation that you’re going to do things this way, it makes a lot easier. In some cases, especially on open-source is well, like, I just want to deliver the function. I didn’t want to do the other things. But if you just make that part of the over-all process for doing it, yeah, it makes a lot of sense to just, “Okay, here you go. You’re going to commit this. Did you do everything that you had to do in order to make it a proper commit?” CORY: Right. The other thing that we’ve done that is really useful, when you’re thinking about reusable components, it’s very helpful to have your documentation effectively be your development environment. So when we create React components, the first thing we do is say npm-start. What that does is it loads up our documentation site. So the assumption is if I’m working on, say, a text input component, I’m going to collect on the text input component within my documentation site. And now, I’m seeing a live view of my documentation, showing different examples of that text input working. So every time that I go over and I make a code change, and I hit save, my documentation instantly hot reloads that change. In that way, you’re helping keep your documentation very front of mind. And that helps avoid that out-of-date problem that can often happen. CHARLES: Yup. That makes sense. Now, one other part of your background that I want to dig into here a little bit is you mentioned that you worked on projects that kind of went from…. Well, not kind of, they did, they went from Knockout to Angular to React. So what is it about React that made you go, “Oh, this is the stuff right here instead of Angular or Knockout or Vue or Ember or…” Man, I could go on and on with all of the frameworks. But what is it about React that is the big pay-off for you? CORY: So I can sum up why React in a single sentence, which is that, “In React, your HTML sits within JavaScript.” And that is the only library that I’ve found that has this model. Now, what I just described would sound like a horrible thing to a large group of people. Frankly, every time that I introduce React to people, I expect them to have this visual reaction early on of saying, “Why in the world would you want to mix your HTML and your JavaScript?” Well, at first that sounds awful but in fact, all these years, what I see as a common problem right now is people thinking in terms of separating concerns based on file type, based on technology. And React doesn’t make me think that way. React makes you think about separating concerns in terms of components. And I believe that components are the future. I say that because you look out across any industry that’s gotten mature, and the way that they’ve matured is by creating higher and higher level reusable components. You look at an automotive manufacture. They’re not out there thinking in terms of nuts and bolts. They’re sourcing large assemblies. They’re saying, for instance, you’ll get Nissan. Nissan doesn’t go in and deal with transistors and capacitors to be able to build a CD player. They say, “Hey, Bose, send us a head unit that has all of this in one big package.” That is a reusable component. In fact, they’ll take that one stereo. They’ll pop that stereo into a multiple models. And what gets me excited is we’re at this point today as front-end developers, in my job, we’re continuing to create higher level reusable components. We started out at the simple things like saying, “You know what, and the way that we do forms is completely redundant.” We know that there’s going to be a label above the input. We know that if the input is required on a form, then we should display a red asterisk for it. We know that there should be an error that displays right below that form input. So all of those opinions shouldn’t be something that resides in someone’s head. They should be something that is encapsulated within a reusable component. So nobody has to remember any of those things. In fact, on our team, we don’t allow anybody to use a plain label. We don’t allow anybody to use a plain input tag because we have a higher level abstraction called the text input that bundles all that together in an opinionated way that makes sure everyone of our form elements looks the same, operates the same, has baked in validation right there. So no one can really make that mistake. That’s what really gets me excited about. This component model that React provides is being able to think of my application as a lot of different nested components. And now, given, you can create components in Vue. You can create components in Angular. You can create components in Ember. But the thing that makes React special to me and the thing that I believe other people should start copying is this idea of co-mingling your mark-up and your JavaScript using something like JSX.  Because when I say that Reacts put your HTML and JavaScript together, you’re not actually writing HTML. You’re writing JSX, which is in fact, just sugar that de-sugars down to plain JavaScript calls. And JavaScript calls to react.createElement() and it ultimately creates that HTML on the browser. And that little change is why React is fundamentally simpler to learn than something like Angular or Knockout or Vue because in React, if I want to map over an array of values, I just use JavaScript’s map. In React, if I want to conditionally say, if this, then, this, then, I literally use JavaScript’s ‘if’ keyword. Whereas, if I were in Angular, for instance, I would say ‘ng-if.’ In Knockout, I would say ‘data-if’. These sorts of things… so what you realize is almost every time that you’re working in React and you need to do something, you just use JavaScript. You don’t have to learn any special frameworks’ specific way of doing these things. That’s why I found… I can teach a team React in less than a day. And I’ve successful than that. I was just in London a couple of weeks ago, and we started it 9 in the morning, at 2 in the afternoon, I said, “Okay, big announcement, everybody. Congratulations, you now know React.” And that’s pretty awesome to be able to say that in a short amount of time. Now, given, I’m not saying they’re expert, but that small API means that there’s just not much surface area for me to cover for you to know the basics to build a real app. CHARLES: Yeah, that makes sense. I can tell you in Angular 2 and 4, things have move a lot in the direction that you’re talking about. But yeah, it’s actually really nice to have the exact capabilities that you’re talking about. In some of these cases, and things close to it in other cases, as I’ve kind to come into learning Angular better. But yeah, React is definitely on my list of things to learn. Again, it comes back to our conversation earlier about, “Hey, look. Stick with what you know but then, go find out what else is out there.” The other thing is there’s just again, you know, these components map across all kinds of technologies. React Native, for example, it’s the same idea except it’s not HTML. You know, I mean that kind of thing is really exciting to see as far as where we’re headed. CORY: I agree. CHARLES: The last thing that we’re going to do talk about here is picks.[Music]__[This episode is sponsored by Newbie Remote Conf. Newbie Remote Conf is a 2-day completely virtual conference hosted by, none other than, Charles Max Wood. If travel expenses are an issue where you just can't afford to be away from home for 2 days. Then, join us! It’s virtual. This conference is focused on people who are new to programming who want to learn what the pros know, or just get a leg up, and getting a job, and getting into the programming community. We will have speakers from all over the programming community to help you stay current in a Slack room where you can connect with speakers and other attendees in real-time. We’ll also have a live roundtable video chat for attendees and speakers. Plus, we’ll provide the top recordings to you within days from the conference.] CHARLES: You have some picks for us? CORY: Yeah, so I guess my first pick would be, if you’re interested in React, go out and check out Pluralsight. I have three courses out there. There’s soon to be another one on reusable React components. It should be live but I imagine by the time you publish this, since, it’s supposed to be a live the next few days. And I really appreciate feedback. I’ve really enjoyed doing these courses. It’s a huge amount of work but also a lot of fun. The other pick that I’ll put in. And this may have been a pick of mine in JS Jabber but it’s a book that’s so good I’ve been re-reading it recently – a book called Essentialism. Any JavaScript developer should read this because we’re living in a world where there’s too much to keep track of. And as you’re plugging my courses, knowing full well that there’s a ton of other ways that you can go learn these things, and frankly, the harder decision you have to make is what to I want to pay attention to. And I love the Essentialism. This whole book is about recognizing that if you don’t set your priorities, someone else will set them for you. You need to be very, very careful about what you think matters. And have a real sense of clarity about what your values are in a world where you’re incessantly bombarded with opportunities to watch something new or read something new. CHARLES: Yup. I’m just going to piggyback on that a little bit. I have a section in my Get a Better Job course that should be released pretty soon as well. That’s about keeping current because I get asked that all the time. How do I keep current? Or I’m trying to find a new job. I want to stay current so that I can find a new job if I need one. How do I keep up on things? How do I know what to look at when there’s so many things coming out? Yeah, it’s an approach just like what you’re saying. It’s like, “Well, look. Where do you want to wind up? What are the outcomes you want to have?” And then, from there, you can start saying, “Okay, well, I don’t have to care about this. I don’t have to care about that.” This is something that’s interesting. So you prioritize the things that matter and deprioritize the other things so that the most important things are the things that go to the top. And then, you pick up that priority and go for it. Yeah. CORY: So where’s your course? You say it was on YouTube? CHARLES: So it’s getacoderjob.com. And people can go and sign up for the mailing list and get information as to when it comes out. I’m probably going to open it up for another handful of people to get in on the beta, which means I can get it for like half price or better. And that’s just based on, I have the videos up. As we speak, I have most of the videos up. By the time it goes up, I have all the videos up and I’m just fine-tuning the course. So I’d like a little bit more feedback than what I’m getting. CORY: Good stuff. CHARLES: Yeah, so there’s a lot of stuff there. And then, since this is my Angular Story and we talked a little bit about React. I’m putting on Angular Remote Conf and that’s going to be in August. So if you’re interested in that, go sign up. We should have speakers listed pretty soon here. One other thing is that I’m working on… pulling things together for kick-starter for a React podcast. Now, this isn’t something that I necessarily would be a co-host on but I have a lot of people asking for it. It seems like if I… how do I put it? Am animating force behind it and get people involved, you know. So I get the whole stuff out there, help us get a schedule together. Help them start finding guests. And then, just handle all the production in the back-end and hosting. It makes it a lot easier to get something off the ground. Keep an eye for that. I’ll have a link to it for the show notes when I have it up. CORY: Awesome. I’m glad to hear that. If nothing else, it’d be definitely something I would be listening to. CHARLES: Yup. Alright, well, if people want to see what you’re up to, you know, keep tabs on what you’re talking about, or anything like that, where do they go, Cory? CORY: You’re going to find me on Twitter @housecor. I tweet about JavaScript, React, and general software development pretty darn consistently. I’m on their way so often. So that’s where to find me. CHARLES: Awesome. Well, we’ll go ahead and wrap this one up. Thank you for coming. CORY: Thanks for having me, Chuck. This was fun. CHARLES: Alright, well. We’ll have another episode up for you all next week.[Bandwidth for this segment is provided by Cachefly, the world's fastest CDN. To view your content fast with Cachefly, visit cachefly.com to learn more.]

Sign up for the Newsletter

Join our newsletter and get updates in your inbox. We won’t spam you and we respect your privacy.