008 - Why you should (or shouldn't) use React

React is really popular, but is it the right choice for your team?

Pluralsight author Cory House tackled this topic in a recent webinar which we’re sharing via this episode. Cory dives into the many upsides, and some of the downsides, that you should weigh when considering React.

• Full webinar link
• Create React App
• Cory's Puralsight courses
• @housecor on Twitter

If you enjoy this episode, please consider leaving a review on Apple Podcasts or wherever you listen.

Please send any questions or comments to podcast@pluralsight.com.

Daniel:
Hello and welcome to All Hands on Tech where today's leaders talk tomorrow's technology. Today we bring you the audio from a recent webinar by Pluralsight author Corey House. Corey dives into the many upsides and some of the downsides that your team should weigh when considering React. This audio has been edited slightly for an optimal listening experience. If you're interested in watching the full video version of the webinar, there's a link in the show notes. All right, please enjoy.

Cory House:
All right, well let's dive in. We're going to talk about why your team should or perhaps should not use React. So I'm going to do my best to be fair about this conversation. So that said, I'll be candid. I do love React. I've been working in React since it was open sourced years ago. Before React, I worked in angular before that knockout, before that J query and before that just plain old JavaScript. I've been writing JavaScript since the late 90's, so a lot of years of experience here, and that's part of why React got me excited is because it changed the paradigm of the way that I thought about writing front end applications. So our plan for today is three things in the next hour. We're going to talk about why React is so popular and why it might be a good choice for you. We're going to talk about the trade offs that may be made in its design.

Cory House:
There's some benefits and some downsides to any of those decisions. And then finally we're going to talk about why you might not want to use React, common concerns that come up. That may mean that it's not a good choice for you. So let's dive in. We're going to start with why React and for that conversation there's a number of reasons. There's flexibility, developer experience, corporate investment, community support, performance and testability. So let's talk about each of these a little bit more.

Cory House:
First, let's talk about flexibility. When we think about flexibility, there's this spectrum that you could consider in flexibility and as opinion goes up, flexibility to some degree goes down. Ember, for instance, is known for being a very opinionated framework that says exactly where you should put files, how you should handle riot routing and so on. Whereas React, on the other hand, is very much on the other side of the opinion scale where it says, well, here's how you create reusable components, but you can decide how to handle routing. You could decide how to handle testing, you can decide how to handle your folder structures, all sorts of other things like that. So depending on what type of a dev environment you want, you may see this as a good thing or a bad thing. Reacts flexibility could be a feature or a bug depending on your priorities.

Cory House:
Now, because React isn't too opinionated, it also can be used all over the place. You can use React to build web applications, that's where it got started. But you could also build a blog or any other static site using tools like Gatsby. You can build mobile apps using React native. You could even build desktop apps using tools like Electron. You could server render your React apps using libraries like Next and you could even build virtual reality apps using React VR. So the idea with React is that you could learn it once and then write it everywhere.

Cory House:
Now there's a number of different React renders, as well. When React first came out, it only rendered to the web but they quickly realized that the component model that's built into React would be useful elsewhere. So they created React Native and by they, I mean Facebook. React is a project from Facebook that started out to solve Facebook's problem on scaling facebook.com. There are also renders out there again for React VR. There's a number of other interesting renders. In fact, you could even render React to the command line, oddly. I mentioned earlier server-side renderings an option and these are a number of different libraries or frameworks that you might find useful to use along with React for handling server side rendering.

Cory House:
Another thing that you'll commonly see people do is take React and sort of sprinkle it on their existing application. Imagine that I was going to build pluralsight.com and it was currently written in some server-side oriented environment and we decided, okay, instead of having a server side oriented framework, let's start replacing pieces of the page with React. So I could replace just this little star component and later I could create a component that would replace each course list and this item.

Cory House:
Eventually later I could end up replacing this entire page using React and the pattern that I've just described there, is exactly how Facebook slowly transitioned from server rendered PHP over to client side rendered React. You take a piece at a time and you slowly sort of draw larger boxes until you've replaced the entire page. Now another benefit with React is broad browser support. It runs on all major browsers, runs back to older versions of IE, as well. And in fact this is one of those things that you can trust will remain because since facebook.com heavily uses React, they also have to make sure that they're supporting all major browsers, even a small percentage of people using some older browser. There's a large number of potential users for Facebook. So they believe strongly in continuing their broad browser support for React. Okay, so that was benefit one.

Cory House:
Benefit two is the developer experience. I've been working in React a lot of years and one thing that I've found is I hardly ever look at the docs. I occasionally go back and read them just as a way to see what new insights they have and as new features come out. But I don't find that I need to reference the docs because the React API is not very large. The API more or less fits in my head. So thinking about the alternatives to React, it's helpful to think about Reacts mindset versus the competitors. So many of Reacts competitors have a JS and HTML design and by that I mean you end up enhancing HTML by adding a custom syntax to it. So for instance, in angular, I could say in NG4 to iterate over users. In view, I could say V-4 or in Ember, I could use pound each user and users.

Cory House:
Whereas in React I have the opposite mindset. It is a 180 degrees shift here to instead think about enhancing JavaScript to handle HTML. So the advantage of this approach is, I don't have to learn some new syntax, I can use builtin JavaScript features to iterate over an array. Map is built into JavaScript so I didn't have to learn anything new, I didn't have to use some special syntax that's specific to one framework. And with React I also tend to use tools like create React app, create React app is the most popular way to do React development today, but there's many other tools out there. This is supported by the Facebook team and has over 54,000 stars now, so quite popular. You'll also find various ways that you could interact with React online where you could create your own little React application on a website by going to tools like codesandbox.io and then you can share your work with others and have a rapid feedback dev environment as you see the results over on the right hand side as you iterate on the left. This is a fun way to get more comfortable with React.

Cory House:
A third advantage to React is corporate investment. As I mentioned before, Facebook created React years ago. In fact, React, although today it is quite popular, it's been around for a long time. In fact, it was way back in 2011 when Facebook created React and they didn't open source it until 2013, after they had used it on Instagram and on facebook.com. By 2014, it had started to become quite popular. By 2015, they released React Native. 2016 was a big release and also it was significant because that was the point where they turned from naming their releases .14, .13, .12, previously, to fully honoring semantic versioning because they wanted to reflect that React was truly mature. So React went from .14 to version 15, which is an odd history in the numbering, but now reflects its maturity.

Cory House:
And today there is a full time staff of developers that work on React every day and that's something that makes React quite unique. Many of its competitors don't have full time developers. They're traditional open source projects that are worked on by people in their spare time and when you look at the React team, it has shifted over time, but they all have a huge commitment to the project. They blog regularly. They also publish code mods which allow you to easily change your code to work with the latest version of React. So when React releases a new version, you don't have to manually update. If there's a breaking change, you can run a command line that goes through your code base and updates it for you.

Cory House:
And this is essential because since Facebook heavily uses React and created React in the first place to solve their own problems today they use over 50,000 React components in production. So they are heavily committed to the project and also therefore committed to not making big breaking changes that might make your life difficult later. They need to provide things like the code mods that I just showed you because they certainly don't want to have to go through 50,000 components and make manual changes that just doesn't scale. The fourth benefit of React is its community. React is in the top five most starred repos on get hub. There's over 2 million repos out there and React is up there in the top five so we're looking at almost 140,000 stars. It's downloaded over 6.6 million times every single week. That number is crazy. Laurie Voss, who was the co founder of NPM recently announced that over 60% of NPM users are using React and it's not just that a lot of people are using it.

Cory House:
It's also that the people who are using it are very happy with it. If you're looking for support, there's a number of interesting options out there to React to flux as a chat community that's very active where you can get rapid feedback. If you go out to stack overflow.com you'll find over 160,000 answers that are tagged React JS and another 60,000 on React native and another 12,000 on Redux, another 10,000 on React router. So so much of this has already been well tread where it's very easy to get an answer your question, so this is exciting. As a developer you can just go copy and paste most of your problems from stack overflow. It's hilarious how often I find something on stack overflow that really is solving exactly what I was looking for because when you have this many developers working in a technology, the problems that you're solving tend to already have been solved by someone else so you can stand on the shoulders of giants and move very quickly, especially in the form of finding existing components and reusing those.

Cory House:
And this has led to a huge number of companies that you've likely heard of and respect who use React on a day to day basis. This commitment has also led to a very robust list of reusable components out there in the real world. Microsoft has invested heavily in fabric, which is a library of reusable components, material UI, which is implements Google's material design is quite popular as well. React bootstrap, which gives you React components that work with the bootstrap library and give you various themes. On top of that and then you can go out to URL like awesome React where you can see literally hundreds and hundreds of reusable components that people have created and shared. You can see the entire ecosystem, find routers and find different tools for handling immutable data structures for handling state management and so on. The Reacts ecosystem has lots of big names that you might have heard of like React router and Redux, but other interesting projects like mob X for state management just for automated testing, graph QL for API APIs and next JS for server rendering.

Cory House:
So when you look at these stats, yeah, it's clear the community is second to none. And when I go to choose a React framework, community is a big piece of it. And I say there's a lot of other good options out there in JavaScript, but part of the reason so many people are coalescing on React is the community is massive and that gives you the opportunity to stand on the shoulders of a lot of other giants. Benefit number five is performance. When React came out. Performance helped set it apart because what they realized was JavaScript has had this unfair reputation of being slow for a long time when in fact it's not JavaScript, it's slow, it's the Dom that is slow. So React had this idea of what if we could minimize Dom changes and React does that by using a virtual Dom behind the scenes.

Cory House:
So without a virtual Dom, you could imagine that a library would blindly update the Dom with new state. Imagine I have, it's this table with a thousand rows in it and if I remove row 500 then a naive implementation would end up re rendering that whole table because that array now has one less element in it. When in fact React would say, okay, I'm going to update the Dom in the most efficient way instead, and there's a lot of benefits to this. This avoids layout thresh, it saves battery and CPU and it enables a very simple programming model because I know that when my state changes React, we'll redraw the screen. This is an interesting contrast to the days of J query where I would have to be careful to update the screen anytime the data changed. I had was responsible for having to keep those two in sync and React.

Cory House:
I changed state and then I trust React to re render as necessary. So React is not the fastest framework out there. There are lots of very fast framework. It's these days, but it does benchmark quite well against its competition. React is also quite small. A minified in Jesus, it's about 32 K but if that's not small enough for you, there's even an alternative to React called PReact, which weighs a whopping 3K, just 3K and it has most of React same API, but it eliminates just a few features to get the size way down. So if you care deeply about your initial page load and time to interactivity, then it may be worth considering. PReact. The nice thing about PReact is if you understand React, you can very quickly pivot over to PReact, but in most cases I find teams end up reaching for React because the size is quite reasonable.

Cory House:
Benefit. Number six is testability. React is friendly to automated testing because many of the components that you create are pure functions. A pure function is a function that returns the same output for a given input. It doesn't mutate its inputs, so you think about that component that I showed earlier that displayed a hello world. That was a pure function because if I pass the word Corey in, it would always return hello Corey, and when you have components that return certain HTML for a given set of inputs, you can write an automated test for that without having to do mocking or stubbing, and it is deterministic. It will always output the same results. When you think about traditional UI tests, they tend to be a hassle to set up, whereas if you're working in React and especially with create React app, automated tests work out of the box, you don't have to do any extra configuration.

Cory House:
Often UI tests require a browser, whereas with React you can run unit tests and memory via node. Traditional UI tests can be slower, but with React they tend to be quite fast. Often UI tests end up being brittle, but if you are testing single React components in isolation and they're going to be reliable and deterministic because you're testing pure functions, traditional end to end UI tests can be time consuming to write and maintain. But if you are doing unit tests on React, then you can write those quickly and update easily. Now that's it. I tend to do integration tests with React as well. I'm a big fan of Cyprus so I end up putting a little bit of extra time. I do both unit testing and integration testing and I suggest that to most React teams, but you can find that if you go create a new app using create React app, you can be writing tests immediately.

Cory House:
Create a file that ends in dot test dot JS and start making your assertions. You don't have to configure it, it will find those tests for you. So with React, the majority of your components can just be plain pure functions, as I've talked about before. So this is a pure function which makes it reliable, it's deterministic and it has no side effects. It doesn't change any outside state. Now there's a number of testing frameworks out there, mocha Jasmine, tape, Q unit. Ava just just is my preference and for what it's worth. I've used all of these in the past and been happy with them, but just as my current favorite. One thing that sets just apart on this list is just has a full time staff at Facebook and just also is bundled into create React app, which is pretty nice as well, so you don't have to do any extra configuration.

Cory House:
Now it's interesting though, when Jeff first came out, it wasn't particularly popular. People didn't like it much because it mocked everything by default, which ended up being a rather unpopular default, but that was why it was called just at first. Now today they've pivoted away from that. It has a very traditional behavior and I'm a big fan of it because it's configured in create React app and gives you a nice command line interface for running tests. You'll also likely want to add some libraries on top Airbnb popularized enzyme, which I used to use heavily, but honestly today I recommend using React testing library a, despite the name. This is not actually associated with React, but it's a wonderful library that's very opinionated. It has a small API and it helps encourage writing your automated tests in a way that is less brittle because it focuses on the user's interactions.

Cory House:
So what you'll see is these are pretty easy to configure and get started because React itself is designed in such a way that it's friendly to testing. Okay. So we just looked at a lot of reasons that you might enjoy working in React. It's very flexible. The dev experience is excellent. There's a huge amount of corporate investment that sets it apart among its peers. The community is second to none. Performance is very good out of the box. And then, although I didn't share it, there's a number of ways to enhance performance with special features that are built into to React when it's necessary. I very rarely find those necessary, but it is nice knowing that they're there. And finally as we just discussed, it is quite testable. Especially if you write your components as pure functions, which many of your components end up being pure functions as you build your app.

Cory House:
So that was the good stuff. Now let's shift over to talk about the trade offs that are inherent and Reacts design. Now I enjoy React but I admit what I've done so far has been a pretty one sided sale pitch. So let's look at these trade offs here. Framework versus library, concise versus explicit templates centric versus JavaScript centric. Separate templates versus single files standards versus non standards, community backed versus corporate backed. These are the inherent trade offs that are made within Reacts design. So depending on your priorities you may see these as good or bad. So let's talk about framework versus library. This is the first trade off inherent in its design. Ember and angular are well known frameworks and there are some benefits to using a framework because they have clear decisions, clear opinions. This means that you have less decision fatigue if you choose one of these.

Cory House:
There tends to be less set up overhead to get a real application going and they help enforce cross team consistency, so lots of wins with choosing a framework. Now on the library side since Reacts a library, it's lighter weight and you can also mix it into existing apps. The reason that React is designed this way is because Facebook wanted to be able to slowly pivot existing technologies that were server rendered over to doing client rendered with React and I find many of my clients do just that. You also get to pick what you need so you think about if I'm going to work in React, I can choose the router that I want. I can choose the HTTP library that I choose to use and the automated testing library and the folder structures. These are my decisions. That also means that I get to choose the best tech for the moment.

Cory House:
Sometimes the best library for a given day changes over time and you're free to pivot to that new thing because it's not baked into the framework. Also, many popular boiler plates exist. The most noteworthy being create React app, which ends up shifting React a little bit more toward a framework rather than merely a library. Now, one of the primary benefits of React being a library is I could have this existing app that might be built today and.net Java, Ruby, PHP, Python, whatever, but I could slowly replace that app with React by coming in and replacing a little box at a time and I can do that with React because it's small and it is composable. Eventually I end up with an app that's completely React and again, this is what Facebook did, but you could think about the features that exist in angular versus React. They both handle components but React doesn't include opinions on testing or HTTP libraries or routing or internationalization animation form validation.

Cory House:
These are all up to you now that said, good options exist out there and popular options. I find that I enjoy being able to make these decisions, but if you want all of these decisions made for you, Ember, angular are two examples of more opinionated frameworks that you might prefer. Instead again, create React app includes some of the opinions that I just showed over there in the box and if you're looking for other options, recognize that for React there are about 200 different boiler plates out there on get hub. This URL ends up listing all those boiler plates and explaining when they might be useful. So for instance, if you want to do server rendered apps, then next JS or Gatsby make that easy trade off. Number two is concise versus explicit. Now React trades being concise for being explicit. An example of this is two way binding.

Cory House:
Imagine that I have a variable that holds a username and an input. Well with two way binding. These would be magically kept in sync. This was a pattern that was popularized by knockout and angular and it's was popular because there is less coding involved in it's automatic. Whereas in one way binding I have to have an explicit change handler to handle that change. So notice that the on change down there on that input. Then I have to wire that up and depending on your priorities, you may see this as a step forward or a step backward. I do have more control but I also had to write a little bit more code. It's more explicit though. So there are some advantages there. It does give me more power and it's easy to deep bug. So some trade offs to consider here. Now that said you can do two way binding with React but it's not typically popular and also don't worry, you don't have to declare one change handler per input.

Cory House:
You can declare one perform. They tend to often be pretty similar so it's not actually that much work to get this pulled together. Trade off. Number three is being templates centric versus JavaScript centric. Angular view and Ember tend to be more template centric and that means that you need to learn their unique syntax, whereas React expects you to know JavaScript well. So if you have a team that is relatively new to JavaScript, React can be more intimidating because there's an expectation that you have more knowledge about modern JavaScript to work in React. Then in some of its competitors. The nice thing about templates centric is you don't have to know as much about JavaScript. It can avoid confusion about JavaScript binding and it also honors the rule of least power, which says if you give me less power than I also have more control to potentially compile those templates and add logic around those templates to provide good support for air messaging and potentially auto complete as well.

Cory House:
Angular is a good example how their story has continued to get better over time in their templates centric approach. So there's certainly some merits to this side. In contrast, React is JavaScript centric, so that has its own advantages which is there is less framework specific syntax, fewer concepts to learn because it's just JavaScript. If you know JavaScript well then, in my experience, you can pick up React very quickly because at its core, React is mostly JavaScript. And that tends to mean that you write less code and your code is pretty easy to read if you didn't know React. But I showed you some React components, you could probably understand what they're doing because as long as you know JavaScript, you could figure out, okay, here's a logical land operator. I know how that is parsed. Here's a ternary, here's an if statement, and so on.

Cory House:
And the benefit is this tends to encourage improving JavaScript skills, which is great because we all know that although React is really popular now, at some point something will come along and dethrone React and we'll all move over to it instead. But chances are JavaScript is going to be around for many, many years to come. So getting good at JavaScript will likely transfer to whatever that new hot thing is when it arrives. So that means if you work in React, you get really comfortable with using modules and let and const object literals, default parameters, template strings, classes, arrow functions, promises, destructuring, the spread operator. These are all excellent JavaScript features that have been added since 2015 and if you get good at these, you'll find that any JavaScript that you write will end up being easier to use because of these modern features. And React encourages you to get better at these because of its JavaScript centric approach.

Cory House:
So your skills will transfer to whatever that new thing is down the road. So another trade off having a separate template versus having a single file. So NBC is a pattern that's been around for a lot of years. It stands for model view controller and it was a popular way for handling, especially server-side rendered apps for many years. Now React came along and popularize the idea of having a single component that contains both your logic and JavaScript and your markup in JSX. Again, JSX is basically HTML just with a few minor tweaks and remember that that JSX compiles down to JavaScript functions that render HTML. But when React first came out, this idea of mixing your JavaScript with your markup was quite controversial and people thought twice about this whole idea. This was back in 2013 you're going where you're at to rethink this established best practice of having separation between your HTML and your JavaScript.

Cory House:
But in my opinion, we need to rethink the way that we described separation of concerns for many years. We thought about separation of concerns in terms of technologies, and the thing is HTML, JavaScript and CSS are most certainly separate technologies, but they are fundamentally intertwined because for me to create, say a date picker, I have to write some HTML and some JavaScript and some CSS and those all have to be written together in a very specific way so that it works successfully. So my real concern is the button that eight picker, the accordion, the text input, each component in my application is truly my concern. So if I happen to put those technologies together in a file that there are benefits to that because now I have co located my concerns. I even get auto-complete support in my JSX if I'm calling some function in that same file because my editor knows that it's in scope.

Cory House:
So there are benefits to commingling these technologies since those technologies have to move together to be able to create the user experience that I desire. So React pivots your idea about separation of concerns from technology to component. The component is your concern that you want to separate and in React. We nest our components much like the Russian doll model where you can have one component that ends up getting composed together with a few other components to create a larger portion of the screen. So we can have this page from Pluralsight where I have a star rating component or an author photo component. These are very simple as as a nav link component, but I could put those together with a few others and create larger components like a course summary or an author summary or a sidebar navigation. I could go even higher and create a component called author courses that composes those lower level components that I mentioned earlier.

Cory House:
And when you see this all together, you can see how your page ends up getting composed of small components placed together and then slowly creating the entire page. So when you do React development, you can start out small and then take those building blocks and put them together. I like to think about working in React a lot like playing with Legos that I end up building something big by taking small pieces of Legos and connecting them. Trade off number five is standard versus nonstandard. Now when we talk about standards, there are a lot of popular nonstandard approaches to components today, but the web components standard, which you might have heard of, hasn't been around for a while. And what it seeks to do is standardize the way that we create reusable components for the web and it gives you templates and custom elements and shadow Dom and imports.

Cory House:
In fact, I have a whole course out on Pluralsight on HTML five web component fundamentals. I published this course a few years ago and I was really excited about finally having a standard because I thought it'd be nice if all of us developers could share each other's components and not have to have these separate fiefdoms of React versus angular versus view and so on. But I've come to realize that the platform isn't my preference, that I actually do prefer writing, working in React instead. And there's a few reasons why the browser support continues to be rather spotty. So you have to add in polyfills you look at HTML templates, imports, shadow Dom, all of these have a lot of red when you go out to caniuse.com, and the thing is these are not new standards. They've been around for years. So it's disappointing that browsers haven't embraced these standards as quickly as we might hope and web components.

Cory House:
The standard actually does not enable anything new. We can get the same things done today in angular or Vue or Ember, and in fact the developer experience tends to be preferable. For instance, if I wanted to do templates which are offered in web components, well React offers that in JSX. If I want to do custom elements, then I can declare React components. They work the same way. If I want to do shadow Dom, there's a number of approaches in React for handling encapsulated styles like CSS modules or CSS and JavaScript. I don't need to worry about imports because with React I have one component per file and my bundler handles that. Also, JS libraries continue to innovate, because of that, web components have a hard time keeping up since it is a web standard and those web standards tend to move more slowly. Finally, web components only run in the browser, whereas React components run in a variety of different places.

Cory House:
So if you really do believe in this standard, you can certainly consider web components, but recognize that you're probably going to have an inferior developer experience to angular, Ember view or React. They all continue to move forward while the standard has lagged behind, and this is why even today when I go to conferences, I rarely find people that are using standard web components. The sixth trade off is community versus corporate backing. For better or worse, React is backed by Facebook, which means it is driven by Facebook's needs, but there's some good things to that. It means that it also has a full time staff and over a thousand contributors. Facebook's the world's fifth most valuable company and there are over 50,000 components in production. So I find the corporate backing a net win because they tend to be doing a lot of the same things that most web applications do today.

Cory House:
All right, so we just talked about a number of different trade offs here and to wrap things up, I want to talk about why not React. We're going to talk about some common reasons that people might have concerns in considering React. The first and probably most common is that JSX is not HTML. I showed JSX earlier here that when I write JSX it compiles down to calls to React dot create element. Now in actuality, the difference between a JSX and HTML is quite small. I can share it for you in about 30 seconds. Instead of saying four, I say HTML four instead of using the class attribute, I say class name. If I'm going to do styles, I declare those styles as if I want to do inline styles. I should say I declare that as an object instead of as a string and if I'm going to do a comment, I use this block style comment instead.

Cory House:
So it's a pretty short list. I have found that designers can very quickly feel comfortable working in JSX because it feels nearly identical to working in HTML. Now you might be worried that you have a lot of existing HTML that you'd have to convert. Well, there's a number of existing converters out there to choose from and these compilers are also a nice way to learn JSX on your own. So in actuality, I haven't found the JSX piece to be a particular concern for working in React. Number two. There is a build step required because what I just showed right here, I can't send that code up above to the browser. I have to send the code below because the browser doesn't know what to do with JSX. It knows how to handle JavaScript functions though, but the fact is in modern JavaScript apps you tend to to build step anyway because you want to minify your code, you want to trans pile it so you can run the latest versions.

Cory House:
You may want to run your tests and run linting so you tend to need a build step either way and benefit from it. There's a couple of popular trans pilers for JSX, a Babel and TypeScript, although now I really should update because Babel does trans pile TypeScript and then that way you don't even really use the native TypeScript compiler anymore. To clarify, TypeScript is just an option. Lots of React developers use just plain JavaScript. You can use a babble to compile your JavaScript down and your JSX down, as well. Create React app comes with support in the box or compiling your JSX so it's no extra work for you to handle that conversion. The third concern is version conflicts and this one is certainly valid. If you have multiple versions of React on the page, that's a problem. Since React has a single runtime, you do have the risk of version conflicts.

Cory House:
If you're sharing React components across teams, that means that you need to choose a single version. If you contrast that with web components for instance, there is no runtime so you don't have to worry about version conflicts and you could also look into interesting alternatives like spelt or skate that have a built in run time and in that way you don't have to worry about versioning either. Version compatibility also comes in when you're looking at React libraries that you might add on because you think about, okay, React router for instance, while the latest version requires me to be on React 16 so if I have some app that's using an older version, I can't use that latest version of React router. Anytime you have this runtime dependency I should say, then this becomes a concern. So there are various ways to avoid conflict. So you could run a code mod that will help you get your app to the latest version.

Cory House:
So in my experience, most of my clients end up running the latest version of React because there's not a lot of reasons to avoid it. You can get there usually fairly quickly unless you have some dependency that requires you to be on an old version because that dependency hasn't updated yet. But I recommend standardizing on a new version and then upgrading React when you're upgrading your libraries, but choosing to do so as a team that can help minimize this downside. But this is certainly a downside over using something like native web components. The fourth concern is there's old docs online because React has been around for five years. If you go out here and you search for React example, you'll find that there are hundreds of millions of links out here. You go out to stack overflow and tens of thousands of answers to questions and blog posts on medium.

Cory House:
So it's great that there's lots of resources, but the risk is that some of the content is outdated. So for example, features have been extracted from React core and that means the old code on the left now needs to be the new code on the right. There are various features that have shifted over the years, so you might be looking at an old blog post or an old answer on stack overflow that no longer is quite valid for that. I'd recommend using the React docs, they are excellent, they're well kept up to date, but certainly is a sort of a good problem that React has had so many answers over the years. Yes, you might come across answers that are now outdated as you look through older resources. Concern number five is decision fatigue. As I said earlier, React is not opinionated and so because of that you end up having lots of options.

Cory House:
Depending on your outlook, that could be a good thing or a bad thing. Here's a few of the decisions that you need to make. You need to choose a dev environment, which I alluded to before and there's almost 200 out there on just this one site listed, but my suggestion is use create React app as a starting point. It's popular, it works well. If you're doing a native app, then check out Crick create React native app. In my experience, the vast majority of people start out there and are pretty happy, but as you grow you can look into the alternatives. You need to decide how to handle types React handles types on its own with their library called prop types, but you've likely heard of TypeScript as a way to have types in JavaScript. You need to decide how to handle state management and a state is a way of saying, okay, how are you going to handle your apps data?

Cory House:
My recommendation is to think about all of these as optional because they are, they're not part of React. A really what I would suggest doing is using plain Reacts, start out using React alone and I've built lots of large apps using just plain React, but you can certainly look around at those others if you feel like you've outgrown, just React by itself. You need to choose a styling approach and this is one of those places where things get silly because there's so many options. My suggestion is use what you already know. React does not require you to use a certain styling approach, although it has a builtin styling option using objects that automatically encapsulate your styles. That's one way to go. I'm a big fan of CSS modules, but whatever you're doing today will continue to work in React so you don't actually have to change, so that helps reduce the feeling of decision fatigue that might exist in React.

Cory House:
What I do for a living is transition teams to React. So I am the principal@Reactjazzconsulting.com so I am bed with teams, I train teams and I also help companies shift their existing technologies over to React. That is what keeps me busy. What you just saw here in this webinar is a shortened version of this particular course on Pluralsight which is called React. The big picture. I also have other courses out here on Pluralsight on building apps with React and Redux, creating reusable React components, React and flux, a variety of other React related content. We've got a few minutes left here and I'm going to look over here at questions that have been posted in the go to webinar and then if anybody else has questions you can go ahead and post those in questions there.

Cory House:
Can I do something with angular which I cannot using React? Well that's a good question. You can build native apps with angular and you're going to build native apps with React. You can build VR with React and I assume you could with angular. Nothing immediately comes to mind. I mean I will say this view, angular, React Ember are for mature options and I think you can build excellent apps with any of those four and you probably will be quite happy with any of those too. That's part of why I focus in the middle of this about trade offs and saying, okay, are the trade offs of Reacts approach of having a more library oriented approach versus a framework oriented approach? How does your team feel about that? Do you, do you like having less opinions so that you can choose exactly how to configure your dev environment and which tools you want or do you want something that has more opinion and just says do it this way?

Cory House:
There's no right answer on that contaminant continuum, but Reacts certainly has a preference between the two. I will also say though that this decision of when to use React at all partially comes down to are you in a situation where you're building a mostly static app that could be server rendered that's not particularly interactive. Then React probably doesn't make much sense for you. The place where React is really useful is you're building a application where there's a lot of interactivity where you want to be able to animate between States. You want to handle a client side rendering. You might want to do a progressive web app so that you could have benefits of an application that remains responsive without even having an internet connection for people. So there's a number of things that become possible once you do client side rendering and that's part of why client side rendering has become so popular, but not everybody needs it.

Cory House:
So server side rendering will continue to be relevant and useful and React is very popular, but that's not a good reason to reach for it in and of itself is create React app a good idea for Greenfield enterprise apps? Any downsides to create React app? Yeah, so I would say I recommend that people start out on create React app and recognize that you can customize it all you want because you can run a checked on create React app at which point you have complete control to change the web pack config and the Babel configuration, the ES link configuration, the testing configuration with chest, all of that is in your hands now and also recognize that the code that you've written in your app, you could always pivot to a different dev environment and it should continue to run as long as you configure your own development environment to trans pile your JSX and bundle your app for production.

Cory House:
Some of the same things. So I tend to suggest to people to start out with create React app and then look at potentially customizing create React app using a React app, a rewired, which is a useful library for tweaking it, but longer term, if you're in a larger company. One thing that I do for a lot of companies is help them create basically their own version of create React app where imagine when you run create React app, you say NPX create React app, my new app. Imagine that you could say NPX create my company name app. So if you work for Amazon, imagine you could say NPX create Amazon React app and it would create a React app that has your unique opinions and references to your component libraries, your whole build process, all sorts of unique scripts built in and that can be really useful on larger teams.

Cory House:
Next question, which is simpler if we are using.net and jQuery, angular or React? Well, so that's an interesting question. The fact that you said, if we are using dot net jQuery, I will say if you're working in React, I recommend avoiding having jQuery in your project because if you're someone who's worked in jQuery a long time, and I'm certainly one of those that worked in jQuery a lot of years, but I found early on was I wanted to manipulate the Dom using jQuery because I knew jQuery well and I was still getting used to React. But React has the model that it handles changing the HTML for you. You merely handle changing state. So I don't think there's a good real answer between if you're using.net I will say a lot of people in dot net tend to struggle about the decision between angular and React and that partially comes down to Microsoft seems to have had a lean toward angular and I think that's partially because angular embrace TypeScript heavily too.

Cory House:
And Microsoft wants to see TypeScript succeed, but increasingly I'm seeing people also work with TypeScript in a React as well because it's quite friendly to it, especially in its most recent versions and create React app supports TypeScript out of the box too. Also, the fact that you mentioned.net tells me that you're sort of thinking about how the decision of.net impacts your front end and I would say think about your front end decisions separate from your backend decision. They're two separate decisions and you're back in need, not affect your front end because you think about, regardless of whether you choose angular or React, you need to send some Jason to a server and you need to get Jason back from some server, so if you're in.net you're going to be calling web API most likely or maybe WCF, however you've built your API calls, but that really doesn't impact your front end decision.

Cory House:
Any JavaScript front end can interact with that, Jason back and forth. All right. Another question is React to better fit for micro front ends then angular at all? Well React is to me a little more attractive for micro front ends than angular. Just because React is so small that is probably the single most obvious advantage. React was designed from the beginning to solve exactly that, that sort of micro front end problem of replacing a first component and then slowly moving farther. So yeah, off the cuff I would say that that would probably make me prefer React over angular for that sort of a story. But you can certainly build micro front ends with either purely from a performance perspective for loading large amounts of data which you clearly choose. React versus angular? No, I, I honestly I think either React or angular will do just fine with large data sets.

Cory House:
In fact, when it comes to performance, React and angular are highly comparable as his view. When React first came out it was really fast and that set it apart. But very quickly angular, Ember and view all also became really fast. So at this point I wouldn't choose any of them for performance reasons, they'll all scale well. I would choose them for some of the other reasons I mentioned before of framework versus library of the community support that they have of what gets your developers excited. Kick the tires on a few of them and see how you like how they work. What dev environment do you mostly use? I mostly use create React app. Although I created my own, which is called React Slingshot years ago. Honestly I don't use it anymore though cause create React app is so good. I tend to customize, create React app. I tend to create a mono repo and keep my reusable components in there.

Cory House:
I'm a believer in having a UI front end mono repo that contains all the code. Is it possible to import HTML files using shared static content? Hmm, I'm not quite sure what you mean by that. A shared static content and I'm not sure if in that case you're referencing a particular technology, you can import HTML like for instance with React what you can do is lazy load your components and in that way if somebody doesn't navigate to a given page then that component will never be downloaded by your users. So this is a way to create a really big application that has all these different tabs across the top, but as your app grows, your load doesn't go slower over time because you're only loading that one component. Last question in here, what are the things to consider when migrating from angular with grunt build to a React ecosystem?

Cory House:
Should we immediately get rid of grunt over web pack, et cetera? Ooh, well that's an interesting one. I guess what I would think about is keeping the lights on with both at the same time and I would end up slowly shifting over to a React by saying let's replace one page or if we could, because replacing a page is easier than replacing a portion of a page and I would have the build process for that. Starting out, you might consider using a library out there that creates autonomous React components. There's a few out there worth considering. I don't have time to get into the merits of the different ones, but there are a number of useful libraries for creating autonomous React components where you could say, "Here's this one, I'm going to publish it out and frame it into my existing app." And then longer term, you could even think about having a React app that is slowly replacing that angular app a page at a time, if that's practical instead.

Cory House:
As far as replacing grunt and anguler JS, I would do that with what Martin Fowler calls the strangulation pattern where you say, "We're going to replace one page at a time or even perhaps one component at a time," but you keep both systems running at once so you always have a fail safe if you need to go back to the old world and that's how you slowly end up in the new world where you'd like to be. If you want to reach out to me, I am housecore on Twitter. I'm also the principal@Reactjazzconsulting.com I help teams move to React, so happy to help you there and plenty of courses on Pluralsight. I would say my final takeaway is, I have worked in lots of different JavaScript libraries and technologies, and I have never been happier than working in React. It really is an enjoyable experience, a great community, and just a lot of fun to build apps every day. So if you haven't given it a shot, I'd encourage you to try it out.

Daniel:
Thank you for listening to All Hands on Tech. If you enjoy this podcast, please rate it on your platform of choice. You can see show notes and more info at pluralsight.com/podcast.