Understanding JavaScript Libraries via React... by Andrew Pinkham

So hi, welcome to the last talk of DjangoCon US 2017. You made it, you survived almost. Thank you for coming to listen to me talk. The topic for today is understanding JavaScript via React and the React ecosystem. So uh my name is Andrew Pinkham. I am probably best known as the author of uh Django Unleashed. I'm currently working on a video series based on On the same material with uh Pearson, and hopefully a second edition for Django 111, because the book is in Django 1. 8. Um, by day, I'm a software consultant with Jambon Software. Uh we're currently working with a client on machine learning over high-resolution satellite imagery, which is super interesting, um a little bit outside of what I'm used to doing, but it's nice to get away from Django every once in a while. One of the nice things about being self-directed as a consultant is you get to work on some really, really cool projects.

So at the beginning of the year I started working with Russell Keith McGee. on search cycle. Search cycle is basically a way for automatically installing and monitoring certificates in the cloud, specifically Amazon and Azure. We're gonna be looking for beta testers before the end of the year, so if that sounds even remotely interesting, please come talk to me. But today you're here to talk, you're here to hear me talk um about JavaScript. I had someone mention, oh, you're you're doing the React talk, right? Oh no it's not the React talk. It's the the JavaScript talk. Well that's a little bit of a bait and switch there. I'm really sorry if you showed up here expecting to hear mostly about React. This is mostly going to be about what I learned about JavaScript while programming a React website. This is targeted at devs

who are not particularly familiar with JavaScript. So if you use npm and yarn, I'm really not gonna hold it against you if you get up and you leave. No worries. The talk outline is gonna start with, how did I get here? Right? Like I mostly Python and Django, um, and suddenly I'm doing JavaScript. Like what forces me into Using this language that I have desperately, desperately tried to avoid. We're gonna then jump into sort of a brief a brief history of the web, and then we'll talk about JavaScript, the web frameworks, what the problem is, and then finally react. And sort of React's ecosystem and all the things that we we had to deal with there. This talk is fundamentally incomplete. And I really want to take a moment to focus on this because I'm taking a year of experience

and I'm condensing it into 20 minutes. I simply don't have time to go into all of the details. What I'm hoping for here is to give you all the people who are sort of beginning on their journey and don't have a map. So I'm not gonna give you a very good map, right? It's sort of a medieval map, and you know, here be dragons and there's an island kind of off over this way. But hopefully it's better than starting with nothing at all. So let's talk about how I got here. What started the journey? Well, in early 2016, a client asked me if I knew Django and I kind of said, yeah, I have a uh an inkling of how that thing works. Um and they said, well that's great. We'd like you to program JavaScript on top of the Django app. And I said, no No, no, no, no, no, no, no, that's not how that works.

And they said, no, no, no, no, no, please do it. And I will leave it to your imagination to guess how the rest of that project went. But so as I'm starting this project, this is the to-do list that I set out for myself. You know, oh, learn JavaScript, figure out how it works, and then go build it. Yeah, I forgot the most important part. And the most important part is I didn't understand the problem. I didn't understand fundamentally what the problem that I was trying to solve with the framework and with JavaScript. And this is not a commentary about JavaScript itself, right? This happens with Django. People go, oh yes, I need to build a website, which I didn't use. Oh, you should use Django. What just happened, right? What's actually happened is is a fairly implicit conversation, right?

Someone has actually asked the question, hey, I need to build a software application. that communicates with other computers over HTTP and then is going to serve up HTML and CSS. You know, do you know of any tools that do that? Oh yeah, Django handles all of that. of that you should go use Django. And so I was asking this question like, hey, how do I build a dynamic front end that is going to communicate with an API? Uh oh you should use all of these tools. Well wait, hold on. What am I actually asking when I I ask that question. What is fundamentally the problem that I am trying to solve? Like many things, the problem becomes really, really clear if you start with history. So let's talk about HTML. HTML first appears in 1991 and it is immediately rolled out into the first browser called Mosaic and then quickly implemented in things like Netscape

Navigator and Introductory. Internet Explorer, but lovely, it's all slightly different implementations, just to like really mess with you. HTML is originally intended as a way of sharing scientific document. Right, you want to go ahead and share your scientific research at CERN. So you've got the content, but you also have all of the structure of the document. This is a title, these are the authors, this is the abstract, et cetera, et cetera, et cetera. But that introduces a sort of duality here, right? There is content and structure when you're dealing with with HTML. And I'm going to stretch this analogy. If it's a little bit like Model View Controller, then the content is a little bit like the model, and the structure of the document is a little bit like the view. I realize I'm stretching this. I'm not stretching it too much though, right?

Because CSS doesn't actually get talked about until 1994. The first spec doesn't exist until you know the very end of 1996, until the first spec Time that you're really going to see nine CSS used is in 1997, which is six years after HTML really comes to be. So that's HTML. Let's talk about JavaScript. JavaScript is built in 10 days. It's a glue language in 1995, and it's effectively this sort of collaboration between Sun and Netscape because they're freaking out about internet experience. And so they hired this guy, Brendan Ike, and he wants to put scheme in the browser. The problem is that because of politics, They want to use Java, right? They want to reference Sun's

Java. So they're gonna call it JavaScript, and they need something that looks like object oriented programming. So he goes and he uses prototypal uh pro uh inheritance taken from a programming language called self which looks nothing like Java. It's important. The reason they're building this is because they want to manipulate the DOM, right? The real reason that they're putting this together is they want to be able to change The content in the structure in the HTML. It's also worth noting that this has changed over time, right? The JavaScript that we are currently working with is not the JavaScript that was put together at that point. And so now that we have the history of HTML and of JavaScript, we really understand the core problems here, right?

JavaScript has vocabulary that we think means one thing, and it actually means something completely different. Classes don't mean what you think it means. JavaScript and HTML are implemented slightly differently in all of the browsers, and JavaScript has slightly different features. in each one of these browsers according to its version. The HTML DOM is weird, right? Like it's it's got its own hidden state, even though it's supposed to be the state. And it's got event handling, but it's different across all of the different browsers. And then there's the duality of it, right? Content and structure. So let's go through each one of these problems in this order, right? Let's start with JavaScript. You're not gonna be able to do much about the fact that they use words

and you think it means one thing. And then it means something else. The sad truth is that you simply have to sit down and learn the vocabulary. I found Douglas Crockford's book, JavaScript of the book. the good parts to be incredibly helpful. Eric Elliott's programming JavaScript applications was less about JavaScript and more about the stuff that we're about to talk about, but I wanted to put it all in in one side. And then Kyle Simpson's um you don't know JavaScript is really interesting, not necessarily immediately helpful for the hands-on stuff. If you're not into books like I am, you might want to look at front-end masters and And egghead. io, they have videos that sort of cover the same stuff. So that's JavaScript, the language. Now we can talk about the different versions. I'm gonna skip the fact that it's slightly different in different browsers because it's no longer something that most of us

developers have to worry about, right? jQuery and MooTools originally solved this in the early 2000s, and if you're using a modern framework, um you don't have to worry about it. So let's let's just skip it. You do have to worry about the different language versions. And this is where things begin to get weird, right? Because if you're using Python, you can just decide that you're gonna run CPython 2. 7 or CPython 3. 6, right? You just run it. But you have different browsers and they're all implementing it, so you need a spec. So the spec is ECMAScript and you can propose things via this thing called TC39. I'm actually unclear on what the name is. If you're running in the browser, you expect uh sort of when we started ES3, so uh JavaScript that it

conforms to ECMAScript 3, or JavaScript that conforms to ECMAScript 5. Um I'm just gonna start calling them ECMAScript or ES3, ES5 , in modern browsers. But ECMAScript 6 and most of 7 currently exists. But unlike with Python where you can just be like, oh, we upgraded our code base and now you just have to run it in Python 3 and you're done with it, you don't get to control who's running your JavaScript. You don't get to say Who is it what browser is being used? So the question then becomes, well, hey, can we write in modern JavaScript and then ship older JavaScript? Can we write in ES6 and ship? And the answer is yes, you can compile JavaScript to JavaScript. Um the community has decided that this is called transpilation.

No, I don't know why. No, I'm not asking. Um there is one additional complication uh on top of of transpilation, and it's that ES6 introduces namespaces in modules. As Python people, you look at this and you go, wait, hold on. Import syntax, right? You you import all the time, import X from Y, or simply import Y, right? This is easy. But JavaScript has no knowledge of this in You don't get to use that at all, but you do get to use it in ECMAScript 6. So how do you take all of your different files and namespaces and produce a single file. Well it's called bundling, right? You bundle all these modules, all these namespaces into a single file, which you can then serve up to the browser and run as if it's the old

thing. So let's now talk about transpilers and bundlers and sort of get into it. Transpilers are actually fairly simple, right? It's a compiler and um you just want to If you're starting, just use Babel. There's a really interesting project, uh, if you're curious about all of this called Buble. It's sort of like a performant Babbel. It doesn't do all the things that Babel does, but it has like an Edge, check it out. It's worth noting that you don't have to go from JavaScript to JavaScript. You can also go from TypeScript to JavaScript or CoffeeScript to JavaScript. Um TypeScript's actually really interesting because it's it's Microsoft's product and they introduce static typing into JavaScript. Um we're currently using it at work. I've only used it for Two weeks, so I don't want to say too much about it, but so far

I'm enjoying it. Bundlers are what I found the most confusing. People were just like, oh, use Webpack. Well, what does Webpack do? What is this thing? And the problem is that originally you had two tools. You would take all of your files, you would run it through this pipeline, you do whatever you need to. to it and then you pass it into Browserify and it produces that one single file that you need. Great! Except now you're using like three or four tools to do all the things that you want until Webpack. But that means that Webpack is not only a bundler, it's also your pipeline tool. And then to make matters more confusing, it expects not only to pipeline your JavaScript, it wants your images and your CSS and your HTML and any asset that you are going to serve.

And so the configs are like really, really confusing. Um I want to note very quickly that um webpack is for apps. If you're going to be providing libraries, you want to check out a thing called rollup because you know Do one thing and do one thing well, I guess. Um now speaking of libraries, we haven't really dealt with any of the environment tools. I feel like someone over in the back is looking a little overwhelmed, I'm sorry. Um the the environment tools, right? You're used to pip. You just use pip. Well no, you get a choice. So NPM was king of the hill, but when you install things with NPM, it's actually non-deterministic. So I had people on my team who were seeing one bug, someone else was seeing a different bug, and I wasn't seeing anything. bugs. So we switch to yarn, which installs things deterministically.

Now I'm told that npm has actually fixed this. I don't actually know. I haven't tried it. We've stayed with yarn. I've also heard of this thing PNPM, it's supposed to be more space efficient. Honestly, I don't really know what to tell you on this front. I use yarn, it's great. I, you know, I feel like people could bike shut about this. I'm just gonna keep going. There are linters that should say jslint and js hint. They're the originals and they're they're basically being succeeded by this thing called ESLint. you should probably just use ESLint. In conclusion, for the starting pack, well, for just JavaScript, we haven't even touched the web frameworks yet. Yet, right? You want Babel for transpilation, Webpack for your pipelining and bundling.

You want to use ESLint for linting. Um, and then for goodness sakes, I don't know what to tell you on package management anymore. more yarn is great. Yarn is backed by Facebook if that makes a uh your choice easier in terms of institutional support. Before we talk about the various frameworks and libraries, I want to make sure everyone's really clear about what I mean. I'm making a really important distinction. A library is something you call yourself, right? You use requests as a library. You have some main loop and you call it. A framework is something that is going to call your own code. Referred to as inversion of control, or else sometimes the Hollywood principle, don't call us, we'll call you. Django is a really good example of a framework.

Both provide a mental model for working with the tools to provide a solution, right? So we understand the problem, right? The problem is effectively the dumb. I think Marco Rogers said it best, right? This is a reminder that the DOM is actually a giant mutable global variable in the middle of your program. Not to mention the fact that There's there's duality to it as well, right? So the way I kind of think about it is like this, right? You've got your HTML to one side, it's got the model and the view, and you really wish it didn't. And then you've kind of got JavaScript over there, and you're gonna try and use it in some way. to control it. So we all are s familiar with model view controller, and Angular 1 is a really good example of this. I haven't played with Angular 2

or Angular 4. I just found out today. Thank you that there is no Angular 3, madness. It's referred to as MVC I'm not sure that's 100% accurate. And they keep the JavaScript totally separate. And then they ask you to annotate the HTML with what they call directives so that they kind of connect the two with this two-way binding. So the content is dynamic, but the structure of the app is still dictated by the HTML. I think of it like this, right? You've managed to split up this model into smaller parts And if you change it in the HTML, it's reflected in the JavaScript and vice versa. But it doesn't actually sort of separate that weird duality between the HTML. In the HTML.

All the way at the other side, uh the other end of the spectrum, we have these reactive programming things. They're fairly new, they're a little strange, and they look at the problem and they say, you know what, we want to think about this in terms of of time, right? We're gonna have these initial parameters and we expect that people are gonna show up, they're gonna click buttons and we're gonna get inputs, but changes happen according to time, and we want those changes to be determined So you set up a function at the beginning when your page loads, and you say, well, if things change in the following ways, if I see the following things, then I want you to deterministically change The HTML in the following ways. It's a little strange. And the real problem is that it almost kind of gets away from this idea of model

or state, right? You have these actions over time and you're pumping them through. Through a function. So it's very functional. And then you have the view. Now this is very nice, though. You'll notice there's a single direction for control. And that's a real improvement over a two-way binding. Facebook's React is sort of this lovely in-between, right? It stays with the single direction of information. But it's a library. And so it only provides part of the solution. They call it the view in an MVC app. And again, MVC MVC's not quite right, but we're gonna stick with it. And they expect that your MVC app is going to follow this thing called the flux architecture. So on top of that, they're like, oh, it's a view, and you have to do

you have to follow all the following rules. Good luck learning all of them. The one key difference though is that they moved completely away from modifying the HTML. They introduced this concept of a virtual DOM. And they're going to modify the HTML after they create this virtual DOM. And that really changes things quite drastically. It looks almost kind of like this. The problem, of course, is that React only gives you that. It gives you part of the controller and none of the state. Well so the way they put this together is they say, oh well, this is how it works. The actions are either network actions or user actions. It's clicking a button, it's receiving network information. like JSON from an API. And they're gonna handle

the rendering of the view. But they don't give you this dispatcher, which is effectively the controller. That's what controls the the actions and how to behave. Um and the dispatcher's goal is always to change this state or this store. It's just raw data that is used to render out the HTML. So what do you do? There's also a side trick here. They're only actually giving you kind of sort of part of the view. So the first thing they say is, oh yes, well you have to be able to handle JSX. That's how we're going to sort of sort of provide syntactic sugar that makes sense for interacting with the virtual DOM. So that's the first thing you need. And then there are lots of tools that provide the flux architecture. The one we were using was Redux.

It's sort of become the the de facto go go-to. And so it works on a functional accumulator, sometimes also uh called a reducer. You hear about the reducer pattern. Unfortunately I don't have time to go into it, but once you sort of look in that functional po uh functional paradigm, it's actually fairly intuitive. And so it breaks down like this, right? You've got the the Redux and the connector, React Redux, which allows you to manage your state and part of the controller, and then React and JSX for handling the second, the sort of the end of the controller and writing out to the view. Now of course that turns out not to be enough either. Everything I've just shown you is synchronous, and that's a real problem because you're interacting with an API and you're receiving network requests. So you need to be able to handle a synchronous

Synchronicity in your application. There are lots of solutions for this. Redux Thunk is the simplest. Netflix is using a thing called Redux Observables. It is overkill. Redux sagas seems to be uh growing in terms of preference. I haven't played with it. It's a lot. The other thing is that you are going to be making network requests. For a long time that you wanted to use XML HTTP request. Don't. We're moving to a new spec. Get a polyfill for fetch. It introduces Introduces a ton of sanity. Um, we also use Redux forms and Redux Logger. It is exactly what you think it is. Uh I want to take a quick moment to talk about testing because testing is the best. You have yet another choice to make. Where do you test, right? JavaScript for a long time only ran in the browser.

Suddenly we have this node thing. You can now run it directly in a process. That's where Webpack is running. You can also run your testing. And in fact, you probably should. Originally, you would have used Karma with Jasmine or Mocha to run directly in the browser, or you would have done end-to-end testing. With Selenium WebDriver. But because you're not really programming to the differences in the browser and you're using a framework, you can avoid all of that complexity and you You can use Node to run your tests with Facebook's Gest, and it's built to work with React. It's glorious. We went from having tests that ran uh you know six or seven minutes In Karma. They ran in under a minute with Jest. It was huge. I highly recommend it.

So that's React, the mental framework. There's a really important implication here. React owns the entirety of the DOM, right? It's got this virtual DOM and it's in full control of the DOM. So how does that interact with J? Django and Django templates. And unfortunately, there is no good answer here. If you're just interacting with a Django API or any API, this is fairly straightforward, right? You use fetch, you you uh make requests, and you get um JavaScript back. Thank you. Um if you are interacting with Django templates, um oh boy, right? Because Django templates want to provide HTML and the DOM, but React wants to be in full control of it. Do you pre-compute with like node on on your server?

Do you try and provide information in your templates so that you can load that information directly? Inter React, what about progressive enhancement? What about accessibility? Honestly, there isn't a clear-cut answer here. It depends a lot on your app, a lot on the market, who you users are. There's also like a I could give a full talk about this. Luckily I don't have to because Julian Fallop, core contributor of of Django , gave a talk about this. two Django cons ago, it is still quite relevant, so I highly recommend it. To conclude, JavaScript's problem is the DOM, right? The DOM is it's it's horrible, right? It has this dual nature to it. It

and it is a giant global variable. And the goal of every framework is to try and provide some means of dealing with this global variable in a sane fashion. Whereas with um HPP HTTP on the back end, a lot of the frameworks look similar, right? You can start with Django and then you can look at bottle pie and you can look at Flask and you understand what's going on because the solutions Are fairly similar, right? You understand the core components. It's a little harder with JavaScript because the way they they rationalize The solution is a little bit different. So it's worth taking time to look at their mentality, you know, the mental framework that they're using, because

the solution For your product is going to differ. There are some places where Angular is going to be a better choice than React, and unfortunately it's going to really depend on the product that you're building. If I were starting this all over again, I would not spend the two weeks I did configuring Webpack. It's awful. Thankfully, no really. Thankfully, Facebook has put together this thing called Create React App. It is great. It works like black magic, which is unfortunate. But uh it gives you this project that is yarn compatible, it comes with Webpack, it comes with Babbel, it gives you a config, it works with ESLint, and it comes with just tests. Goodness gracious.

Gracious, thank you. Um of course, you know, JSX and React, somewhat obvious. You will have to install Redux and Redux Logger and Redux React and Re-oh, my you know You get the picture yourself. But you know, you're going to have to do that anyways. I think I have like 15 seconds. What's coming next? As with JavaScript. As with JavaScript, everything moves at a million miles an hour. Fastest, it's better, it's called React Fiber. Should I use it? I really don't know. Um the Apache Foundation came forward and said you can't use React in open source apps because of the patents that

That Facebook has placed on the React code. There's a really interesting problem where should you use it at all? What about using libraries like Inferno. js, which is effectively the same API and exactly the same mental framework, but that is much, much quicker. Do those patents apply? I honestly don't know. There's some other really interesting There's some interesting movement. Google I. O. lately has really focused on performance because of these, right? Running JavaScript on these mobile devices is actually actually really taxing bandwidth, computation, et cetera. And so there's a real sort of movement in the JavaScript community to move towards simpler, smaller apps. Svelte is really interesting. It's not ready for production yet, but I would keep an eye out for it.

I've heard really good things about Vue. js. Um should use it instead of React. Again, I'm Unfortunately, really unsure, and I I wish I could be um I give you a a a firmer accent uh firmer um answer about that. But Uh yeah. Thank you very much.