From 101d6baba8e01b866328b96bfdb36aff01642bd2 Mon Sep 17 00:00:00 2001 From: "Kent C. Dodds" Date: Mon, 6 Jun 2016 13:04:53 -0600 Subject: [PATCH] Add transcripts to several shows Closes #32 Closes #74 Closes #21 Closes #79 --- episodes/2016-02-10/index.js | 205 +++++++++++++++++- episodes/2016-05-11/index.js | 213 +++++++++++++++++++ episodes/2016-05-18/index.js | 236 +++++++++++++++++++++ episodes/2016-05-25/index.js | 391 +++++++++++++++++++++++++++++++++++ 4 files changed, 1044 insertions(+), 1 deletion(-) diff --git a/episodes/2016-02-10/index.js b/episodes/2016-02-10/index.js index ba725ac..ff1355c 100644 --- a/episodes/2016-02-10/index.js +++ b/episodes/2016-02-10/index.js @@ -26,6 +26,209 @@ export default { {twitter: 'getify'}, {twitter: 'tylermcginnis33'}, ], -} + transcript: ` + KENT: Hello, everyone! My name is Kent C. Dodds. And I guess I could say we're live with JavaScript Air. (laughs) So for those of you who are not familiar in the audience, JavaScript Air is a live broadcast podcast, all about JavaScript and the web platform. And we just started in December, so we've got a handful of shows on javascriptair.com. And this show will be available, hopefully, within the next week when I can get the audio off of it. But just a quick shout out to our sponsors, we have Egghead.io is our premier sponsor. They have bite-size videos and they're amazing, awesome. FrontEnd Masters is also a training website. Check them out. We're also sponsored by TrackJS, error tracking. They're fantastic. And Codecov is a code coverage platform that's awesome. And WallabyJS, they do live code coverage. As you're typing your code, it runs your code, like, it's amazing. Go check them out. + + Okay, so I should probably go ahead and introduce our panel. I don't have my regular Google Doc in front of me, so I'm kind of nervous but luckily I've got this. (laughs) We've got Kassandra Perch, Tyler McGinnis, Allen Wirfs-Brock, Brian Lonsdorf and Kyle Simpson. Brian, Kyle and Tyler are our regular panelists on the show. I'm your host, Kent C. Dodds. Allen and Kassandra have graciously accepted the invitation to join our conversation. Kassandra, like, five minutes ago. (laughter) So, thank you, Kassandra. + + So I think a good kickoff for our show is actually to get an introduction to our guests because they're not on the show every week. And so why don't we get an intro to you, Kassandra? Give us like sixty seconds of who you are what you do. + + KASSANDRA: Sure! So I am a Developer Evangelist at Auth0 during the day. I like to talk about user and identity management. And then when I'm not doing that, I'm building NodeBots and supporting the NodeBots community, and absolutely gushing about everything I love about NodeBots. So that's pretty much what I do. (laughs) + + KENT: Awesome. And totally loved your talk this morning. Anybody watching at home, go watch that talk. It was very, very good. Also, you just had a show with JavaScript Jabber about Auth0, right? + + KASSANDRA: I did. I did. It was really good. + + KENT: Cool. I was listening to it this morning. So JavaScript Jabber is a great podcast. Not our podcast but listen to both. (laughs) So Allen, could you give us an intro? + + ALLEN: Sure! So I guess my main claim to fame for this room was that I was the Project Editor for the development of the ECMAScript 2015 ES6 specification. And I was actually Project Editor for also ES5 and ES5.1. And what that means in the world of JavaScript standards development is for ES6 is I essentially wrote most of the standards. I didn't necessarily make all the decisions of what needed to be written down, but it was my job to actually figure out most of the actual specification material. Before that, I've done lots of things over a long career. I'm a dynamic language guy. I was really heavily involved in the early emergence of object-oriented programming technology and the Smalltalk programming language and building high-performance virtual machines and lots of other things. And that's kind of what ultimately led me to JavaScript. + + KENT: Cool. Thank you! You have a very interesting background (laughs). So before we get into asking questions, I'll just give a little bit of the format of this. For about twenty minutes, we're going to be just chatting amongst ourselves, probably generally about ES6, ES2015 and 2016. And then for the last ten minutes or so, we're going to be taking questions from the audience. And the way that we do this on the JavaScript Air show is through Twitter. And so at the last little bit, I'll pull out my phone, so don't think I'm being rude, and I'll be watching the #jsAirQuestion hashtag. So that's #jsAirQuestion. So if you have a question during the show that you'd like to ask, just go ahead and tweet to that hashtag and I'll bring up as many as we can in the time that we have. So, great. I think a good starter question for our panel is is it "ES7" or "ES2016"? + + ALLEN: It's ES2016. + + KENT: Can you explain a little bit about the reasoning behind that? + + ALLEN: Sure. You know, so first of all, historically, there has been a kind of confusion about these numbers and numbers getting bound too early to particular things. In particular, there was a whole effort to develop ES4, which has never happened. Then we kind of had to skip that number, which sent shock through the world of standards people because that's actually a document revision number, yet there was no revision four. And so after the long, long effort to develop what we all knew as ES6, in TC39, we really wanted to move towards smaller, more incremental releases on a yearly basis and stuff. And doing that, we just foresaw that having a string of kind of meaningless integer numbers, you know, once we went through four or five or six of those was going to be kind of meaningless. And so we just decided to bite the bullet and say, "Okay, we're gonna start identifying the standard revisions by the year they were released." In the long run, the feeling is most people don't need to talk about those numbers. It's really just JavaScript. That's really all you need to say is JavaScript, you know, the current JavaScript standard and-- + + KENT: I'm so sorry to derail it really quick. If you're moving your head, and that's ok to move your head, just make sure you move your mic with you. + + ALLEN: Oh, sure! + + KENT: Okay. That's really interesting. So I think this is really big for the JavaScript community that we're going to be having yearly releases. Can you talk a little bit about the process for getting features into JavaScript? + + ALLEN: Yeah. So TC39 is the standards committee that is responsible for developing JavaScript. And it's made up of members who represent companies and stuff. And it's that group of organizations and the people who represent them who actually make the decision of what is going to go into the revisions of the JavaScript standard. And during the development for ES2015, ES6, that was a pretty ad hoc process. People would write proposals and over sort of a long period of years, actually those proposals would evolve and consensus would be built. And then dozens and dozens of these went into making the final standard. + + To have a more incremental process, what we're doing now as we actually have identified stage of developments that go from a number of (mumbles) stages or older, stage four or stage zero is what we call a straw man which is sort of a wacky idea. And it progresses from a wacky idea to "yes, the committee thinks there's a problem here that's worth working on." That's stage one. Stage two is, "Here's the shape of the solution that we think we're going to follow." The stage three is, "Here is actually a specification of what we think we're gonna do. And we'd like people to try this in browsers and stuff." To stage four where, "Yeah, this is locked down. It's complete and it's going to be in the next edition of the standard." + + So how long it takes a particular feature to go through that process depends on the size of what we're talking about. If it's a very small change, like the exponentiation operator, it can go through those phases quite quickly over a matter months. If it's a large or complex set of features like async functions, it can take years. It's likely to take years. But that's basically the process. And then when the yearly releases come out, it's basically about this time of the year, we look and see, "Well, what's at stage four?" Those are the things that go into the next official version of the standard, which it will be released in June. + + TYLER: So you've mentioned that stage zero is kind of the... you used the term "wacky" ideas. + + ALLEN: Well, they may not be wacky but they're just, you know, we call them straw man. "Wouldn't it be interesting to do x?" + + TYLER: Yeah, absolutely. So, with tools like Babel, now, all of a sudden those stage zero ideas are starting to get more adoption in actual production code bases. What's your opinion? Is that a good thing because you kind of get it tested before it actually goes in the spec or is that a bad thing because all of a sudden, we have entire communities around stage zero features? + + ALLEN: Well, it's risky. I think as an app developer, if you're going to be using Babel in that way and using experimental features, you really need to be aware of this staging process and where they are. If you really become dependent upon a stage zero feature, you're really taking a lot of risk. I mean that that may never go anywhere. It may be that the actual implementation, the actual details of it changes in a way that's totally incompatible with what you've done. So you really have to weigh the risks there against the benefit. I mean how badly do you need that? + + KYLE: So you're talking about these stages of features and I think one of the ones most people probably are kind of anxious about is the async await, which I think it's current status is at stage three, is that correct? + + ALLEN: Mh-hm. + + KYLE: So it almost made it into what we are going to know as ES2016., but it didn't quite make it. So let's just say that it comes out a week after... it makes it to stage four after you've put the official stamp on ES2016. So it will eventually, eleven and a half months later, make it into a spec. How do we talk about that thing, for that potentially eleven and a half months? Do we start saying, "Well this is ES2017 because it's already stage four." How do we talk about these features? + + ALLEN: Async functions. I mean that's the name of the feature. If something is at stage four, that means on the TC39 GitHub site, there will be a complete specification for that feature. And "stage four" means that specification is essentially frozen. It's not been fully integrated into the, you know, the thick document that defines the entire language. But the intent is that it's not going to change from that stage four specification. Also to be at stage four means that it hasn't been implemented in browsers. I mean, there has to be at least some browsers out there that's already implemented the feature. So, you know, it's there. And so I just try to talk about the feature by whatever the name of the feature is. + + KYLE: But to push on that a little bit, features are never finished, right? They are always subject to... so a great example is what we know of as classes that landed in ES2015, ES6, there's already several proposals that look like they're likely to land at some point in the future, that augment that syntax, changing some of its semantics, things like that. So there does seem to be a need in the discussion of features to say, "Well, I'm talking about the ES6 class versus the ES2018 version of class." And I assume that the same may be true of other features like async await. There may be things that land in that initial spec and things that are, at the same time, being worked on for a potentially later spec. + + ALLEN: Well, sure. I mean, take something that's even, in some ways, more pervasive, let's say regular expressions. Ah, there is certainly room for evolution of regular expressions (mumbles) additional features. But most people, most of the time, don't need to make that distinction. If you really need to make that distinction, make it. Say, I'm talking about this proposed extension in the classes or I'm talking about these easy extension to regular expressions or what have you. Or put it another way, how do you address this problem... how do you talk about emerging HTML features? What is unique about this issue to JavaScript? + + KYLE: The fact that basically, when HTML5 came out, they said, "That's it. There's no more after HTML5." So, it's all its all HTML5 even though it came years after. + + ALLEN: Well, but it's still continually evolving. + + BRIAN: Maybe CSS is a better example, but it makes sense. I did have a quick question if I could interject. Do you feel okay with that last answer? (laughs) + + KYLE: Yeah. + + BRIAN: I was just wondering if you have any focus on a particular paradigm or way of programming in JavaScript. Like is there a guiding light for adding features like I see we added classes but then I also see a proposal for a flat map. Are we looking at something like Scala in the future? + + ALLEN: So JavaScript, just the way I would characterize it, is a multi-paradigm dynamic programming language, dynamically-typed programming language. And I think at least from the perspective of TC39, that's what we intend to maintain it as. And so when we look at all the paradigms, programming paradigms that are in use and look at how well they're being served by the language. And if there are deficiencies in the language or some improvements and improve an object-based approach, we would look at augmenting language there. If there are deficiencies from a functional approach, we'll look at what those deficiencies are, and try to fill them. But maintaining this idea that it's a multi-paradigm language and one of the characteristics of a multi-paradigm language is that features that support differing paradigms still have to fit together and create a coherent whole or a coherent design. So we have to look not just in terms of a functional style but we have to look at well, how will these functional features fit in when people are using more object-oriented features and stuff? + + KENT: So Kassandra, I actually had a question for you. I'm interested in your perspective on the progression of the language. And in your talk, you talked about a tool that you use to take a JSON object and convert it into C code. What was the name of that tool again? + + KASSANDRA: BabelBot. + + KENT: BabelBox? + + KASSANDRA: Bot. + + KENT: Oh, BabelBot. When I first saw that, I was like, "Well, that's kind of an inconvenient naming, kind of confusing because we have Babel." But then what it actually does it kind of does something similar to what Babel does. But what's your take on the new specification? What does that mean for the NodeBots community? Like, do you see in the NodeBots community, are they using the latest version of the language with Babel or anything like that? + + KASSANDRA: So that's kind of... we're just now getting to that. So basically, Node serial port had some issues when Node moved to 4 and adopted a lot of these new features. So we just now, I think in December, got Johnny Five and node serial port working consistently with Node 4. So we're starting to see more and more of these features coming to NodeBots. And from a global perspective, what I've found is a lot of the features that are new to JavaScript make it a little easier to teach, especially for users that are coming from different languages. Because of that multi paradigm outset of JavaScript, if you're looking at someone who's never coded before, you can teach them one way. But if you're looking at someone who's come from a background where they used to program fifteen years ago, but they're just now getting back into coding, you can also kind of (mumbles) that. And so because NodeBots has such a core in education, these new features are really starting to help us out in creating better curriculum in teaching people faster and teaching people code that they can easily translate from NodeBots into a career in web development. + + KENT: Cool. Tyler, what's your take on that? Being kind of in education, in general. Have you seen ES6 and the future specification being easier to teach? + + TYLER: So it's tricky because I think it is, but then you have this problem of beginners getting into the field and they go, "I don't know if I should learn like ES5," or I've seen that question a lot like, "Do I learn ES5 or do I learn ES6?" And even though I think ES6 has done a great job as far as like making it easier to come from different programming languages, it is tricky and it's kind of a natural thing that happens to beginners, because now they have like two choices. And an obvious answer is like, "Well, just learn JavaScript." You can start with ES5 like the same thing almost, like as you were mentioning earlier. But I think because we do put such a distinct point between "this is ES5 and this is ES6, and now this is ES Whatever," that makes it a little a little frustrating for beginners. But we can't just kind of stop the whole progression of the language for beginners, so. + + KENT: I think the challenge is that browser support different things. And so just today I had somebody asked me, "What's the browser support for Array.prototype.sum?" Because you really, unless you look into the documentation, you don't know, "What am I ok to use? What do I need to polyfill?" Kyle, what do you think about this subject? + + KYLE: Yeah, I definitely think that there are lots of differences between the browsers. And rather than being scared of those differences, I think we should actually embrace that idea. I'm glad that Chrome tries out a feature first and Edge is working on a different feature and Firefox is working on a different feature. I think that helps. And the way we normalize that of course is through the use of tools. So some people who have sort of asserted the idea that transpilation tools are a kind of like a temporary thing and a stopgap and will eventually go away. + + My perspective from the outside, I'm not on the committee, my perspective on the outside, JavaScript's gonna keep going and there's always going to be a gap between what they just came up with and what I can use for supporting, you know, customers. So there's always going to be a need for that tooling gap. Now with respect to teaching, I always think we're gonna have to take a new feature and teach it in the context of how we did that thing in the version before. And that's how like all I've approached with the ES6 is to say, "I'm not just going to teach destructuring or I'm not just going to teach you this feature of ES6, I'm going to show you how we did that thing before and why this new declarative approach makes the code more understandable, more readable, more teachable." + + KENT: But at some point, we're going to pretty much do, destructuring might not be a perfect example, but destructuring will be just like such a ubiquitous part of the language, that all browsers will support, anything that your shipping or any environment you're shipping to will support this feature. So in that circumstance, years down the road, do you still plan to teach in that method or will you just kind of teach it just like you teach other property accessors? + + KYLE: I think consistent with the way I teach everything that I teach about JavaScript, I don't just want you to use a feature as the sugar that's presented and not understand what its doing. So destructuring is actually a perfect example because there is a set of primitive operations that all of this syntax sugar maps to. And that's not just an implementation detail, that's an understanding detail. It helps me to get a better mental model of what all of these new curly braces in different places that I've never seen before, why are they there? Why is there an equals there? I need to understand what the fundamental operation to emulate that would be. And right now, that's a bridge between my current understanding of JavaScript and the new stuff. But five years from now, I'm still am going to want you understand what destructuring is doing, so you know why it's important. + + KASSANDRA: That reminds me of Ashley Williams' talks from JSConf in May of last year, about the abstractions and the teaching abstractions. He's right, like, it'll always be an abstraction no matter how integral or how day today it is a part of the language, we'll still have to teach why that abstraction works and what that abstraction does. Because if you present an abstraction to a student without explaining it, eventually, it's going to go down a bad path of they're either not going to understand it correctly because they don't know how it works or something like that. So yeah, I definitely back up Kyle's point; we're gonna have to teach it like an abstraction because it's still what it is, no matter what. + + BRIAN: I was going to ask if you feel that you need to know exactly what's happening under the hood a lot more when you're working in robotics, then so as more sugar gets presented, the further you get away from like memory management and things that you kind of want to have control over. Is that a thing? + + KASSANDRA: That's a great question. So to give some preface to this, I have exactly zero formal electrical engineering training. I knew zero C until I started doing... like a year into NodeBots when I started wanting to build things that required some C. So I mean, yes and no. You start to learn how the things work as you build up to them, but like it's certainly not a prerequisite for getting into robotics. You don't need to already know C to get into robotics. But you will pick up some C and some memory management while you're doing it. But it's not nearly as hard as people seem to think, so (laughs). + + KYLE: That's a good thing to have a layer of competency, wherever you're at, you have some competency understanding of the stuff in the layer below, so that you're making proper decisions. + TYLER: I think even on a broader term, I've found that beginners or new to JavaScript, it's really helpful to talk kind of about the history of JavaScript and how we got here. I don't think we do that enough in teaching. Because in my experience is when we talked about like, "Hey, we just had like pure DOM manipulation." And then like MooTools came and jQuery came. That's super refreshing because what the newcomer is seeing is they're seeing how we've kind of adapted and we've started to fix these problems rather than just jumping into like the virtual DOM. And they don't really know how we got there and they just take that for like (mumbles). I think if you are starting out or you're teaching someone starting out, it's really, really helpful to kind of just start at the beginning like, 1995. And whether it takes a while to get to where we are, I think them seeing the history of how we got here, and the problems we solved getting here is really, really helpful. + ALLEN: So I wonder, so one perspective I take on JavaScript is it's just yet another programming language. And if you're teaching somebody C or C++ or Python or whatever, I mean would you go through that same thing? Would you try to go back to the early stages of those languages? Or in particular, we could do that with a beginner or should you spend that time really focusing on kind of the fundamental concepts and-- + + TYLER: So for your cs3, that's exactly what they do. I don't have cs3 so I don't know, but I think that there's at least some merit in that. And I don't know. I mean the difference between like JavaScript and even like C, there's a lot more history with C, I think. So I think it works with JavaScript. I'm not educated enough with- + + KYLE: The other complicating factor there of course is that JavaScript has to interact with all these other things that actually aren't JavaScript, like the DOM and the other web platform features. A lot of people think of that stuff as JavaScript and don't understand the history of that stuff. So you may not necessarily need to go back and look at what ES1 said about JavaScript before we had try catch, for example, but understanding the context that JavaScript is interacting with those other things, I think, is useful. And maybe there isn't as much of an analog in the C world because it seems like you kind of do most everything all in one, you're maybe not as interacting with DOM from your C program like we have to do in our JavaScript programs. + + KASSANDRA: Taking it back to Kyle's point about having a basic competency, from a career perspective, knowing the history of a programming language can be very important to its future. For instance, when I was teaching Node two years ago, I had to teach the rift between io.js and node.js because we didn't know who was going to come out on top. We didn't know what set of features was going to take over. So like knowing the history of a programming language can affect you as a developer because you'll know a little bit more about where that language is going, feature-wise, popularity-wise. You can kind of see what's going on in the horizon. And it can really affect how what you want to learn how you want to do things in that language. + + ALLEN: Yeah, I mean. I totally agree that knowing that programming languages, knowing the history of programming languages is really important. Probably the most important thing you can do, if you want to have a long career in software world is understand many programming languages and stuff, because over time, they're going to change. No matter what it looks like the today, ten years, twenty years from now, it's going to be different. So absolutely, you need to do that. But I'm not sure whether it comes exactly at the beginner's stage or it's more downstream a bit. Once you've mastered a programming language, now you need to start looking at other programming languages and history and stuff. + + TYLER: That's where I think we're painting with a very broad brush because for example, someone who's like an entrepreneur doesn't really care that Brendan Eich made the language, right? They just want to build something. They just want to like make money. For someone who's planning on getting into a career as a software engineer, I think that's its more critical to them. + + KENT: Yeah, sorry. Just to kind of continue on that point, Dave Smith wrote a recent article that was all about the importance of learning to learn. And I think that's something that we kind of overlook. We just think, "Okay, I'm an Angular developer and so I'm just gonna like build Angular for the rest of my life." And that is not advisable. So learn JavaScript, but then don't forget to just learn to learn. And JavaScript is an amazing language. I love programming in it, but I'm not going to be doing it till the day I die. I'm almost positive of that. + + BRIAN: You'll be programming in Haskell soon. + + KENT: That's exactly what I'm planning on, actually. + + KYLE: No, JavaScript is going to kill me, so I actually will be-- + + (laughter) + + KENT: Thank you for that. (laughs) + + ALLEN: So I wanted to throw out here kind of my perspective on where JavaScript fits in the world for the long-term and kind of why I decided it was important to get involved with JavaScript. I think JavaScript's position in computing for the next thirty to forty years is comparable to the position C had for the last thirty years. It is sort of the canonical language that defines... that is central to an era of computing. And that there will be variations and dialects, there's C and then there's C++, you can say Java is very end of that. But at its core, if you think about what it took to develop personal computing technology, PC technology, C was the programming language that was at the foundation for that. And I think the things we're going to be doing for the next thirty or forty years, it's JavaScript is going to be at the foundation of that. There will be many other languages. JavaScript is going to evolve incredibly. There may well be dialects of it and stuff, but you know it really is the central language going forward here. + + KASSANDRA: And you can see that in the hardware world. Basically, I haven't seen a hardware platform come out that that had a ton of traction the didn't have a seat at the table for JavaScript developers, either via a dedicated JS SDK or supporting a third-party JavaScript SDK or even making JavaScript one of their core tenets. So especially definitely in the hardware and IoT space, JavaScript's at the seat of the table. And so I think that kind of reinforces that. + + KENT: I'm afraid I'm gonna have to cut it short. We've got about four minutes or so and we do have a couple questions on Twitter. This has been actually a really awesome conversation. I wasn't planning on talking about education so much, and I'm glad that we did because I think that's really important in our community. So here we have a couple of questions from Crowd Source Labs, "Doesn't it take longer than a year for browsers to come up to a new standard? How will they ever keep up?" + + ALLEN: Well, the releases we're doing are much, much smaller, right? It will take a good browser probably about two or three weeks to implement the new features better- + + KYLE: There are two in ECMAScript 2016, exponentiation operator- + + ALLEN: Yeah, that's the whole point is to not have these huge baskets of interdependent features that take forever to implement. + + KENT: Yeah. And I think that's a common misconception just because ES6 was so big, that many people think that each year, it's just gonna be like this huge evolution of the language. Which would be really dangerous for the language, in my opinion. And so yeah and it's actually kind of touches on to Thomas Bernie's question, "Briefly, which ES2016 feature is the most exciting to each panelist?" And there are literally two features in ES2016 and so- + + (laughter) + + KASSANDRA: He probably meant ES6. + + KYLE: Fight me over the exponentiation operator, man! + + KENT: (laughs) Yeah, I need that. I'm all over- + + TYLER: Yeah, Kyle actually has a new course on that coming up. + + KASSANDRA: Yeah. + + KENT: No, but let's talk really quickly. And like Thomas said, briefly, about each one of our favorite ES6 or ES Next feature, I guess we could say. So for me, I think probably my favorite is, oh man, destructuring. I love to destructuring. I think it's awesome. It makes things really expressive declarative. + + KASSANDRA: As someone who has to deal with third-party data on a regular basis, where I just have to move one property to the other, I really love the arrow syntax. + + TYLER: I really like classes. That was a joke. + + (laughter) + + So this is going to sound-- + + KENT: I thought we were going to avoid classes-- + + TYLER: We had to mention classes once in there. + + KENT: Yeah. (laughs) + + TYLER: So this is really easy one but I don't know why i like it so much better, the template strings. I don't know because I'm just like not that smart and it just made sense, but I really like it. + + ALLEN: So in the long run, I think the modular design is going to have the most impact and influence over anything that's in ES2016. + + BRIAN: Nice. I like fat arrows. I'm a lambda kind of person. (laughs) + + KYLE: So for current features, I would say other than the destructuring, I would say generators because you know, to borrow a mathematical term, sort of squaring the circle, thing the generators allow is a synchronous looking asynchronous programming. And that is something that we really just didn't have a paradigm for. The state machine equivalent to that was just so bad that nobody ever did it. And I think that was leading the way into async await and other patterns that are coming likely beyond that. I think that was one of the biggest paradigm shifts that we got was getting that sort of feature and understanding how, with promises, that will change asynchronous programming. + + KENT: Cool. That's definitely one thing that I haven't actually used yet, so I need to get on that train. Kyle said so, so. (laughs) Okay, so we have two more questions and one more minute. So this is from Tom (mumbles), who I think is in the audience. Hi, Tom! There he is. He says, "When teaching a beginner ES6, do you think arrow functions glaze over understanding context? How do you handle that? I think the answer is yes, but how do you handle it? + + TYLER: So I think I think you shouldn't mention arrow functions before you teach context. I think that's the answer, in fifteen seconds. + + KYLE: I don't teach arrow functions- + + TYLER: Or just don't. Don't teach it. (laughs) + + KYLE: I don't each arrow functions because I don't think that they are actually useful for getting rid of the function key word, the way most people seem to think. There's one particular use case, which is giving you a lexical environment for the "this" keyword or the arguments object. I did an analysis of my own code and that touched about 2% of the code that I've ever written. So on the whole scope of things, it doesn't seem compelling to me. + + KASSANDRA: I'm a fan of them, but I agree you teach context long before you teach arrow functions. If you would teach a beginner arrow functions at all. + + KENT: Yeah. I feel the same way. The utility for arrow functions for me is not the lexical this, which probably should be, but it's more the ability to have one liners, and I just love that. + + BRIAN: Well, I want to jump in there and say, from a functional perspective, you're striving to write a single expression without... that's going to always return something. And if I use fat arrows, I know I'm doing it correctly. If I have the curly braces and have to do return and all those stuff, I guess you know, functional... the word function will make you have to write return and gives you a lot more freedom to not write a single expression. + + KENT: Yeah, cool. So we are just a second over or two, so you can feel free to leave but I'm gonna ask this last question, so. + + (laughter) + + So this was Ramana Venkata, who's actually one of my developers in code mod world, but he says, "Many people seems to be unhappy with Promises swallowing errors. Is there way a to make this situation better?" + + KYLE: They've already made, and by "they" I mean the web platforms, the browser platform and the node platform, have already mostly solved this by adding... there was aspect for unhandled rejection. So it's kind of like the new school way of window dot on air. It's a way to catch something if you forgot to put on your catch, you know, method on your promise chain or something like that. I would say chaining of promises is absolutely the least important part of promises, so I don't get all that worried about it because I'm gonna be using, like I said, the async await or the generator form, the synchronous syntax, the try's and catches, so I'm not all that concerned about it. And I think if you get too obsessed about creating these long promise chains, then you have to worry a lot more about that problem, where these other patterns kind of solve that for you. + + KENT: And that's a perfect answer. So that's our show. I want to give a shout out to our Silver Sponsor, O'Reilly Fluent Conf. They're going to happen in three, four weeks. And we do have a discount code on our deals page, if you go to our JavaScriptAir.com/deals. And we have several other deals on there that are totally legit. And if you have suggestions for the show, go to suggest.javascriptair.com. There's a Google form you can fill out. If you have feedback, feedback.JavaScriptAir.com. We totally appreciate your feedback. And with that, I just would like to thank Kassandra and Allen for joining us on the show. And thank you all for joining us as well. Thank you! + `, +} diff --git a/episodes/2016-05-11/index.js b/episodes/2016-05-11/index.js index bac39e4..197a583 100644 --- a/episodes/2016-05-11/index.js +++ b/episodes/2016-05-11/index.js @@ -79,4 +79,217 @@ export default { ], }, ], + transcript: ` + KENT: Java Script Air. Hello, everyone! My name is Kent C. Dodds, and I am your host for this Java Script web platform podcast broadcast thing, that is awesome. And today we're going to be talking about the science of people in tech. Really excited to have some people on the show who are really interested in this and have a lot of experience and background on this subject. + + Before we get into that, I'd like to give a shout out to the sponsors that make some of the cool things about this podcast possible. Our premiere sponsor is Egghead.io. They have a huge library of bite sized web development training videos. Check them out for content on JavaScript, Angular, React, Node and more, including Redux. I hear that Dan Abramov is working on a big Redux series, so if that's your thing, look forward to that. + + Frontend Masters is a recorded expert-led workshop with courses on Advanced JavaScript, Asynchronous and Functional JS, as well as lots of other great courses on Frontend topics. + And TrackJS reports bugs in your JavaScript before customers notice them, and with their telemetry timeline, you'll have the context to actually fix them. Check them out and start tracking JavaScript errors today at TrackJS.com. + + And then SparkPost is email delivery built for developers. Build something awesome with their Node JS library or SMTP relay. Start sending 100,000 emails free with SparkPost at SparkPost.com/JSAir. + + And finally, WebStorm is a powerful JavaScript IDE. It makes developers more productive with its super intelligent code assistance for JavaScript, Node JS, Angular and React, and in integration with lots of different tools. Check them out at JetBrains.com/WebStorm. + + Okay, so this is a live show, so for any of you who are watching the show live, we want to engage with you. And so, if you have any questions from our, the people on the panel or our guests, during the show, then you can tweet with the hashtag #JsAirQuestion and we will get to those questions at the end of the show. + + And then, this is a weekly live show. Next week, we're going to be talking with Lee Byron and Nick, I don't know how to say his last name, Schrock? (chuckles) From Facebook about transitioning from REST to GraphQL. It should be a solid show. Great, and then, as always, follow us on Twitter, Facebook and Google Plus to keep up with the latest from the show. + And with that, let's go ahead and introduce who's on the show today. So for our panelists, we have Brian Lonsdorf. + + BRIAN: Hello. + + KENT: And Kyle Simpson. + + KYLE: Hello, everyone. + + KENT: And then for our guests, we have Kate Edwards. + + KATE: Hello. + + KENT: And Omoju Miller. + + OMOJU: Hello. + + KENT: And Steve Andrews. + + STEVE: Hello. + + KENT: And we're happy to have them all here today to talk about the science of people in tech. So before we get into that, let's get a quick intro to our guests, and then we can start chatting about our topic. So Kate, why don't we get an intro to you first? + + KATE: Okay, so I'm Kate Edwards. I'm the executive director of the International Game Developers Association, which is the professional society for anyone who makes video games. And I also, my background is in geography and cartography, and I've been doing what I call culturalization work in the game industry for over 20 years. + + KENT: Wow, yeah, really interested to hear about your experiences there. Very cool. Omoju? + + OMOJU: Hi everyone, my name is Omoju Miller. I just finished my PhD from Berkeley in Computer Science and education-- + + KENT: Congratulations! + + OMOJU: Thank you! I have 15 years of AI background, studying how people learn, as well as making machines behave like people. I am currently the head of a board of advisors at a very interesting start-up that I'm super excited about, Learner's Guild. + + KENT: Very cool, yeah, I know that lots of us on the show regularly really care about learning and education, so that's great. Steve, why don't you go next? + + STEVE: I'm Steve Andrews, I am the founder and executive director of Platinum Bay Technologies, and we are a software company specially designed to employ technically capable autistic adults. + + KENT: That's a noble cause. Thank you for doing that, and we look forward to talking to you about what we can do practically to help people of all backgrounds. Great, so yeah, let's go ahead and get into our conversation. I think there are kind of three things that I really want to make sure that we cover with this show, and that is first, the science of, well, kind of the data aspect of how important it is for us to be aware of other people and their differing backgrounds and you know, just being empathetic of others. And then to convince us all that we can actually make a difference and improve other's lives and our own so that, like there are actually things we can do. And finally, to give practical tips and ideas of things like specific things that we can do to improve our community and help be more inclusive in that way. + + Just to kind of get our conversation going, what are some data points around, like the different people in the tech space? Like why, I'm having a really hard time starting out this question, (laughs) but yeah, what are the different, like people in tech? Like why do we care about these different people in tech? + + OMOJU: I guess I'll go for it. So the demographic landscape right now is pretty much, I think it's around 20 or 15% are historically underrepresented people. And those include women, people of color, persons with disabilities. And so basically a majority of the technical workforce is white and Asian male, so we have that demographic well represented, but everybody else is underrepresented. And everybody else is around 70% of the American population. So just from a workforce development perspective, it doesn't make sense to leave out almost 70% of the population, especially when there are so many technical jobs that go unfilled in the United States. So just from an economic perspective, you just have to solve that problem. And so that's who's there right now. And actually, that's not who's there right now, those are who graduate as technical people. Whether they go on to be there is another whole question. And when they do go on to be there, often within three to five years, they decide they are frustrated, and they leave the technical profession. So it's like a leaky pipeline. + + KATE: I can speak from the game sector. We at the IGDA, we do an annual survey we call the Developer's Satisfaction Survey, and our demographics break down in the gaming sector to about 20% women, and as far as people of color, it's vastly dominated by Caucasians at the moment. 76% of the people report that they are Caucasian descent. And so, yeah, the game industry has been, I guess, pretty well-known to be mostly white, mostly male, and that's been an issue for a long time, now. But when you look at the consumer demographic, like the figures from the ESA, in the US, the number of women playing games, it's almost parody with men, it's close to 50-50. Women are about 45% of the game playing population. And people of color are again, much higher than the people in the actual workforce. And so I know on our side, we're definitely looking at a situation where the workforce does not represent those who are actually consuming the products that are being produced by that industry. And so our basic goal in that case is essentially, we want to see that those that play games, or those who make games better represent those who play games. + + STEVE: From a disability perspective, for Autism, specifically, the current estimates are about 80 to some say as high as 90% unemployment or underemployment for Autistic individuals. Some of the highest unemployment rates for any "disability". And so, but I've talked to people who are paralyzed, people who have non-union fractures in their legs, which means the bone didn't grow back together correctly, and mobility is limited, and they're super talented folks, but they can't find work. + + KENT: I think that, Steve, you kind of touched on part of where I wanted to go next was, and this sounds awful, and like, I don't mean anything bad by this, but my next question is why should we care? Why do we care that there are underrepresented groups? And obviously, I do care, but I think that's an important question that some people may have. What makes the difference whether these different groups are represented well in the tech industry? + + STEVE: I think it's, you know, the same reason as it is for disabilities as it is for gender and race and any other segment of the population is everybody brings a different mindset, everybody brings different capabilities, everybody brings... and ultimately, if all lives are equal, everyone has value, and why not be inclusive of everyone? + + KATE: Well, you know, I think from a creative perspective, in the game industry, one of the biggest phenomenons over the last several years has been the rise of Indie game development, mainly because the tools for creating games have become really cheap or they're free, and that has democratized game development in a way that we've never seen before. So basically, almost anyone who has even the interest in creating a game can do so by just getting the tools and downloading it if they've got the technology, they've got the computing technology, they can start making games. And so a lot of the resurgence we've seen in the game sector recently, while we still have major blockbusters, just like the film industry does, like, you know, you've got your Grand Theft Autos, and Call of Duty and Halos and all that stuff, but the real interest in the game industry, sort of a renaissance has come from Indie games, and a lot of these Indie games are being produced by people who don't represent the typical demographic of the game industry. We're seeing a lot more women and a lot more people of color creating games and bringing their perspectives. + + And so, to the point where it's changed the industry. So like, with the last console launches, with the PS4 and the Xbox One, you know, Microsoft and Sony were bending over backwards to create a platform so Indies could publish on those consoles. And the reason they did that, from my perspective, is that the companies realized that the innovations in content and the innovation in games are coming from the Indie game sector, which is a lot more diverse than those who are actually creating the big AAA games. We're gonna continue to see this as time moves forward. I think it's really exciting to see. And what it's showing is that having this much greater diversity and voices creating games because games are an art form, we're actually seeing the game sector kind of have a resurgence, and renewed interest as well as a greater reach to a lot more people. + + KYLE: So I had a question. The statistics that were quoted just a little while ago about, you know, 20% identify as women and 80% identify as men and that sort of thing. And particularly, the racial demographic statistics, like how many people identify as Caucasian and that sort of thing. How much of that is centric to the United States, versus, or incorporating all of the world? Because I, for example, have trouble, just my own personal mindset, I have trouble believing that if we incorporated the billion people in India that use the Internet, but maybe use a more little, like feature phones, if we incorporate all the people in South America, all the people in China and all the other parts of the world, I have trouble believing that the usage of the web really is so heavily skewed towards Caucasians. And I don't mean that to say I'm somehow a minority, but I'm wondering how inclusive are we actually being in that statistics gathering. And does is that too big of a chunk to bite off, or should we be thinking about it in that bigger global sense? + + OMOJU: So I can take this one. From a global perspective, the racial demographics, they change, but one thing that is almost to the point of being a cultural universal is the gender demographics. So for example, if you go to the African continent, sub-Saharan Africa, so I've done this analysis just to understand, like I used to be at Google.org, and this was part of my position. I was the Computer Science Education specialist. So thinking about this from a global perspective, let's say we wanted to solve this problem for the entire world. And let's say that you want to actually pick people that look like me, which are women of African descent, there are three major places you go to. You go to the United States, 30 something million people. You go to Brazil, 40 something million. Then go to sub-Saharan Africa. All those places, women are vastly underrepresented in technical professions, in the professional side, as well as on the education side. So you will have men writing code, you still won't have any women doing any of this stuff. And those places, half the population of those places are also female. + + The same thing we see in China. India is slightly different, you see more women in India. However, once they cross over into industry, they get stuck at a lower level. And by the time you get up to mid-management in technical professions in software engineering, all the women are gone. They've gone to the business side of the company. So now you have your VP of marketing, VP of sales, they can be women, you know. But somehow, still in engineering ladder, they've still disappeared. And India is pretty much the light of the world when it comes to advancement of gender equity in technical professions and they still have challenges getting women up the ladder in engineering. So it's almost like there's nowhere in the world really solving this right, except for a few middle eastern countries, whose culture actually helps this problem better because they set up systems where women and men, they don't work in the same environment, so therefore, they've done remote employment very, very well. And as a result, women can advance further because they never have to go to work and be in the presence of men. They work from their houses and from their centers. And so, very few countries, though, they're just very small specs. Beyond that, in places where men and women freely interact, those problems persist. + + BRIAN: I was curious if, see, you kind of hinted on a possible solution there, but do you have ideas about, you know, top causes of, you know, the reasons for these statistics, and you know, the underrepresentation, you know, just basically the root causes that you think are most important? + + OMOJU: I mean, this is not even rocket science. It's just very simple things, as simple as everybody, you know, you grow up, you're a little girl, and you want to climb a tree, and people say girls shouldn't climb trees because they wear dresses. It's un-ladylike. So it's just silly cultural things, and that kind of carries over into mathematics. And people have, like a math phobia, even though computer science or writing code is not that math heavy. And so those kinds of small little things just sort of persist. And most people, most humans, the strongest urge is the urge of belonging. They want to feel like they belong wherever they are. So for a lot of people, you have to be one of the first few to really break through. And for most people, they don't want to spend most of their life being an extreme minority. It's like, why? And the people who want to do this often have the technical and intellectual acumen that they can easily switch to other professions and crush it. So it's kind of hard. It's like, you're smart enough to do anything, you can still make just as much money and not be underrepresented. Most people are gonna be like, "I'm gonna leave." So that's the hard problem we actually have to solve. + + KYLE: So there's lots of different societal-- + + BRIAN: I think Kate's, Kate's talking but was muted. + + KYLE: Okay. + + BRIAN: (laughs) Just mentioning because I see her mouth move. + + KENT: Kate, there's a hot key command to your control key to mute and unmute yourself. + + KATE: Yes, for some reason it muted itself, so sorry about that. Yeah, I mean, just to add to that, one of the big challenges we have, I mean, we know from the tech sector, from the history of the tech sector, that it's predominately male because it came out of you know, hard, computing science way back in the '50s and '60s. And that was a very male dominated field, even though a lot of early code, and a lot of, there were a lot of innovations that were done by women who were working in the computing science sector at the time. But it's just historically, it just remained a very male dominated space. One of the problems we're seeing, like on the game side, for instance, is that we see young women like in elementary school, like girls are extremely excited about STEM subjects and they grasp it really easily, they get super excited about it, and we see this amazing precipitous drop-off in middle school and junior high. + + And it's almost a universal phenomenon across the board, not just in North America, but globally. And a lot of it is due to, you know, hitting puberty, there's a lot of social pressures. And like was stated, there's a lot of cultural pressure that gets added when a young woman is starting to grow up and decide what she wants to do. A lot of times, either the cultural reasons or just social pressure, it's like, "No. Don't be a geek. Don't be a nerd. That's not a cool thing to be. Go do this instead." And so one of the big challenges we're seeing is that in that age range, in that middle school age range, we see that drop-off. Because then those who actually "survive" it into high school and into college, they maintain an extreme interest and go on to pursue engineering and technical fields. But trying to stop that huge drop-off has been a major, major problem. + + KYLE: So, society has got, has made suggestions for a lot of different solutions to these structural bias problems that I think all of us here fully admit exist and a lot of people listening probably admit exist. So we don't need to prove that they exist, but there's a lot of different thoughts on what is the appropriate response to an observation that these things exist. And I would like to actually discuss, more concretely, the gap that may exist between those that believe that if we see that there's a problem with gender in tech, or there's a problem with racial diversity in tech or other things like that, that to fix those problems, we have to, those of us that care about it, have to actually go out of our way to increase, you know... I'm thinking in terms of like when a conference organizer is trying to have a diverse conference, so they actually have to go out of their way to invite people of color, people of different gender persuasions and all of those things, because it's not just enough to have an open field and say, "Everybody, come join me if you want," because the structural problems prevent those people from coming in the first place. So there's that side. + + And then, there's the other side that says technology ought to be a meritocracy, and everybody's free and we're blind to the issues of race and gender, and the best ideas win. There's a huge gap between those two fields. And I sense that that is one of the biggest reasons why people hate the word diversity and they hate the word inclusiveness. And they feel put off by those terms because they think when you talk about diversity and inclusiveness, you're saying you have to be in one of these two camps. So how do we deal with those two fundamental, and maybe there's more than that, maybe it's more modal than that, but how do we deal with those two fundamental camps of how to solve this problem? + + STEVE: I don't think it's, for the second camp, it's not possible to just be a free for all meritocracy. We all have our own inherent biases, and we all have our own privilege. And the crazy thing about privilege is when you have it, you don't see it. And so, I am a white male. And I've just been learning in these last few years about the privileges that I have that those who are not white or those who are not male may not have. At the same time, I'm learning about, in my story, I was diagnosed with Asperger's about four years ago. So I'm on the Autism spectrum and I've been learning about ways that I may not have privilege compared to others. And so we all have inherent privileges and disprivileges that form a bias in our minds that make it difficult to say we're gonna turn a blind eye, and we're gonna have a meritocracy, and we're gonna be fair. + + KYLE: Isn't that one of the cases where... and I'm trying to make sure that both sides here are represented, isn't that one of the cases where somebody would argue that if the level playing ground meritocracy thing isn't working, it's because we're not focusing enough on turning a blind eye to those differences and letting people come in as they see fit. Isn't it really just, we have to do that more? Or why isn't it not that we have to do more, and we have to have an entirely different strategy? Like for example, you know, society has had Affirmative Action, for example, which is creating laws specifically to go outside of the normal fairness realm and try to tip the balance back. So does tech need to mirror what society has done? Or can tech simply say, "We just need to get more and more pure, more and more meritocracy?" + + KATE: One of the things that I would mention is that it's been evident in the last couple of years that one of the big issues in the tech sector is unconscious bias, and we've seen Google and Facebook and other companies be very overt about creating training around unconscious bias within their companies because they realize that, you know, and this is the situation, I was at Microsoft for 13 years, and I saw this happen quite frequently, is that like Steve mentioned, I mean, we do all have inherent biases, and a lot of times, we don't recognize them, we just can't see them. And so I know in the hiring process, for example, a lot of time you'll get hiring managers who, as people, they may not be overtly biased or have any, you know major concerns about any race or gender or anything, it's just that it's a human propensity to hire people or to have people around you who are like you. Or, if you have a team that, for example, is mostly guys, then there... and I've heard this more than once, where a hiring manager will say, "Well, I'd like to hire a woman on the team but I'm afraid that she won't be a good fit and she might be disruptive to the team." Which is, part of that is ignorance because there's been sociological studies that show in that situation, you add a woman to a group of men, and actually their performance improves because it kicks in this natural anthropological competition around her, you know. So that's kind of a misperception. But I think a lot of these companies are realizing that they need to address unconscious bias as one of the issues that they're facing where they just need people to be more aware of making conscious choices between qualified candidates and not just going for that default of hiring someone like themselves. + + STEVE: Yeah, I think for unconscious bias, I read a story, an article recently about black children in the education system and how they are more likely to be given, to be expelled or to be given detention versus white children because they found an inherent bias to view them as older than their age. And so, we all kind of have these inherent biases in our head. From the disability perspective, especially from, it's easy when you see someone in a wheelchair or someone with a cane to see, "Oh, they need some assistance. Let's help them out." But there's an unconscious bias... and we'll talk about Autism for a sec, if someone comes into an interview and they're very monotone, even more than me, and they perseverate and they don't make eye contact, there's a social bias as well. People talk about team fit, and that person may be an excellent programmer, but because of the social stigma, the social bias, they're not gonna get the job. + + KYLE: So beyond just feeling an ethic like we should fix these problems because I deeply feel that ethic. I have taken actionable steps in my career to try to speak out on this topic, so I'm not one of those that needs to be convinced from a morals perspective that we should be working to try to address the problems, but this is a podcast about the data behind it. So is there any data that lets us know the efforts to, you know, as those two camps that I talked about just a moment ago, the camp that says, "we need to go above and beyond," versus the camp that says, "no, we just need to be pure and level playing field." For the first of those two, is there any evidence that efforts in those areas have actually made a difference? Or are they just looking good PR-wise, but they aren't actually moving the bar forward? + + OMOJU: Yeah, so let me, part of the research I actually did for my PhD was studying this phenomenon from the data perspective, as well as the psychological perspective, as well as the social perspective, so we can have it all together and actually know what is actually going on. The interesting thing that I found in the research that I did not even know existed was majority of the students of color, especially African-American students I spoke to, at the undergraduate level in computer science, majority, over 80 or 90% of them had participated in some summer program for wannabe engineers when they were in high school or something. It just kept coming up over and over, and over and over again. It basically seemed, I hardly met a student that had not participated in that kind of a program. So that shows that those programs, they do bear fruit ahead in the future, but the issue is, you need to do a longitudinal study to figure out the efficacy of things like that. So you came up with a program in 1985 or 1990, you got to wait until like year 2000 or something or beyond to see what's happening with the students in the program. + + And also, research around this kind of issue, especially around the issues of equity with respect to underrepresented persons is sort of new-ish. Historically, there hasn't been a lot of data. If you dig into the research and say, "I want to learn about the experiences of African-American women in computer science," the number of research is so low that you can't even pull from it. So even the area itself is under-researched. So it just becomes a compounding issue. There are not enough researchers researching it because everybody that was already doing research did not finish that demographic. And so it wasn't a problem that their brain said they should wonder about, so there's not enough research in the area to begin with as well. But there is enough research around issues of gender. And it has shown, over and over and over again, there are tons of research, especially from Harvard Business Review and Harvard Business School, of the impact of women in teams and how those teams often over perform versus other teams. And more interesting with respect to Silicon Valley and venture funding, companies that were venture funded that had women as part of the founding team often perform better for their investors. So like, it's just pretty much from an investment perspective, if you are part of an investment team, or you are VC and you are funding things, and there are no women on the teams, you are basically going against your own interest. If you want to make money, make sure that there's at least one or two women in each team that you're funding. And you can actually track the data and run analysis and see that outcomes are better in your favor when women are on those teams, especially when it comes to things that have to do with money. + + KENT: That's actually kind of interesting to me. So is it the fact that, like, I guess this is more of a question of, like are women just more capable? Or is it better to like is the reason that they're so successful because they have more perspectives and more diversity in the team? Is that what makes it successful or is there something, like inherent about, like if it was a solely, only women team, would that perform better than an only men team? Or is it more about diversity in the team? + + KATE: Just a couple of quick comments on that, I mean, one thing is that there is a VC here in the Seattle area who came out, I believe late last year and he said that going forward, he's only going to fund women run companies. And the reason he said that is it's the women run companies who actually come through and do exactly what they say they're gonna do. And he said a lot of the male run companies, they don't always deliver. Sometimes they use a lot of BS, say, "No, everything's fine, everything's fine," whereas he found that the women are much more honest about where they are with their business strategy and with their progress. And so he just openly declared that from moving forward this is how I'm gonna spend my money. And that was kind of a bombshell. A lot of people were like, wow, that's kind of big news that he would make that kind of overt decision. But he's saying, "Look, it's just purely about results. I get results from women run companies." + + Now, I personally think that some of the factors that feed that is that women, a lot of women especially who are in this sector are we realize what the challenges are, and a lot of them have fought their way to get in this sector and have stayed in this sector despite a lot of challenges, whether it's open harassment or unconscious bias, or whatever it might be. And what I find with a lot of my friends in the tech sector, there is a certain, kind of inherent tenacity that comes with wanting to succeed that may not be as quite inherent in a lot of men who are in the sector. And it's true not just women, but also people of color because the barrier has been there, and the perception that it's been a lot harder for them to get ahead, to get the position they want and everything, there is a drive that I think is pretty unique to people in that situation. And you see that it's not just about gender and ethnicity, either. I've seen that a lot in people from emerging markets for example, who want to rise above their economic situation, there's a level of drive there that you generally don't see in developed countries where people have it "easier." + + KYLE: I think we can probably all agree that the constituency that is served by the tech industry, meaning just about the entire world's population is, by definition, incredibly diverse. And we can also admit that it's a really tiny percentage of us that are actually participating in the building of the stuff that the rest of the world consumes. So it stands to reason that the more diverse those teams are, the better they can address those concerns. But beyond reason, what data lets me know, for example, that if I build a team that has somebody with disability challenges on it, that my team is going to be better able to serve that part of the demographic? And if I have a team that has someone of color or, you know, multiple people, I don't mean like token, I mean multiple people of all of these different groups, that my team will be better able to serve it? Beyond just, like intuition, what data tells us that? + + OMOJU: So your team, for example, if you had a team and you had persons of color, it is not the case that automatically they'll be able to solve problems and attract customers who look like them. That is not necessarily true. What happens is, it's the diversity of points of view that creates a product that speaks to more people. So we've seen the same exact kinds of things actually happen in technical curriculum that is culturally relevant. So for example, you're trying to do like a data science module on rap or something like that, the idea, most people would think, "Oh, the black kids will love it." Not necessarily the case, not necessarily true. What that does is, basically gives everybody permission to be more creative and to start looking at the same material from more perspectives. And what you get with that is a richer, better product that reaches out to way more people. And that's what you just keep on getting. And overall, you keep building better, better products. And better products talk to way more people. Black people don't necessarily have like special black people problems. They have the same kinds of problems that most people have. But if you design a product in a way that allows for multiple perspectives, you will attract multiple kinds of customers. + + KYLE: So if I went and built a team that had a white dude from every single continent, and now my team has "diversity" because now I have people from wildly different cultures, wildly different backgrounds, speaking very different languages and all, will naturally out of that group arise the awareness to understand issues that perhaps would include the women's perspective and racially diverse... I mean, will it just come because I had a bunch of different kinds of white dudes? Or don't we need more than that? + + KATE: You need more than that because, I mean, if you still have white dudes from all over the world, how are they gonna have the women's perspective, for example? Or how are they gonna have the sub-Saharan perspective? You know, you do need more than that. And I actually need to leave in a second, so I wanted to put out this one last comment. So last year, we had IGDA hosted what we call our Leadership Summit, and our keynote speaker was Kristina Reed. And Kristina was a producer at Disney, and she's won three Oscars. She was a producer on Big Hero 6 and the shorts Paperman and Feast. And she gave this fantastic talk about what inclusion means in the creative space and in the creative process. The most interesting part about her talk was that she did not address racial diversity, she didn't address gender diversity, she didn't explicitly address diversity as we know it. What she was talking about with inclusion is the inclusiveness of thought and inclusiveness of opinion. + + And so what she outlined, and what she, and you know, this is, yeah, it's not hard empirical data but it's qualitative data that resulted in three Oscars, so the highest accolade for her field. In every one of the projects that she worked on as a producer, they took the approach that every single voice mattered. Every single voice in their office mattered. It didn't matter if you're the janitor, if you're the receptionist, whoever you are, she said when they did idea sessions, they brought every single person into the room and encouraged everyone to speak up, and made it clear to them that this is an absolute level playing field in this room, and every idea and every piece of feedback matters. Now, obviously the creative leadership team on those projects, it was their job to then parse which ideas where actually gonna be, you know, applicable to the project or not. But it was really interesting that she outlined this approach about inclusion in the most broadest context, and that resulted in enormous success for them. So basically, the message there was that the more diversity you have in that room, the better your inclusion is going to be and the more likelihood you're gonna get voices and opinions that you just never would have considered. + + BRIAN: That's a really great action item. Maybe we should shift into some of those. I know you have to leave soon, is there any other action items that you can give us to, you know, advocate and help? I have the most amount of guilt. I'm the most privileged white dude in the world, so I need to do things to help out. And you know, I always see tidbits on Twitter and stuff, but what do you feel is the most important things I can do on a day to day basis? + + KATE: I think part of it is just pure awareness. And I know that's kind of cheesy to say, but honestly, in my experience, it's the number one thing. It's like, it's more than half the battle, is just making people aware of their own behavior. It's like in my culturalization work, that's exactly what I do for companies. I help them find political and cultural sensitivities in their content, so they're not gonna get in trouble, like have their product banned by a government or have consumers uprising against them. A lot of that is just being aware of the choices that they're making. So a lot of times, it takes someone, whether it's that individual or someone around that individual, who just simply asks the question, "Why is this company hiring nothing but white dudes? Why are we not looking at other candidates?" And a lot of times, you'll hear hiring managers say, "Well, I can't find the candidates. I want to hire people of diversity but I can't find them." And so, you kind of have to go down the rabbit hole and investigate, okay, so how do we find them? Don't just end it there and say, "Sorry, you know, that's the way it is," which I see a lot of companies do, but actually take the next step and say, "We want to find candidates that we can consider that are not just the typical demographics." You have to keep pursuing it, and not let it go. + + I think that, to me, speaks to companies making it a value and individuals making it a value that, you know what, being inclusive in that most broadest sense and trying to get as many voices in the room as possible is our goal because we believe it's ultimately gonna make our product better, which therefore means we're going to increase our revenue, which ultimately, that's the argument that you have to make with a lot of these companies is that you are broadening the appeal of what you are creating and broadening the perspectives that are feeding the creation of it. And therefore there's argument to be made that it can increase the bottom line, which that, for better or worse, is usually the only thing a lot of companies are gonna listen to, but it works. I guess I would just say having an overall consciousness of what they're doing and the actions they're taking is really critical. And with that, I'm gonna have to say goodbye. + + KENT: Thanks for coming, Kate. + + KATE: All right, thanks very much for inviting me. + + KENT: Yep, so I would like to continue on this train of practical tips that people can do. And if anybody watching live has any questions about anything that they could do, or suggestions even, I guess, just tweet the hashtag #JsAirQuestion and in a couple minutes, we'll go ahead and answer those. For our guests, do you have any other suggestions of things that we can do, practical tips to help improve the diversity in our communities? + + OMOJU: I think one simple one is, since most of us are on Twitter follow people who are not like you. It can be hard sometimes, especially if you have, like differing political views, you might find yourself getting slightly infuriated and worked up, but you got to remember that these are human beings as well, there's a reason why they think the way that they do. With more technology and more freedom over the content we consume, many of us have rolled ourselves into a bubble where we only hear from the echo chamber. So follow people who are not like you, and see if you are, someone like me who's a black woman, that means that I'm following persons who are, like Asian men, and white men, I mean, all kinds of different people, transwomen, just listen to that kind of conversation, and it helps you broaden your perspective of what their experience is like, so when that opportunity comes that you're building your team or you're mentoring people, you are no longer just mentoring people who look like you, you are mentoring a diverse population of persons. That's just an easy tip. + + KYLE: I, to build off of that same thing. I just wanted to share with the audience something that I've done personally. So for those who don't know, I've been on the conference speaking circuit for quite a while, and seen a lot of different things in a lot of different places. It was fun, but at the most recent Fluent conference, I was privileged enough to give a keynote and in that keynote, I essentially announced that I was stepping down from conference speaking specifically because I go to all of these conferences all over the world and I see a lot of the same people that look like me and think like me giving all the talks. And I don't see enough of that, and it's too hard, and I do a Google search, and I try to find different perspectives on a piece of tech, all I find are white dudes writing about it. I don't find other people. So specifically in the area of conference speaking, I decided to step away from conference speaking to make room for different voices. But it's not just enough for me to make a gap. I have to try to help fill that gap, so I'm actively looking for ways to try to encourage and mentor other people to step up, and hopefully inspire other voices to be in those slots. So whatever position you find yourself in, whether you're a conference speaker or you're a writer or whatever, you should be looking for ways to lessen yourself so that there's room and you can encourage other people to take that step up as well. + + KENT: Yeah, that's a great tip. Steve, did you have any tips or ideas of how we can improve our community in this way? + + STEVE: I think while we're talking about diversity, the overarching goal of our area I'm focused on is neuro-diversity. And sometimes, it can be more subtle than other types of diversity because someone may appear to be neuro-typical, they may appear to be... so I think awareness is good, but we also need understanding. We need to understand the individual challenges. And that's where, and this is controversial, but I step away from team first principles. And as was mentioned earlier, instead of talking about equality, equity is more important. What does each person need to be successful that may be different from what other people need to be successful? For people in the spectrum, that may be a dark, quiet corner. It may be clear and written instructions. It may be other combinations like those that then help them utilize high intelligence and attention to detail, intense focus, creative, out of the box problem solving skills, you know, things we should be hiring for in tech. + + KENT: Interesting, so you're suggesting, you know, maybe the 9-5 workday doesn't work great for everybody. Let's make it more accessible to, like regardless of what time of day works for you, and then also like, maybe some people are a lot, can focus a lot better when they're working from home, and so let's be more remote friendly, stuff like that? + + STEVE: Yeah, our entire company works remote, and for those reasons, sensory issues, social, political. And frankly, we by and large don't have set schedules. So I can often get more done between like 11pm and 5am than I can from 5am to 11pm (laughs) and lots of folks are like that. Why not let them do their best work? If you get your stuff done, I'm happy. + + KENT: Totally, I think that's good. I just started working from home and I totally love it, so I'm all over that. Cool, is there anything else, because like Brian, I am insanely privileged, and I want to know more things. We were talking a little bit about, Kyle brought up conferences and how they, lots of times they have to go above and beyond to reach out to specific people and invite them to come. Is there anything else that, maybe a conference or a meetups organizer could do to improve the inclusiveness of their event? + + STEVE: I think along with what Omoju said about getting involved with other, you know, following more diverse people on Twitter is, get involved in more diverse communities out in the real world. We tend to, as was said earlier, we tend to self-select, it's kind of our human nature, self-select for people who are like us, so go out and get involved in various diverse communities, whether it's gender or race or disability or whatnot, and get some different perspectives, meet some new people. A lot of times, there may not be a great intersection between our communities. + + OMOJU: Another thing I would add to that is to actually be an onboarding ambassador. So you might decide, "This year, 2016, I'm gonna focus on two persons and I'm gonna be their sponsor." So one of the things you can do is, if you participate in open source software, you can decide I'm gonna spend this year trying to onboard one or two people into an open source project, and make sure that the pull request gets accepted. So you are basically grafting them into the community. It's a lot easier to do that than to, like go big over the conference schedule because what you're doing is, you're becoming that ambassador that is actually welcoming people, and actually showing them real things they can actually do. If you get a pull request accepted, that sweet joy of success is enough to make people stay. And once you've mirrored that behavior, they go and do the same thing for other people, and that's actually how you change things. It's not some big magical thing in the sky, it's just one or two people. And one or two people over a year is something that you can do without getting mentally fatigued. + + KENT: Wow, that was awesome! That's a fantastic bit of advice, and definitely something that I could, like really practical for me. And I'm a huge advocate for being welcoming and inclusive in open source, so great, yeah, thank you for that. We're coming down on our time, so before we... we don't have any questions on Twitter, so we do have a little more time, but before we get into our tips and picks, is there anything else that anybody would like to bring up before we-- + + BRIAN: I would, really quickly, just wanted to make one comment. You mentioned Omoju, that people don't like to be, you know, in a place where they're the minority and it's not really comfortable. But as we make these efforts, it's kind of, we have to get over that initial hump. And I don't know if you have any tips or ideas about how to maybe, initially attack that issue to get a few people so they don't feel so underrepresented and out of place. + + OMOJU: So one of the things I actually advise people to do if you're in a position of, you know, hiring manager, or even at universities looking to hire professors, instead of hiring one person, why not just wait, get your recs together and hire four or five at a time. So immediately you bring in, like a set of small critical mass, so you don't hire just one woman. Like, that's one of the worst things to do, because then she becomes the Barbie engineer. She'll just become the female engineer. She's no longer an engineer, she's like representing all women. But if you hired five female engineers at the same time, they're now engineers. And so, that might be very hard to do in big companies, but smaller companies, especially if you have room, if you have enough power over your team, bringing in things together, three, four, five at a time is a lot easier for the sense of belonging than one person who happens to be the only person there for five years. Like, you're asking that person to do a lot. And they're fighting so many demons in their head, you're actually not getting the best production from them, so it doesn't even make sense for you as well. You want to bring someone in, and you want them to be in an environment where they can do their best job. You don't want them to come in there and start to, like fight some kind of civil rights battle. That's not what this is about. + + BRIAN: Right on. + + KYLE: I just wanted to share one other thought that occurred to me while listening to these other fantastically smart guests here. Again, building off of this notion of hiring, I believe very strongly, I think a lot of other people would agree, I believe very strongly that we, one of the things that holds us back is that we haven't fully admitted, as an industry, that the stuff that we do is not about code, it's actually about people. And that means that hiring needs to be more balanced in figuring out what we're looking for. We use these umbrella terms like "good culture fit." As a matter of fact, maybe you ought to find somebody that's not a good culture fit so that you can get a more broad culture. But at the same time, we don't actually have to say, "I have to have a single member of my team that represents every possible different view or there's no way for me to be diverse." What I think we need to look for is people that demonstrate, with their actions, that they are empathetic people. Even if they don't know a thing or don't personally have experience with a particular perspective, there are people that can be big enough to go outside of themselves to try to look for other sorts of input, and those are the kinds of people that we ought to be trying to hire more instead of just a guy who can write the algorithm fastest on the white board. + + KENT: Wow, yeah, that was great. And that's really challenging the status quo of like, "Well, we want to have people who fit our culture." I actually really like the idea of, "No, we want people who are gonna broaden our culture, make our culture more, like be able to have more people fit it." So that was great. I think we're gonna have to wrap things up. So thank you to our guests for coming on. Let's move into our tips and picks, and then we'll just wrap things up. We'll have panelists and me go first, and then we'll let our guests get into their tips and anything else they'd like to bring up as well. Brian, why don't we have you go first? + + BRIAN: Sure, I wish I had good tips and links that had to do with the show. I learned a lot today, and always have an open mind to things I can do to help. I threw just a few picks on here that there's PureScript miniconf coming up to check out. That's in Catalina Islands. And then I've been reading this Algebra Ch 0 book, which is really interesting. And I watched a great talk on, I guess, just programming architecture from Zach Tellman, that kind of talks about just metaphors the whole time, but it's really eye opening and mind expanding, so check it out. + + KENT: Cool. Kyle? + + KYLE: Yeah, couple of quick things. I have one tip, and it may sound a little bit out of left field or out of context, but those who follow me know, so my tip is write your code, every once in a while, maybe not all the time, but write your code as if it was intended for kids to read and learn. I've actually been doing this specifically because this weekend, I'm giving a workshop at OSCON kids day, so I'm going to be teaching a group of six through 12 year olds how to write JavaScript to make a game. And I've been intentionally trying to write my code so that it will be easier to help kids understand. And it's continued to broaden my perspective on what it actually means to have code readability. So I think it's a good exercise for everyone to kind of push outside of their normal thought process of like, optimizing for, you know, senior developers. + + A couple of picks for you. First is a resource that I actually found to be fantastic to pass out to people. I've already sent this link out several times now, simplified JavaScript jargon. A big long list of all the different acronyms and terms that we throw around, especially in the web world, and in JavaScript particularly. It's a nice little quick synopsis of each of those ideas to help somebody kind of get their brains into the right context. + + Another one, which I have been working on also as part of that game for kids day, I've been, one of the games I'm working on is Tic-Tac-Toe and I learned about the algorithm, an AI algorithm for having the computer play you in Tic-Tac-Toe, and it's called the Minimax Algorithm. So I thought that was an interesting algorithm, and I got to implement that. + + And finally, my employer, MakerSquare, I'm head of curriculum for them, we are opening up a New York City campus here in two weeks and so I'm super excited about that. If anybody listening is interested in tech schools that take learning deeply and seriously, check us out. + + KENT: Great. So I'll go next and because Kate took off, or she had to take off early, I'll give her tip that she left for us. So, for me, my tip, this is like, not even a novel idea or anything, but it's something that I've been doing recently is using reminders. So Google Inbox has reminders that integrates really well with, like Calendar and stuff like that. And so I don't have to keep things in my head. I just put it in a reminder and I forget about it, and it's just really, really nice. And Google Inbox, or I guess it's called Inbox by Gmail, but it's got a really nice system for that. So I recommend that as a tip. + + For my picks, I just ordered a shirt that says, "You can sit with us" on it. I was inspired by Brad Green at his Fluent Conf and ngConf conf talks. And so I've got a link where you can get your own. I think you have two weeks before they stop printing it, and so check that out. + + And then a really exciting tip, Irwin Datin, I think is how you say his name, I've got a link to his story here. He, a couple weeks, or like a week or two ago, filed a pull request on the JavaScriptAir.com website that added deploying the JSON data for the show information and stuff, and I was like, "Well, that's kind of cool, "I wonder what he wants that for." And he said, "Believe me, you're gonna love it." So he just told me this morning that he created a JSAir app, so a native app made with React Native for iOS and Android. And so the repo for the app is open source, so if you're interested in React Native, go check that out. And then download the app, it's pretty cool. + + And then, finally, my last pick is a talk by Joe Eames at Angular Connect, and it's called Becoming Betazoid, How to Listen and Empathize with Others in the Workplace. I think that's really applicable, and it was a fantastic talk, so check that out. + + For Kate, she has a couple of links here that we'll have in the show notes, but her tip is "be aware that you and everyone has natural bias." I agree with her, I think that awareness is a big part of this picture. I don't think anybody really intends on being a non-inclusive, unkind person. I hope that nobody would intentionally do that. I think a lot of the battle for those of us who aren't intending to be biased is just the fact that bias is really natural, and we just have this unconscious bias. So I totally agree with Kate on that tip. And I would recommend you check out her links in the show notes later for some more information about that. Okay, Omoju, why don't you go next? + + OMOJU: So my tip is always ask why, and never lose your curiosity, especially if you're doing something, like I do, with data science. At some point, you can dig into a problem to the point that you just want to find, you just want to make sure that your evaluation metric is just perfect, you want to increase the precision to just extra, to the point that you've actually lost focus on what the problem is. You always want to keep that perspective and ask, "Why am I doing this? Why am I over-optimizing this? Why? Why, why, why?" Never stop asking why. + + And my picks is four different picks. The first one is this great TED talk that I love so much and I think everybody should listen to at least once a year, it's called Danger of a Single Story. It's by the Nigerian writer, Chimamanda Ngozi Adichie, and the link is here. Another one is a newsletter called Tomorrow Looks Bright. That newsletter focuses on African-American, women of African descent and their creative artifacts, so the companies that they've built, the products that they've invented. It's very interesting, and it's very cute. + + The next one is a podcast called Call Your Girlfriend for long distance besties everywhere. It's fun, it's by And it's like a feminist podcast, but it's just so fun. It's fun, it's like laughs. And the last one is Recode Decode by Kara Swisher. I love her perspective on tech and the kinds of people that she brings in. One of my favorite episodes of Recode Decode was when she had a conversation with Anne Wojcicki of 23 and Me and talking about building a science company and dealing with the FDA and fighting regulation and helping to create that public, private partnership and founding this company and persisting over the years with awesome borderline science, bringing that to the masses. So those are my picks. + + KENT: Great. Yeah, we love podcasts here, so thanks for those recommendations. Steve? + + STEVE: Oh, I'm still trying to figure out how this works, but, I'll say that we are, at Platinum Bay, we are actively looking for folks on the spectrum who are in software. And we are looking for AngularJS folks specifically, along with a lot of other things. So people in your audience, feel free to reach out to us. + + KENT: Cool, I put that down as a tip for you, "Platinum Bay is hiring." (laughs) All right, great, this has been a great show. I think that, yeah, we can definitely do more things. I actually just thought of a tip, if I can be so pretentious as to suggest a tip for somebody as privileged as myself, for ways that we can become more inclusive. And I just wanted to mention, so one thing to combat the natural or unconscious bias that I try to do is on the JavaScript Air website, when I was adding the functionality for having the guest avatars on the shows, I thought, "Okay, well, I don't want to have to worry about ordering these in any particular order." I think my first thought was, "Well, who should I put on first? Like maybe the person who's most influential in the space or something like that." And then I finally decided, I don't want to have to make any sort of judgment call on that because unconscious bias would probably direct me to do something, you know, that isn't right. And so, instead, I just said, okay, I'm gonna sort it by Twitter handle, so alphabetically, by Twitter handle. And so now I don't have to worry about it. And so there's no, like unconscious bias at play, even in the sorting of guests on the shows. + + I think things like that, we can really just like, just like Kate said, I wish that she was here because I want to give her like a high five, but I just think we need to be aware that we have unconscious bias, and that awareness will lead us, and that desire to avoid that, will lead us to question whether we're acting in a biased way, or whether we could, and prevent ourselves from even being able to act in that way. Really, it's all about just being inclusive and being good people to others. + + With that, I think we'll just wrap up the show with a couple closing announcements. A shout out to our silver sponsors, Auth0 and Trading Technologies, check them out. They're awesome for sponsoring the show. And then if you have suggestions for the show, go to suggest.javascriptair.com. And you can suggest topics or guests or both. And then if you have feedback for our shows, go to feedback.javascriptair.com. And if you'd like to sign up for our weekly newsletter, you can go to jsair.io/email. And then remember next week we're talking about transitioning from REST to GraphQL with Lee Byron and Nick, I can't pronounce his last name, but I will next week. (laughs) And then, as always, follow us on Twitter, Google Plus and Facebook to keep up with the latest. + + And one final announcement that I should probably mention, we do have openings for silver sponsors, so if anybody out there would like to have their company sponsor the show, that would be awesome. You get a shout out in the show at the end of the show, and also a feature on the newsletter on a rotation with the rest of the sponsors. Go to, let's see... I should probably have this on here, but if you just go to the website, in the sponsor section there's a button for becoming a sponsor that gives you more information about that. So that's our show, thank you so much Steve and Omoju and Kate for all coming. + + OMOJU: All right, thank you! + + KENT: We'll see ya. + `, } diff --git a/episodes/2016-05-18/index.js b/episodes/2016-05-18/index.js index a9ef081..61352a5 100644 --- a/episodes/2016-05-18/index.js +++ b/episodes/2016-05-18/index.js @@ -66,4 +66,240 @@ export default { ], }, ], + transcript: ` + KENT: And we're live with JavaScript Air. Hello, everyone! My name is Kent C. Dodds and I am your host for this JavaScript broadcast podcast, all about JavaScript and the web platform. Today, we are going to be talking about transitioning from REST to GraphQL. And maybe not just REST, but SOAP. We might be talking about SOAP. That'd be interesting, maybe not (laughs). But, yeah, we have a couple of subject matter experts with us today, so I'm super-excited to be chatting with them. + + Before I introduce everyone, I'd like to give a shout-out to our sponsors. So first our premier sponsor is Egghead.io. They have a huge library of bite-sized, web development training videos. Check them out for content on JavaScript, Angular, React, Node and more. Hopefully, GraphQL coming soon, actually. I think somebody's working on that. + + And then Front End Masters is a recorded, expert-led workshop with courses on Advanced JavaScript, Asynchronous and Functional JS, as well as lots of other great courses on front-end topics. Check them out at frontendmasters.com. + + TrackJS reports bugs in your JavaScript before customers notice them and with their telemetry timeline, you'll have the context you need to actually fix them. Check them out and start tracking JavaScript errors today, at trackjs.com. + + And SparkPost is email delivery built for developers. Build something awesome with their Node.js library or SMTP relay. Start sending a hundred thousand emails per month, free with SparkPost at sparkpost.com/jsair. + + And finally, WebStorm. WebStorm is a powerful JavaScript IDE. It makes developers more productive with its super-intelligent code assistance for JavaScript, Node, Angular and React, and integration of lots of different tools. Learn more at jetbrains.com/webstorm. + + Great, so as a reminder this a live show, and so with that, we have the nice benefit of being able to engage you, the live viewers, and so if you have any questions, go ahead and ask those on Twitter, with the hashtag #jsAirQuestion. I'll have my TweetDeck up here, watching that. And we'll answer those questions at the end of the show. + + And as a reminder, we are a weekly show, and so we have another show next week, same time, same place, and it is Progressive Web Apps. I'm super-excited about the show because I think progressive web apps are the future and awesome and exciting. And so, yeah, we'll have a couple of guests on there. Henrik Joreteg, (I'm not sure how to say his last name. I should probably find out), Ada Rose Edwards, Nolan Lawson and Ben Kelly. So a bunch of different perspectives. It's gonna be a great show. + + And, yeah, that's it for my announcements. So, oh yeah, and then always, follow us on social media, Google Plus, Facebook, Twitter, all that good stuff to keep up with the latest. Oh, and I should probably also announce there is a React Native app for JavaScript Air, which is super cool. So on iOS and Android, check out the JavaScript Air app. So it's JSAir. + So, yeah, great, let's go ahead and introduce everybody, so we have for our panelist, Dan Abramov! + + DAN: Hi, everyone! + + KENT: And I will be hosting. And then for our guests, our subject matter experts, we have Lee Byron. + + LEE: Howdy! + + KENT: And Steven, oh shoot Steven, I didn't ask you how to say your last name. Luscher? + + STEVEN: Hey you nailed it! + + KENT: Sweet! + + STEVEN: Hi everyone! + + KENT: So awesome, yeah, so Lee and Steven, why don't you give us a quick intro to yourselves, who you are, where you work, what you care about and why GraphQL life matters to you. We'll go ahead and start out with Lee. + + LEE: Sure. So, hi, I'm Lee. I work at Facebook and started the GraphQL project four years ago, actually. And also led the effort to redesign GraphQL, and open-source it, last year, this time last year. So GraphQL is important to me because it's my baby, but I've also seen it do some pretty awesome things at Facebook and help us build stuff that we never would have been able to build before without it. + + KENT: Super awesome! Now that we're talking more about transitioning from REST, but I would really love a back-story on how you created GraphQL, or like where the idea came from. So we'll chat about that in a sec. Steven, why don't you go? + + STEVEN: Sure. Yeah, my name is Steve Luscher. I work at Facebook. I started for a year working on the Instagram Web Team and now I work on the Relay Team. And GraphQL to me, I've landed on the Relay Team, and I think it's sort of, it's sort of fortuitous because in the early days of React, people were really excited about building user interfaces, and they were like, "Oh yeah, declarativity. This makes so much sense." But then there's always, always this missing piece, you know, "Okay, well fine, I can build this beautiful declarative UI, but how do I get data into it? How do I ferry data back and forth from my server? How do I perform mutations," you know? + + And, in my last company, we were sort of grappling with this and sort of like circling the solution. And when I joined Facebook, you know, Pete Hunt, pulled me aside and he was like, "Hey, have you seen, have you seen this thing? This thing, Delay?" That was the code name of Relay, before Relay became Relay. And he showed it to me, you know, colocated queries in the form of GraphQL, that sort of looked like, you know, what your response format would be without all the values and you know, married together with React components. And to me, it all started to make sense. So that's why I was super-excited to join Relay and work together closely with the GraphQL Team. + + KENT: So yeah, I love the co-location idea, like colocate all the things. It makes things so much easier. Well, that's great! Cool, thanks for coming on the show, each of you. So to kick off our show, I think it would be great to get a baseline. I think most people who are really interested in this show, probably know what GraphQL is or at least have heard of it. But It would be great to get a baseline, so could we talk really quickly about what is GraphQL? And then maybe Lee, you can go into the background of how GraphQL came to be. + + LEE: Sure, GraphQL is, it's a query language, it's a QL. But it's a query language, not for a database, it's a query language for your application. And another way to think of it is, I've heard it described as nested RPC. So if you're familiar with RPC, then nested RPC is where you can do an RPC call, and then based on the output of that RPC call, do another RPC call, and then get all of the results sent back to you. It started at Facebook as trying to figure, just the same problem that we've been trying to solve for a long time, like how do you get data that lives on the server to the client and then solve all the myriad of problems that inevitably come out of that, right? The problem of how do you only get the data that you want, so you're not just over-sending data, which is especially important when you're on crappy network connections which is basically the default now that mobile has taken over web. How do you handle, multiple related resources? + + So this was a huge problem for us before when we had a more RESTful kind of API, where we needed to load newsfeed, and then we needed to load the users for the authors of every story. And then newsfeeds' stories often contain other pieces of information within them, and you just, you either get all this duplication and with like a super-custom endpoint, or you get these URLs, (oh my gosh, my lights just turned off) ...you get all these URLs that you have to go load and in a second run. And that's super annoying either way, right? + + So GraphQL is an attempt to solve those kinds of problems. And the origin of it was actually, Nick Schrock. So Nick Schrock's given some talks at ReactEurope before. He keynoted the last React Conference, so you can go learn about Nick. And he had this idea to take our existing server code and kind of expose it in as a raw a way as possible. Our server has this framework called ENT, which is short for entities. And it's a really simple ORM. And what he wanted was a way to basically write, like condensed PHP code, that you could then send to the server, which would run and it would be limited to only like getter functions, and it would run all those getter functions, and then it would send the data back. + + And so he showed me a prototype of this, and, you know, it was really, it was a super-early prototype, it was kind of janky, you know, regular expressions to parse the stuff, and like a pretty crazy executor. But it totally worked, and the idea kind of blew my mind. It was like, "Yes, like this is, this is so much better than what we were doing before. Let's figure out like why, how it's gonna break, like let's figure out how to make this thing work at scale." + + And so Nick Schrock, Dan Schafer, who was on the Newsfeed Team at the time and myself, got together to figure out how, how GraphQL should look, and then how it should actually point at our service data. And Dan Schafer, in particular, was pretty instrumental in that. On the Feed Team, he was the mastermind of how a newsfeed would integrate with GraphQL. And that was like actually a pretty, pretty fast project. It went from crazy idea in the sky, to like a working server in about a month. And then a lot of the work after that was just getting our iOS up in a much better shape. And we launched the first version of our iOS app that hit a GraphQL-based newsfeed API, in the late Summer of 2012, so about four years ago. + + KENT: That's quite a history (laughs). + + STEVEN: I really love how... oh it happened to me too. I really love how Lee described, you know, straight off, it's a query language, not for your database, but it's a query language for your application. I like to think of like, you know, at Facebook we use one monolithic GraphQL schema, that describes everything you could possibly ever want to fetch. And it doesn't really matter if it's backed by, you know, a database or some, you know, microphone hanging on a window, that's like generating entropy, like it could be anything, right? It sort of describes your data universe, rather than any one particular storage back-end. And in this way, you can write a GraphQL schema (and I'm sure we're gonna talk about this later), that fronts pretty much anything. Like you can have some fields in a GraphQL query being resolved by (mumbles), you can have some being resolved by, you know, live video stream, or anything you can possibly imagine, that you can, that you can express in code. But fundamentally, what falls out of that, the response format is something that looks, you know, very familiar. It's a record, basically. It looks like JSON, behaves like JSON and it matches, very, very closely to the query that you just made. I like to describe GraphQL. Lee described it as a query language for your application. I like to sort of flippantly describe it as slick JSON, just without all the values. + + KENT: (laughs) Nice. So as in like the query language, itself, like you look at the query and it's like JSON without values. + + STEVEN: Exactly. + + KENT: Cool, cool. So on like, what we talked a little bit about the, you know, some of the problems that it solves, what are some of the things that, like, is there a point where GraphQL makes sense? Or like does GraphQL apply to all applications? Should everybody use this or is it a little bit more complex? Or does it add too much complexity to like a basic smaller application? + + LEE: So, I don't know if complexity would be the thing that I think you'd (mumbles) to use GraphQL. Actually, when we shifted from... so our iOS app used to hit a RESTful API server at Facebook, and it was a lot of code. In transitioning to GraphQL, we deleted tons of code. So it actually ended up being dramatically simpler from the client's point of view. Now that's kind of where we started. Since then, you know, it's been four years, we've built lots of really complicated tools on top of GraphQL because it gives us the stable base to build those tools on. So we've built up a lot of complicated things to do stuff that was impossible before, but none of that was required to use GraphQL. It was made possible by GraphQL. So, complexity, I don't know is the thing. + + We also, in talking to server engineers, found that GraphQL helps them organize their code, and shrink the amount of code that they had to write in order to surface an API. I've had to write like REST framework integration code before and it kind of sucks. It was like, it's really not too dissimilar from if you're writing an HTML-based website, where every endpoint needs to load, all the HTML for that page. Sounds simple, until you realize, oh you got to hit these databases in this order and then fill out this template and then do this and that. And, you know, it's enough work that you end up with at least a couple hundred lines of code. And those probably call out to functions, which are other lines of code that's all kind of manual stuff that you maintain. With GraphQL, the mapping tends to be pretty small. And if you think about, you know, each endpoint in your REST API, might be dozens, hundreds, thousands of lines of code, depending on how complicated that thing is, the corresponding GraphQL-type that it maps to, that you define those types, tend to be really, really small in comparison. So it's actually a simple find for us on the server as well. + + But to get back to your question about like where are the boundaries? Like where's a good idea and not a good idea? I think that depends a lot on the architecture of your application, the purposes of your API, etc. There's a lot of greatness about REST, right? One of REST's super-powers is that everything that one resource points to is a URL, which means any one resource can point to anything else on the internet. You can have two APIs hosted by totally different companies that know how to talk to each other via URLs. That's nothing that GraphQL tries to solve for you. In fact, doing something like that in GraphQL would be very hard, but it's because it's outside of the scope of the problem that are trying to tackle. But if your application is bend with constrains, if it's constrained on how many network operations it's trying to do, if it's constrained on the amount of code that's being written, to take the output of that no-network call when the REST API finally dumps you data and then parse that into model files or whatever. Like, if that's the focus, then GraphQL can actually be a great simplifier. + + STEVEN: On the topic of complexity, I wanna go two places with this. Number one, because you can introspect a GraphQL schema, for those who haven't used it, once you've built up a GraphQL schema, that describes your data universe in a nested way with fields inside fields, inside fields, like, for instance, users, posts, authors, right, sort of cyclic relationship. We have tooling that lets you inspect at every level. "Okay, I'm in an author. What's its type? It's a user. What fields are available on it?" And any client from, you know, someone who built the schema themselves, to a new intern who just joined your team, can use the introspection tools to understand, at a glance, immediately, what fields are available on user, what fields are available on posts. And this literally is available through and auto-complete interface. + + And I think these sorts of features lend themselves to, you know, increased developer velocity. You can move a lot faster when you, when you don't have to go, you know, swimming through server code to figure out, "Okay, well I'm hitting, you know, I'm hitting myapp.com/home. That's my mega REST endpoint. What does it return? Like what data's available on there?" You can introspect the query just at a glance using tooling. + + And another thing about complexity that I wanted to say was that because GraphQL queries are sort of composable, they're also fragmentizable, right? You can pull them apart... + + KENT: I love that word! + + STEVEN: ...into fragments of queries. And you know what, this is a lot has to do with relay, is push a lot of the complexity of data fetching, abstracting that away up into a framework level, so that you can do, you can do incredible things, like you can say, "This tiny little avatar widget needs to know this subset of this larger universe of data," like maybe the profile picture at 50 pixels and the link to the user's profile, right? And that's all it needs to know about. But because GraphQL queries are sort of intimately composable at the framework level, we can put an avatar into a post, into a list of posts, into a blog application, and compose that tiny fragment of a query all the way down into a larger query that we eventually send off to the server resolved however we resolved it. So these sorts of features have let us sort of abstract away a lot of complexity of data fetching, pushed them up into the framework level, so that you can move really, really, really fast and be able to jump into a small section of an application and have an impact without having to understand the entire system. + + KENT: Yeah, I think that it's really cool to see like more and more things moving to a more composable and like composability design pattern, where React's really pushed forward the idea of the composability of your different components. And then, you know, bringing that into, into our data queries, having composable data queries, it makes it a lot easier for us to like, I totally love, like keeping, colocating as much of our stuff as possible and so that when you, when you're a new developer coming onto to a team, you say, "Okay, I need to update the avatar widget or whatever." I just go to that avatar widget file and I see everything that I need to know about what makes that avatar widget work. And with, you know, the CSS and JS kind of movement thing as well, like, being able to have even the CSS, the HTML or JSX and the data stuff, everything that you need, just right there in that one file or in that one folder, all together, and the tests even, makes it so much easier to come in and make a quick impact. So it's really cool to see GraphQL all kind of enabling that. + + LEE: We've been using GraphQL at Facebook for four years, but this idea of colocated fragments is actually a relatively new one. This is an idea that Relay introduced and we're actually now taking that idea and bringing it back to all of our other platforms that use GraphQL. And it's been huge because one of the serious problems that we've had in our apps, that is a serious problem that lots of people have in their apps is just over-fetching, just like getting more data than you end up actually using. + + And as we've been going through components and writing fragments that describe exactly what those components need, and then ultimately replacing like master query files that say like, "Here's all the data you need for this whole view or this whole part of the app," we find that all of that over-fetching completely goes away, because we can write tools that say, "You wrote in your query here that you wanted this field. But then in the same file, you never asked for it." It's like the same kind of lint rule that ESLint can do. It's like, "Hey, you defined this variable and never used it." + + And the inverse is also possible, right? Under-fetching, where you end up asking for something on a model, but you never actually got from the server and then it just shows up invisible and you have a bug in your product. You can do the same trick. That's like using a variable without defining it first. Same lint rule. It's like, "Hey, you're using this thing from the model that you never defined in the query. Did you mean to put it in the query?" And it's been super-powerful to just completely curb over-fetching and under-fetching in our existing apps. It's something that, you know, really introduced that idea. Pretty cool. + + STEVEN: And another thing that co-location, sort of does, I love Greg Hurrell who works on, who works on the Relay Team with me, he gave another talk at Relay Deep Dive, Technical Talk. It's available on YouTube. I'll put the link in later. And he talks about, he talks about coupling. You know, is coupling bad? Is Coupling something we want to avoid? But, you know, fundamentally the model of your data, that author is coupled in a way that you can't, you can't avoid to the user interface. User interface demands that certain data is present. The data will hydrate the user interface. And what co-location lets us do is it lets us, it lets us sort of embrace that coupling, but makes sure that, that coupling occurs over a shorter distance, right? Literally within the same component, you know, component file or that boundary. So an avatar can now say, "Okay, I'm going to admit," you know, a therapy session for a component, (laughter) "I admit that I'm coupled to my data. But, you know, it's all right here and I'm declaring just the parts that I need." + + You know, before, you'd have to say like, "Okay, I need to render a profile picture," and then the front-end dev would have to go all the way back into the back-end, the REST API and be like, you know, "Is this the 50 pixel version being vended through /users, /id? If not you need to put it there, or put it behind a flag, that's like, you know, user/one with a little query param that's like include profile picture at size equals 50,100 or something like this." And that's coupling over a very, very large distance. I mean that's spans the network, that spans different technologies. If we're able to colocate the query and abstract all of that complexity up to the framework level, they embrace this coupling over a much smaller distance, which I think is huge! + + LEE: Yeah, and usually when we talk about coupling, we're talking about like separating technology concerns or separating functionality concerns, right? And one of the nice things that GraphQL lets us do is separate the concepts of actually like going to the network, and doing network activity from the data that we ultimately want from the network. So when you colocate, your GraphQL with your component, you're not like, it's code that's calling the network, it doesn't make it any less unit testable, right? It doesn't do any of the things that tight coupling costs you. And so maybe coupling isn't even the right word to talk about those two things next to each other, because it's not influencing how you end up actually talking to the network. As Steven mentioned, it lets us pull all that stuff away and do it somewhere else. So it actually allows us to more loosely couple those two things to each other. + + KENT: You know, that's a really interesting, interesting idea. And I think that, like maybe what we're kind of talking about here is dependencies and I guess that's why it's so, like in our minds, it's all about coupling. But like in the way that common applications are built now, you have kind of these implicit dependencies like this avatar which is implicitly dependent on the data it receives. And, yeah, maybe like it accepts all that data as props, and so you can make it explicit in that way, but it, it like, it doesn't really do a whole lot for you. I feel like GraphQL makes that just even a little bit more explicit. And then like, you know, in the same vein having like, we're really used to having CSS, like these giant CSS files that style everything in our application, but it's like totally implicit. And there's no like, it's you know, then we build all these tools to find out, okay what styles am I not using because it's implicit, like you have no way of knowing, for sure. So, yeah, I think it's really cool that GraphQL has brought that to our data. + + So we've kind of alluded to a couple of the strengths of GraphQL, or we talked about some of the strengths of GraphQL and that kind of has alluded to some of the weaknesses with REST. What are some of the other things about REST that make developing applications a little harder that GraphQL solves? + + LEE: I think it's actually pretty, pretty simple. I don't there's a lot of them. I mean REST does a lot of stuff really great, but the one thing that it tends to not do great is allow you to get all the data that you need, nothing more or less, in a single round trip. Many REST frameworks have like extensions that let you do variations of this where, you know, maybe if you ask for, maybe I have like an endpoint that gives me a list of my friends. And rather than just like simply giving me an array of URLs, which might be the like most straightforward REST-ty thing to do, I can ask it to like expand. I'm like, "Oh, actually expand, because I actually want to know the names of all my friends." There are a lot of REST frameworks that can do that, but what many REST frameworks don't let you do is say, "Okay, I don't want to just know the names of my friends, I also want to know the last group that they posted in." And by the way, for each of those groups, "I want to know which of my friends are in those groups. And by the way for each of those friends that are in those groups, I wanna know their name, and I wanna know who their best friend is. And I want profile pictures all the way." And you know you ask for all these dependent resources. I've never seen a REST framework that can do more than one level of inclusion of a URL resource without kind of cascading into over-fetching. GraphQL is designed explicitly to handle exactly that problem, where you have a mobile connection that's crappy, you have latency that's very long. And I just like the idea that you would have to do two network round trips, where the first one has to come back before you know enough information to do the second one, is just like completely insane. + + KENT: Yeah. That's what leads us to kind of breaking out of REST and making these one off endpoints, like, "Oh, I'll just make this one, so that I don't have to like do multiple fetches." I'll just say, "Okay, this is the data endpoint for this page and I'll get everything that I need for that page." And then, "No I'll just, like make that one exception." But then you wind up making a million of those. + + LEE: I've gotten in that exact same trap. It's like, "Okay, what we really need here is you know, we're trying to build the feed for our app, so we're just gonna have our API slash feed. And then that's just gonna give super-custom stuff that's specific to that view." But even that is kind of painful because what you've really done then is created a tight coupling between your client code and your server code. And then when your client needs to change because, you know, products evolve all the time, and you're like, "Whoops, it doesn't need to work that way. It needs to work this other way!" and you have to change the server, and you have to change this in lockstep. And if we're talking about a web app that's deployed as JavaScript, maybe that's okay. You might have to worry about, like a little bit of safety or someone has cached JavaScript and they're at your server but that might get by. But you have iOS or Android apps or any kind of deployed binary, once it's out there, you can't take it back, right? So you send that out and people are going to continually hit that endpoint expecting data to come in a certain way. + + And, you know, the last time that I had to build apps that way and I had to build API endpoints that just give custom stuff, we broke stuff all the time. It was just really hard and we ended up with these insane test plans before we could deploy where we had to look at every "supported" version of our client which just only grew over time. Even if you're like, "Oh, as soon as somebody has more than six-month old version of the app, then we won't support it," which is conservative, if you would launch your app every month, you're still talking about like six versions of your app that you have to go test on every view, to make sure that nothing broke when you changed an endpoint, which basically cripples the server team. And so that's why I like, when you talk to your API engineers, that's why they're so upset all the time, it's 'cause they're like every time something breaks, it's their fault. They have to fix it. So GraphQL also like helps us get past that problem where the client was responsible for describing what it needed, rather than the server implicitly having already having written that stuff out. + + The other thing that it ends up doing that's nice is because you have a semantic understanding of what that stuff actually is. As Steven mentioned before, GraphQL has a type system there and every point in that GraphQL query is talking about a particular type, a user, a post, etc. And so when you get that data back, you know what type it is, which makes it way easier to build a caching mechanism. You can say like, "Okay, here's this thing that claims to be a user, and here's this other thing that claims to be a user. I can store them in the same spot. I can do lots of interesting things depending on how complicated I want my caching system to be. I can start to make sure when I get a query in one place that has new information, that I make sure that it's updated in all the other parts of my view, etc." It's much harder to do that kind of thing when the server's contract is, "I will give you newsfeed and that will be JSON. Good luck to you." Right, like it's much harder to build a shared caching strategy around that. + + STEVEN: And it's paralyzing for developers as you've mentioned, you know, API developers, 'cause they jump into this endpoint like slash feed, and they look at it and there's all the history of everything that's ever happened to feed there. And they terrified to remove a field because they don't know what client's using it, who's depending on it. It's very difficult to find out who's depending on it because unless, you know, unless a graph of your code base turns it up, you might not even know what PC's interface is using that, whether it's being hit anymore or whether it even exists. Even the non-presence of-- + + LEE: It's a recipe for-- + + STEVEN: Yeah, even the non-presence of that in your code base, you're like, "Uh, is it really, has it really been deleted? I'm just gonna leave it here in this endpoint." And so you end up with these incredibly bloated endpoints, that contain, you know, they read like a history text of like every experiment that your company has ever tried and like failed and abandoned. And you know, these weird things like, at exp underscore one, underscore user, like, you know, some long abandoned experiment. As an exercise for the reader, I honestly encourage you, like fire up Charles, fire up an HTTP proxy, and put in front of your favorite, you know, app that you use daily and you'll find incredible things in there. You know, it reads like a storybook. + + LEE: Oh my gosh, one of favorite things of all time was, so one of our engineers, Adam Ernst, he is occasionally asked to visit other companies and gives talks about the kinds of things he's building at Facebook. And I think he, I think it was Etsy that he went to, and, you know, they didn't give a prompt. They were just like, "Hey, a friend of his worked there. Can you come talk to us and tell us about some of the cooler stuff that you're building?" And he decided that he was gonna tell them about GraphQL. So he set up Charles which is a proxying service, you can look at APIs. And he had his Etsy app on his phone hit Charles and then he just watched the traffic, and he basically reverse-engineered their API and then stepped through their API and then told them everything that we're doing wrong. It's like, "You're doing this. That's gonna be bad for these reasons." + + And then after he had like explained all this, then he like showed them GraphQL and he's like, "Okay, let's go back through all of those and show you how we would do that with GraphQL." And he like wrote GraphQL queries. He basically came up with like the whole GraphQL interface for them and then wrote it all out. And during the presentation, as he was like showing, you know, the folks in the room, they were like, "Yep, we do have that problem. Yep, what you said is correct. That did bite us." + + And so, yeah, he was just looking at it from the experience of, you know, he's an iOS engineer at Facebook, so he's watched the app go through this many phases of life. And he was a pivotal member of the team that helped integrate GraphQL four years ago, so he's watched the kinds of problems that you suffer from and been first-hand at replacing them with the appropriate GraphQL queries. But I loved it! It was one of my favorite presentations ever. I wish it was something that we could share more broadly, despite it being company specific. + + But Steven as you were saying, I think you can replicate this experiment for yourself, so whether it's your app or whether it's from your company or some other favorite app you have, hook it up to your proxy, just like watch what happens! You'll be surprised how chatty it is, how weird those endpoints look. Like, the insaneness of the API responses that are coming back. It truly is, yeah, like a history lesson of what that app has been through over the time that it's been released. + + STEVEN: And to your point, there are REST frameworks that try and eliminate these problems, or like make it easier. But in practice, time and time again, plugin that proxy and look. And that's what I see in practice. People are terrified to remove things, constantly adding things. And, you know, custom the entropy is this universe of custom endpoints, rather than, you know, rather than one unified one. That's the sort of entropy that we've tried to reverse with GraphQL, one unified endpoint that knows how to respond to every possible query, since time immemorial. It's amazing. If you have like an iPhone 3GS or something, sitting in a drawer, you know, go find one of those power adaptors and charge it up and see if you have the Facebook app on it. It's amazing that it'll still, you know, the GraphQL queries that are present in that, you know, three year-old version of the Facebook app, they'll still resolve today. And that's something that's really amazing. + + And on this flip-side, someone who's doing some cutting edge experiment, right now, in whatever product at Facebook, they're putting in all of these fields to do their experiment, and if the experiment fails, they can sort of just sweep away that client code with impunity and that query is now completely flushed from the system. It's not going over anyone's wires anymore. + + KENT: It's so amazing. I'm seeing, like I keep coming back to CSS, but I just see so many parallels to the problems that we have with CSS. That's just really interesting to me. So, let's talk about the actual transition period. I think we've probably talked enough about trying to convince people that GraphQL is a good idea and could really save people from a lot of problems with REST. So how complicated is it for... and I guess there's kind of two parts to a transition from REST, right? You have this server-side part and you have the client side, whether that client's written in React or Angular or Backbone or whatever. So let's talk about the server side first. How difficult is it for somebody to take their server and turn it into a GraphQL server? + + LEE: It's not hard at all. And here's the strategy that I usually suggest people do. And actually, Steven did a super-awesome talk about exactly this idea. Start on the client. So basically pretend that you're hitting a GraphQL endpoint, but all you're really doing is just running GraphQL, locally. And what that lets you do, is just play with it, right? 'Cause often what makes changing a client-server relationship very hard is that unless you're a very tiny company, it probably involves at least two people, if not more, right? You got to convince everyone that this is a good idea, and then you got to plan it, and then you got to like figure out how to deploy it. And there can be a lot of steps that need to happen, until you can make your first GraphQL query and be like, "Oh look, is it valuable for us now?" Like you really want a much earlier point at which you can say, "Here's a prototype. Check it out. This is what we can do with this." And you wanna be able to do that as like a one-man army so you can actually convince people, this is what it looks like for our data at our company. + + So, usually what I suggest is, take a look at GraphQL.js. We made our reference implementation of GraphQL in JavaScript, for the very reason that it can be run in so many environments. Run it in the browser. What you do then is because GraphQL is a query language for your application, what that actually means is every kind of field that you see in a GraphQL query, maps to a literal JavaScript function. There's a JavaScript function that will be called and it will return either a value or it will return a promise for a value, and that's it, that's the whole contract. So, that's great because it turns out that talking to networks is really easy, if you can talk about it as a promise for a value. You hit a REST endpoint, you get a backup promise for ultimately the like JSON payload that it will return to you, and then you can keep going. So you can write a REST wrapper in GraphQL with a fairly small amount of code. Everyone should watch Steven's talk, we'll get a link up to that talk where he does that exact thing, for three different programming languages in about 25 minutes, which is pretty awesome, for like a reasonably complicated thing. So it's not hard to do. Like you can do it, in an afternoon to try it out for like a portion of your app. Now, that doesn't win you the like network chattiness problem. All that lets you do is say, "Okay, now I can kind of see what it would look like. I can write queries. I can get responses. I can start to visualize GraphQL for my own data." But it's still being chatty over the network, right? It's still actually sending all those REST requests. + + The next step is to actually put that code on your server. And you could do that in a lot of different ways. If you have the ability to run Node somewhere, anywhere, you can just take the exact same code that you just wrote for GraphQL.js and run it on a Node server, still hitting the REST endpoints. You could even put that on Heroku or something, if your REST endpoints can be hit live, which I assume they can, if you're using them for your web app or iOS app or whatever. And that way, you can just kind of like spool it up on your own, just to kind of prove the point, and then show how the iOS app can now look, one round trip and I get all this data. And even better if you can do that in a way where you're colocating with data center. So if you use AWS, deploy it to the same cluster. If you use Heroku, deploy it to the same like Heroku cluster. That way, the calls to your REST endpoint are happening within the same facility and they're gonna be like extremely fast. + + And then the final step is to actually write, like remove REST from the equation and re-implement GraphQL. And at that point you can kind of do it kind of incrementally. You can go through kind of one type at a time. And basically the same kind of code that you would write to implement a REST framework is roughly the same kind of code you end up writing to implement GraphQL. And you can do that kind of one type at a time and then eventually you get to the point where there's no more REST anymore and you either keep that REST server alive if you have clients that depend on it, and you can have a brand new GraphQL server or you can remove it if you're no longer using it and then you're just on GraphQL all the time. But that kind of progression of try it yourself, you know, be a one-man army to test it out, test it totally on the client, just so you can kind of get a feel for it, then host it up somewhere, but still point it at your REST endpoints is kind of like a good one-two punch, for testing it out without requiring like agreement from lots of people all at the same time. And that will give you a basis from which to start to then convince co-workers that what you're doing is actually good. + + STEVEN: I love that progression. That's, you just laid it out so well. I wanna try and say exactly what you just said, like, just like, I wanna get super-tactical for people 'cause I did give a really, really, tactical talk. It's called "Zero to GraphQL," and you can search on it, where I sort of live-coded up one of these schemas. But this is basically how you can start, just as Lee said. There's a library. It's called GraphQL.js. There's a method, probably called GraphQL. It takes two arguments. It takes a string that represents the query, and a schema that you wanna execute against. So basically the string might look like, you know, in curly braces, me, curly braces, first name, email. Maybe you won't wanna get your first name and email. So that's the string. Second argument is the schema. The schema is where you locate all of these resolver functions that know, given a user-type, how to go get the first name and the email. And this is where you write JavaScript. + + In Lee's first example where you're just purely operating on the client, those resolver functions are probably gonna like make XHR requests to the server and hit your REST endpoints to get that user, you know, and pull out the first name and email fields and stuff like that. And that's like, that's the whole thing. If you can pull that in, write a query, that's just a JS string, write a schema using our schema creation libraries, that know given these types, where to go get the data for them, then you can go get started. So your, and the return value of this function is just an object. Basically, you can think of it as the JSON response that comes from the server. So you put in GraphQL query, a schema that you've crafted that knows where to go get that data, and it will return you a JavaScript object with the response. + + DAN: Do we have any Twitter questions that we want to answer? + + LEE: I think we do. I can see a couple Twitter questions coming in. + + DAN: Yeah. + + LEE: One of them is, one is asking what are the best learning resources for GraphQL? That's a great question. And to be honest there, it's actually relatively sparse right now. I think there's a lot of appetite for more resources to learn about GraphQL, which is on us to some degree. But the community is actually stepping up in a pretty big way there. So there's this GitHub account called awesome-GraphQL which lists out links to tons of different things, blog posts, conference talks, libraries, tools, that are all about GraphQL and they try to surface the best content. Also the Meteor Apollo Team, it's a Meteor company. They're building a new client and server that speak GraphQL and they've been pretty regularly writing about GraphQL and I found those to actually be really good, like introductions to GraphQL and the concepts. And then once you're familiar with GraphQL and you're like, alright, I wanna get into the weeds, GraphQL.org has a lot of, GraphQL.org has a lot of resources there as well. There's kind of like full articles, there's blog posts, there's just like API documentation. That's what we have now. It still, I got to say though, it's a little sparse. We need more, we need more stuff. + + DAN: I have a small question. Can you tell me, what is the difference between Relay and this Apollo thing? Are they both libraries on top of GraphQL? How are they different? + + STEVEN: Yeah, that's a question for me. Super-embarrassing 'cause I have not played with Apollo yet, even though we've been in close conversation with the Apollo Team and sharing ideas, sharing ideas about Relay, sharing ideas about Apollo and sharing ideas about GraphQL, itself. But, unfortunately, I can't speak to the differences between Relay and Apollo, and their approaches. Yeah, because I've been in the weeds, working on, working on some stuff. But I very much look forward to being able to come up for air and check out what they're doing and seeing what we can learn there, learn from them. + + LEE: Yeah, I would add that, you know, there are a lot of trade-offs that you make when designing clients or when designing frameworks for data on clients. You can choose to be as simple as possible. You can choose to have really complicated caching mechanisms that do smart things for you. You can be very pluggable and have a lot of user-provided functionality. You can be very opinionated. There's all kinds of trade-offs that you can make. And even within Facebook, a lot of our frameworks make different trade-offs based on the kinds of stuff that people are building. + + So, our iOS and our Android apps, for example, are actually simpler than Relay. Relay does a lot of smarter things with the cache than our iOS and our Android apps were doing, and we're now kind of like learning from each other. So our iOS app is taking advantage of some of the caching techniques that Relay introduced. Also Relay introduced that idea of colocating fragments with the components that use the data. And that was a new idea, so we've been stealing that one in our iOS and Android. + + iOS and Android, themselves, have come up with cool ideas that Relay doesn't do. One of them is the ability to look at all the possible queries that your app could ever run before you ever run the app and then upload them all to your server ahead of time. So you can think of this like stored procedures for some, you know, some SQL databases have this concept. You get back, just like these really small keys, that represent those queries. And then at run-time, rather than sending up a big string that describes the whole query you wanna run, you can send up a key that represents that query which is gonna be much smaller bytes. And if you're talking about, you know, if you're optimizing down to like how many TCP packets are we sending in order to do this request, you can get a query that would have been many TCP packets 'cause it's a string down to one TCP packet for that outgoing request. And so now Relay is actually investigating what doing that would look like, within Relay. + + So there's a lot of these trade-offs. We're learning stuff, and we're seeing new GraphQL clients pop up in the community, mainly to take a different point on that continuum of trade-offs. So one of my favorites that's community-driven is called Lokka, L-O-K-K-A. And the drive on that one was to be as simple as possible. So basically what it does is it helps you construct your GraphQL query, and then that's it. It sends the query to the network. It comes back and you get JSON, and that's it. And one step simpler than that is cURL or XHR, right? It's like kind of the same that a REST endpoint would be, like you don't have to have a client framework to hit a REST endpoint. You just XHR it and then you get back JSON. GraphQL is very much the same way. Like if you point your GraphQL query as a parameter string and like send it, you'll get back a JSON payload, and that can be your whole client framework if you want it to be. It's just all kind of different points on the continuum of how sophisticated you want your clients to be or how simple do you want your client to be. + + STEVEN: Yeah, you reminded me, I think in conversation with the folks from the Apollo Team, they were definitely trying to find some different trade-offs than we found on the current Relay. And I think one of the things they're trying to do, is they're trying to make the simple things really simple. + + LEE: And one of the key differences between Apollo and Relay in particular, is the integration with other view frameworks. So Relay is unapologetically about React. Its purpose in being, is to tie together React and GraphQL. So the whole idea that Relay would do some other kind of view framework is just against its reason for existence. With Apollo, it's different. Apollo's reason for existence is not to tie React together, it's to create a common library for GraphQL. And so they wanna build integrations with Relay, sorry with React, integrations with Angular, integrations with Ember, to be more flexible. + + There are trade-offs with that, right? Like if you know that you're doing React, you can do really cool specific things that have a much tighter integration with React. If you know you wanna be more flexible and target other view platforms, then you have to curb that back and be a little bit more generic. That gives you that flexibility, but it also means there might be, you know, additional plugins you have to use or some other thing that has to happen in order to make that happen. + + So, you know, these are all just trade-offs that you can make, so I imagine that, I can't envision a future where there's only one GraphQL client. That seems like a failed future in my mind. I think we will see a handful of, you know, of the peaks and valleys of value along this continuum, that people just find all the spots where, where there's value. It's like, "Here's one that's really simple. Here's one that's really flexible. It can be lots of things. Here's one that's great for React. Here's one that's great for iOS," right? And we're just gonna see a bunch. I think that'll be awesome! + + STEVEN: This is why I'm really glad that these two projects exist, because, yes, Relay grew up unapologetically as a, you know, way to bind queries to React components. But I think what we're finding, you can take a look at some of our recent meeting notes for Relay or the Relay future repo, we're starting to think about how the concepts of like the client store and all of the other like abstractions that Relay offers. You know, whether we could whittle that down to a core and if React Relay could be a wrapper around that. So we're starting to explore these things. I think the existence of the Apollo project, the Apollo project (whooshes) (laughter) can only help, as we share ideas and like explore different decisions and different trade-offs. + + KENT: Great. , am I back? + + LEE: Yeah. + + KENT: Okay. + + STEVEN: Yes, you are. + + KENT: That was really weird. Yeah, that was great discussion. Thanks for carrying the stuff on while I had some weird things going on. So we do still have two more questions that I think are both relevant and interesting. S Daniel asks, "What is a good starting point for people with SQL background, only?" + + STEVEN: Yeah, this one's really great. There's nothing that we can particularly point to, except I wanted to point to this project called PostGraphQL. It's actually an automatic schema generation library for PostgreSQL. So it'll inspect a post-graph schema and try and generate a GraphQL schema from it. And I think if you're starting from SQL background, if you did that and started to see what the output of the schema generator was, then that's a good way to sort of slipstream into writing your own schema or customizing that schema further. + + LEE: Yeah. Also one of the things that we tried pretty hard to do with GraphQL is keep it very simple. So there are extension points to let us do more complicated things, but it's actually much simpler than SQL. And in doing so, it explicitly doesn't do some things that SQL does. And so if you come to it from a SQL background, probably the most important thing to know is that it's solving a very different problem than what SQL is solving. SQL lets you ask arbitrary questions about a series of tabulated data. And GraphQL does not do that. What GraphQL lets you do is ask, kind of going back to my metaphor from before, nested RPC. You can call a function on your server and get back the values, and then call more functions on the result of that, and get back the values, and ultimately come out with kind of a JSON payload of the results of all those operations. So the query language, itself, is simpler than SQL. And it's targeted to let you do only the things that, whoever built the schema, wants you to be able to do. So no, kind of arbitrary order-by's on an unindexed field that cause super-slow queries, which is actually another boon for server engineers and DBAs in particular, that you're not constantly hunting down, like bad queries and trying to go fix them, yourself. That's something that we haven't had to solve with GraphQL. + + KENT: That's great, awesome. Check that out Daniel! For Mike Williamson, our last Twitter question, "Why the split between GraphQL regular types and input types? Why are both needed?" This seems pretty specific. If you could give us a little bit of background. + + LEE: Yeah, so, we mentioned before that GraphQL has a type system. So GraphQL has a type system, both for the kinds of things that you can ask about. And, we didn't really talk that much about this, but there's this other concept of being able to provide inputs to some of these things. So a good example is, there might be a field on User called Avatar, a profile picture. And you might actually want different sizes of that thing, right? So I'd say, "Hey give me the avatar for Steven Luscher." And it's like, "Alright, here you go." And I get this 50 by 50 pixel image. I'm like, "Well that sucks, 'cause I'm on a quad retinal display, and I wanna like display this thing at, you know, 300 by 300 pixels." + + So what I really wanna do is be able to provide an argument, so if you literally think about that thing as like a function, where the function is get profile picture and the implicit first argument is Steven, the user object, and then the next argument needs to be "what resolution do you want?" And so for that you need input types. So input types, there's all like the scalers are the same, so, you know, strings, Booleans, whatever. But there are handful of cases where you wanna provide a complex and protects. You wanna provide and object with fields, as an input, or something like that. And this is relatively common when you're doing GraphQL mutations. And so these two type systems are different. The output types are your users, your newsfeed posts, whatever, all the things you can ask questions about and get answers for and your input types are all the input that you need to provide in order to get the right data back out. So these two things are different because they have subtly different characteristics. + + So one good example is those arguments. So a field has arguments in an output type, but in an input type, it does not make sense to have those fields have arguments. If you think about what the corollary is in a programming language, like JavaScript, a output type is an object that contains only methods, right? It's a class with like getter functions. That's an output type, and an input type is like a plain old JavaScript object that has some properties on it, with some values there, right, with no functions anywhere in it. That's kind of the mental model that I use to distinguish the two from one another. + + One of the other discrepancies is default values. So output types don't have a concept of a default value. Where input types, you can say, "Okay, here's, like a point in the world that has longitude, latitude and altitude. And altitude I don't always care about, so if I don't provide it, what I mean is sea-level." That's a default value. So now I can say, "Here's my point on the world, longitude, latitude, and that's it." And now we just, we know you're talking about sea-level. Output types aren't the same. You either ask for the field or you don't. There's no default value. So because there's all these discrepancies, we actually tried to figure out if we could make them the same. Are there cases where an input type, and an output type are just gonna be the same. And every time we tried to do it, there was just too many weird quirks and like bad-edge cases and just decided it was best to keep them separate. + + KENT: Cool, great thanks for that answer. So there was one more question, but we don't have time for it, so if you wanna check out that through the Twitter hashtag after, I'm sure Apollo would be very grateful. So let's go ahead and get into our, just wrapping up with our tips and picks. And we'll have Dan go first, then me and then Lee and then Steven. So go ahead, Dan. + + DAN: Sure, so let me open the doc (laughs). So for today's tip is something that is, I'm working on a new series about Redux, like more real-world patterns, it doesn't get as sophisticated as Relay. It's just talking to REST endpoint (laughs). But so as I was working on tutorial, I noticed the pattern I started following which is related to what we've been talking about, the co-location. So in Redux, what you often do, is when you often want to change, especially in the beginning as you iterate on the application files, you want to change the state shape of your application. Like, you want to introduce something new into the state shape. You want to store it in different way for, as an optimization or something. So this gets painful, if you have to hunt for all the components and all the other parts of code that rely on this specific state shape. So what I suggest doing is together with the reducer, right in the reducer files, you can put the selector functions that... they act as a public API for the state managed by this reducer. And just like you compose the reducers into separate files, and then combine them, you can also compose selectors and have selectors call other selectors, thereby ensuring that if you change the state structure this change is localized in a single file and you don't have to change any other components. So this is my tip for today. I linked to a comment, sorry, a place in the Redux examples where we used this pattern. + + And I have a bunch of picks for today. So my first pick is a new interface to OCaml language which Facebook released just like yesterday. It is a creation by Jordan Walke, who's the author, the original author of React. And it's like super-cool. I'm very excited about functional languages. And this is a way to write in a functional language with a mature tool chain, but in a syntax that kind of resembles JavaScript a lot, especially ES6. So it's a great way to introduce yourself to functional programming, in a comfortable way. + + Another of my pick is React Tiny Renderer. So it's a project that implements the minimal interface for a React renderer. You probably never need to do it in your projects, but it's a great learning exercise into like how React works internally and how the difference between ReactDOM and React Native is actually implemented in the code. And so this is a tiny renderer that just renders everything into JSON. + + So my next pick is a new course by Wes Bos, called Learn Redux, which is free. It's sponsored by Sentry. Big thanks to Sentry for doing it. So check it out. People say it's really great, so it must be great! + + And I have another pick with Mark Erikson's link collections. So with Mark Erikson is the person who came up with Redux Fact, where they ask questions and he has a really good collection of links in his GitHub profile. So check those out. + + And I wanted to highlight Apollo Client again, because people have been talking to me about it and asking have I looked at it. It integrates Redux with GraphQL and I haven't had a chance to look at it yet. So check it out as well. That's it! + + KENT: Great, a ton of awesome resources there. And I think, I don't know if you mentioned the actual name of that OCaml interface, it's called Reason. So good luck Googling that (laughs). Yeah, I had a hard time finding that one. Okay, great so for my tips, I'm actually gonna piggy-back on Dan's tip about colocating selectors. I'm gonna make it more broad, as colocate A-M-A-R, that's as much as reasonable. So try to get like your CSS and your GraphQL queries and your HTML if you're doing it, if you're not doing React like put your HTML right there. And like, yeah, just as much like your test files and everything, put it where it's being used. And so like even if you have multiple components, if it's only being used by one other component, you just like extract out, put them where they're being used. It just makes it a lot easier to think about this like structure of your application. So yeah, colocating is great! + + And then I want to pick, LGTM, Looks Good To Me. This a service, or it's a GitHub status bot, that will allow you to say, like, "This pull request can't be merged until two maintainers say, 'It looks good to me' or 'Ship it,'" or something. It's great. It's enabling some really cool things for open-source projects in the way of like automatic releasing and doing all kinds of really cool things, so I like it. + + Code Cartoons is really applicable for this episode, specifically our cartoon guide to Facebook's Relay. And if you're interested in more of the inner workings, how everything works this is a fantastic blog post from Lin Clark and so I recommend you check that out. + + And then Aphrodite. This is CSS and JS done right. I totally love Aphrodite. It is amazing. And so there are a lot of problems with doing in-line styles in CSS and JS, but Aphrodite gets around all of those by actually generating actual CSS styles and sticking those into the DOM. And so you can use media queries and pseudo-elements and all kinds of that stuff without doing some magic JavaScript stuff. So, yeah, it's fantastic. I recommend you check it out! Great, Lee why don't we have you go next? + + LEE: Just got to unmute myself. Alright, so I have one pick for the day and it's a book, and it's a new book that isn't out yet but you can pre-order it. And I've had the ability to read some of it before it's come out. And it's super-awesome and so I like super-can't wait for the whole thing to come out. It's called "Suspension." You find it at readsuspension.com to get a pre-order. It's super-cool. It's a sci-fi, political thriller book, that deals with zombies and reality TV and the presidential race. And it takes place in the United States in 2018. So it's like sci-fi, but it's like sci-fi that happens very soon from now, which is cool. Like I don't think we see that kind of writing that often. So I'm super-excited for that. Check that out! + + KENT: Cool, I'm looking forward to 2018. (laughs) Cool, Steven. + + STEVEN: Hey, I'm gonna do my picks first. My first pick is music. I want you all to take a look at an album, Hope by The Strumbellas. It's an old friend of mine, that I used to play in garages with back in Oshawa, Ontario. And now, that band's gone to Number One on the US alternative charts, for good reasons. Let's take a listen to that! It's gonna melt your face. + + Second thing is a book. It's called the "The Lost Chord," by Conrad Amenta. This is an incredible science fiction book about a world in which algorithms have completely replaced performers in the musical, it's for music. Nobody produces music anymore, only algorithms produce music. And it's an absolutely chilling view of the future, possibly the near future. + + And my tip is, my tip is about resource contention. Particularly, about America's highways and roadways. I'd bike to work every day. I live in Menlo Park, right near Facebook's office. Takes me 16 minutes to bike to work each way. It's a hundred percent flat because it's Silicon Valley. But there are a lot of four-way stops along the way and this message goes out to pretty much everybody that bikes, specifically Californians. And I wanna give you a little tip for negotiating a four-way, three-way or an end-way stop. Here's the rule, basically. If you arrive at an end-way stop at the same time as one or more people, what do you do? Who goes first? Do you sort of like look at each other and, you know, do this and like, "No, you." "No, you." "No, you." + + Well here's what the Highway Traffic Act has to say, and here's my tip. If you arrive at an end-way stop the same time as other people, take your right hand and point it out to the right of you. If you are pointing at nobody, it's your turn to go. That's the whole thing! You can think of it as right-of-way. If you are the right-most vehicle, be that a car, a bus or a truck, you've got the right-of-way. Go for it! If there's one thing that we don't need on American highways, it's diversity. We should all understand the rules and just, just run 'em on a daily basis! + + KENT: I love that tip! We need to get more of those kinds of tips (laughs). Thanks for that! Cool, well let's wrap this up! So I'd just like to give a quick shout-out to our Silver sponsor, Trading Technologies. They are hiring and so check them out. And then if you have suggestions for the show, we love getting suggestions of guests or topics, so go to suggest.javascriptair.com. If you have feedback for this show or the show in general or a previous show, go to feedback.javascriptair.com and submit your feedback. And then we have a weekly newsletter that goes out about highlighting, like highlights of the shows and with the show notes and everything. Go to jsair.io/email to sign up for that and see previous ones. And then remember, next week our show is Progressive Web Apps, and it's going to be the bomb. We're going to have a good time and follow us on Twitter, Google Plus and Facebook to keep up with the latest and download the JSAir app on your iOS or Android phone. And with that I think we can say goodbye. I thank you so, so much Lee and Steven! It has been a blast! + + STEVEN: Cool, thanks for having us! + + KENT: We'll see you all next week! + `, } diff --git a/episodes/2016-05-25/index.js b/episodes/2016-05-25/index.js index ee1108b..ae8da68 100644 --- a/episodes/2016-05-25/index.js +++ b/episodes/2016-05-25/index.js @@ -92,4 +92,395 @@ export default { `[vaadin Progressive Web App Competition](https://vaadin.com/pwa-competition)`, ], }, + transcript: ` + KENT: And we're live at JavaScript Air! Hello, everyone. We are super excited to be talking about progressive web apps today, in this JavaScript broadcast podcast, JavaScript Air, that we love so much. + + Before we get started, I'd like to give a shout out to our sponsors, that make this possible. We have Egghead.io, the show's premier sponsor. They have a huge library of bite-sized web development training videos. Check them out for content on JavaScript, Angular, React, Node, TypeScript, all kinds of awesome stuff. And upcoming really soon, a deep dive on Webpack that I'm working on right now. Really excited about it. And I'm using Webpack too, which is the bomb. + + Then, Frontend Masters is also sponsoring. It's a recorded, expert-led workshop with courses on advanced JavaScript, Asynchronous and Functional JS, as well as lots of other great courses on frontend topics. And incidentally, I'm also doing a workshop for Frontend Masters in August. And one of my workshops will be Webpack deep dive. So, if that's your jam, check that out. + + Then TrackJS reports bugs in your JavaScript before customers notice them, and with their telemetry timeline, you'll have the context to actually fix them. Check them out, and start tracking JavaScript errors today at trackjs.com. + + And SparkPost is email delivery built for developers. Build something awesome with their Node.js library, or SMTP Relay. Start sending 100,000 emails free with SparkPost at sparkpost.com/jsair. + + And finally, WebStorm. WebStorm is a powerful JavaScript IDE. It makes developers more productive with its super intelligent code assistants for JavaScript, Node, Angular, and React, and integration with lots of other different tools. Learn more at jetbrains.com/webstorm. + + Great, that's our sponsors. Let me just mention, again, that this is a live show, and so we have the benefit of interacting with you, the live viewers. So if you're interested in asking any questions of our guests about this topic, Progressive Web Apps, you can tweet the hashtag #jsAirQuestion, and ask your questions there. And they will be answered. + + And then next week, our show is actually sort of in flux right now, it was going to be Webpack. We pushed that back a week. And we're probably going to be doing something about beginning, the beginners in the JavaScript community. So, should be an awesome show. I think it's valuable for us to care about people who are new in the community, and in the industry. So check that out next week, it'll be the same time. And then follow us on Twitter, Facebook and Google+ to keep up with the latest. + + Let's get to know people who are on the show. So like I said, I'm Kent C. Dodds, your host, and then we have a couple subject matter experts in the area of progressive web apps. And so yeah, first, Henrik Joreteg. + + HENRIK: Hi. + + KENT: I'm pretty sure that I'm pronounce your last name wrong. + + HENRIK: No, you got it, it's good. + + KENT: (laughs) Okay, I didn't ask, I didn't practice the name. So hopefully, this works out. We also have Ada Rose Edwards. + + ADA: Hi. + + KENT: And Nolan Lawson. + + NOLAN: Hello. + + KENT: And Ben Kelly. + + BEN: Hello. + + KENT: Awesome, so, let's give each one of our guests an opportunity to introduce themselves before we get into our topic. So we'll start with Henrik. + + HENRIK: Hey, uh, yeah, so, I'm an independent JavaScript developer, right now doing some contract work for a Fortune 500, building some frontend stuff that might be related to the show. And yeah, I think the web needs to be doing what we're doing here with progressive web apps. And I'm really excited to see this, like, come to be. So, that's me. (chuckles) + + KENT: Awesome, Ada. + + ADA: Hi, I'm from the Financial Times, from FT Labs, their like research department. I'm a full stack JavaScript developer. And yeah, I've been talking about progressive web apps for a while now, and I've been working on web apps since I joined the Financial Times before service workers were a thing. So, a long time. So yeah, that's that. + + KENT: Awesome, I just wanna say thank you, Financial Times, for Polyfill.io, it's a fantastic service. And actually, it was picked on the show by Misko Hevery a couple episodes ago, so, yeah, Polyfill had been on the show before. It's super cool. All right, Nolan. + + NOLAN: Hi, I'm Nolan Lawson. I'm a freelance web and mobile developer. And I do a lot of stuff. I'm one of the maintainers of a JavaScript library called CouchDB, open source JavaScript database. You may know me from a silly PokÇmon app that I wrote, that is a progressive web app, so I guess that makes me an expert on the subject. And I'm happy to be here. + + KENT: And we're happy to have ya. Ben? + + BEN: Hi, my name's Ben Kelly, I work for Mozilla. I'm on the DOM team, mainly working on service workers for the last two years or so. Kind of have the, I don't know, misfortune of being a C++ developer, so, I find myself often having to take an opinion on web stuff, even though I don't, I'm not a practitioner day to day. So, fully aware that I have a lot to learn there, but, try to help where I can. So, hopefully I can offer something here. (laughs) + + KENT: Well, we appreciate your work on Service Worker and I think that will be a major topic in our show. And maybe a little bit controversial. (laughs) We'll find out. So, cool, yeah, I think, to just get started with our show, it's always good to get kind of a baseline for everybody's understanding, make sure we're all talking about the same thing. So, could I get somebody to give us a, like a one or two-minute definition of progressive web app? Anybody can take that. + + ADA: Sure, I will, if no one else will. A progressive web app is a website that's so good, you wanted to install it to your home screen. Usually has offline support. + + HENRIK: (laughs) That's awesome. + + ADA: It can do push notifications, it's got to be responsive. Yeah, you could add it to your home screen, which is, yeah, one of the main things always you get with an app. And, it's gonna be progressive, as in, so that, it'll still work in IE7, it's just a website, but if you're on... in a recent browser, you can also install it to your home screen. Does that kind of encompass most things? + + KENT: Yeah, I was actually, so, I might have a misconception here, but, is it possible... I thought that it was only possible to actually install, like, and have an actual icon on the home screen on Android devices with Chrome. Is that not true? You can do that with like Apple and Safari? + + ADA: Ah yes, you have to-- + + HENRIK: Yeah, go ahead. + + ADA: I was gonna say, Apple's done it for years. + + HENRIK: Yeah, that's how they first started. (laughs) + + KENT: Yeah, obviously I'm not a subject matter expert on this. (laughs) + + NOLAN: Yeah, I think that's why Ada was very careful to not mention any particular technologies in her definition of a service work, or of a, (laughs) there it is right there. + + (laughter) + + KENT: Nice. + + NOLAN: ...progressive web app. Because it's true, there's lots of different ways that you can make one. + + KENT: Cool, actually Nolan, maybe this would be a good opportunity for you to talk about being duped a little bit by a certain progressive web app. + + NOLAN: Yeah, I guess I can tell that story now, I might as well. Yeah, so I was so excited, you know, I just got off the plane, I'm in New York, flying from Seattle. And I was so excited, 'cause I was excited to come on the show, and to talk about my recent experience with a lovely progressive web app that I had from Alaskan Airlines, which allowed me to look up my boarding pass, and it worked totally offline. I could save it to my home screen, it had a splash screen when it launched, it didn't have a URL bar. And I said to myself, "This is a beautiful progressive web app. A perfect, shining example of what a progressive web app, can be used for," right? Like a boarding pass, like, I don't have to take a screenshot of this thing, I don't have to worry that I'm gonna lose it when I'm standing in line fumbling for my phone, right? But it turns out that I opened it up in the Chrome Inspector, the dev tools, and actually, it was using Application Cache, or AppCache, and touch icons, and another special tag, mobile-web-app-capable, is that right? Which was a novelty, that was a new one for me. And those technologies have actually been around for several years, so, they predate the term "progressive web app," even. + + KENT: So I think, just like Ada, you know, carefully avoided any specific technologies in her definition, I think, you know, even though Alaska Airlines wasn't actually, you know, a "progressive web app" in the terms of modern technologies, it still, like, provided that kind of an experience. And I think that's kind of what we're talking about when we talk about progressive web apps. Even though their technologies are maybe a little bit nicer these days, or advanced in some ways, it doesn't have to use those technologies to be a progressive web app. + + NOLAN: Yeah, absolutely. + + ADA: I agree with that part. + + NOLAN: I agree, yeah, the whole progressive aspect is, as Ada said, that progressively... it progresses from site to app, basically. + + KENT: Cool, so, let's talk about some of the more, like, modern technologies that are used to accomplish this. So, what are, or maybe, let's... sorry, let's dive a little bit deeper into the definition of progressive web app. What are the minimal things that are required, I guess, for you to consider an application progressive? + + HENRIK: Well, I can give you kind of what the Google Chrome definition of that is, which is that you have an app manifest which is a JSON format for describing metadata about your application. You register a service worker, and your site runs on HTTPS. In addition, from what I understand, they're going to add additional kind of requirements, in that, it should serve something offline when you, so without network, it should still be rendering something. So that's kind of the modern, the definition in terms of that's what will make the add to home screen UI appear. That's part of the native browser UI for, you know, any browsers that fully support progressive web apps. + + ADA: I would say the minimum required functionality, again, I'm gonna avoid some tech, not, for something to be considered a web app, but this is below what is required to actually bring up a prompt. I'd say it needs to be responsibly designed, so it works well on mobile and desktop, otherwise we'll just have another generation of mdot sites. And it's got to, yeah, it's got to have some kind of content when you're offline, and it's got to work well across touch platforms and mouse or pointer environments. And that's kind of like my minimum, what I would expect. + + KENT: Go ahead, Nolan. + + NOLAN: Yes, I think that that's an interesting point you brought up. You just mentioned the prompt, and I think maybe the panelists here, we all know what the prompt is, but maybe we should explain it for the audience what she means by the prompt. Okay, so this is kind of, this goes back to the question of "what is the definition of a progressive web app?" And as it turns out, we don't have any representatives of Chrome here, but the Chrome team does have a very specific definition of what a progressive web app is in terms of whether or not they will show this magical prompt to you. And what this prompt is, is basically, it's like a little toast that shows up at the bottom of the screen, and when you go to a website, that qualifies as a progressive web app in their definition. And it says, "Do you want to add this site to your home screen?" Which, and actually, that's in Chrome right now, it's in Opera, both for Android, and then, Ben, correct me if I'm wrong, I believe that's in Fennec, it's in Firefox, rendering nightly now, right? + + BEN: Actually, I'm not sure, we're working on our manifest support. but it's not to my knowledge, shipping yet in any of our branches. The whole issue with the prompt, it's basically a browser-specific heuristic that has no standards around it. Like, there is no standard for progressive web app. It's like the underlying technologies are standardized, but this concept is not. And, so, should we standardize this heuristic or not, I guess is an open question, it kind of ties browsers' hands if we do that, but. Anyway, long answer to a short question, so. (laughs) + + NOLAN: No, that's a good answer, yeah. Sorry, go ahead. + + ADA: I'll say something, so, some of the heuristics for it aren't, they aren't matched across browsers. They're down to what the browser thinks a progressive web app should be. And those views don't necessarily align. But I think that's actually kind of a good thing that progressive web apps themselves aren't a spec, they're just a way of building something. + + BEN: Well, so this might be, this kind of gets inta, sometimes I get confused by the term "progressive web app," 'cause in my mind, I hear "progressive" and I think, "This site works progressively, gets more features depending on what platform it's on. If it's on a site with Service Worker, maybe it works offline, if it's on browser, sorry, on a browser with Service Worker. If it's on a browser without Service Worker, maybe it doesn't work offline, but it sort of progressively enhances across feature sets." But, that's actually not the definition. I guess progressive web app is more, as you, over time, use it, it progressively gets more app like. + + And so, there are a number of progressive web apps that are sort of, "I only work on Chrome," you know. Even though, (laughs) mainly 'cause they haven't been, for various reasons, like, if you don't have the exact set of features that are in this definition for the heuristic. And internally, I'm like, "That doesn't feel progressive to me." But, I think that's the problem is, there's this one browser definition that's being sort of defined very firmly. They're the first ones with implementations that... I'm not complaining about that, but I think it'd be great if we could come to a cross-browser solution so things work progressively across the platforms as, instead of tying it to, you know, the new largest market share browser, sorry. Kind of rambling there. + + HENRIK: No, I think it's interesting. But I tend to think that we should be, actually, holding the bar pretty darn high for that prompt. Because I think the web has a reliability problem, in general. You know, Apple, you know, kind of originally said to everybody, "Hey developers, if you're gonna build for iOS, you should, you know, add this web app capable tag, and then we'll, you know, we'll make a way for you to add an icon." But the problem was, the web wasn't ready for that, in terms of capabilities. And so everyone knew that it was just a bookmark, right? No one thought that they were installing an app. But as a result, you know, you push that bookmark, and you don't know whether it's gonna open or not. And I think that's exactly the problem here, is we don't have a way to, like, have people fully depend on the experience of the web. And then when I add something to my home screen, like I want that thing to friggin' work, as if it's a native app, whether or not, you know... I explained this to somebody who wasn't, you know, overly technical, and then, the thought of adding something to their home screen was not appealing to them because they were like, "That's where I've got all my, like, pure native apps that I know are gonna work, like, why would I want to add a bookmark to that?" + + And I think, you know, it's just kind of, I think it's important that this is, for the first time, something that the web can do to actually be a fully, like, native feeling, you know, OS treats it as a first class citizen type thing. And I think, if we don't hold the bar to that, to the "add to home screen" thing, I think we lose a lot. Because we have no other mechanism of controlling, you know, kind of quality of these things, other than, you know, so what every app registers a service worker, and tries to get you to install it to the home screen, like what, that doesn't gain you anything, you know. I think it's really important that, in addition to having Service Worker and stuff, that it actually, you know, runs some tests to make sure that this thing will open when it's offline, et cetera. I feel like that's an important detail on all this, that we risk diluting the value of the whole thing by not holding that bar a little higher. + + ADA: So, you were just saying that the, that it's only recently we can now do fully offline apps, and... + + HENRIK: Unless I misspoke. (laughs) + + ADA: Yeah, I'd slightly disagree there. + + HENRIK: But please, please clarify. (laughter) + + ADA: Because the, again, I'm kind of shilling for my company here, but the Financial Times started, has been using a progressive web app as it's, like, main distribution of digital content on mobile via a progressive web app since 2012. And this was before service workers, and the AppCache manifest. But we weren't just shipping for iOS, we were also deploying this to Android via a wrapper, and Firefox OS, and RIP, and, Blackberry and Windows. So it's definitely something that's not, not a new thing to do. And I think... 'cause it does have some history behind it, I think it's a pretty safe technology to go into. And I'm worried, because only recently entered into the limelight, that a lot of companies are going to be concerned that it's new, that it's new, and untested, when it's actually a quite robust technology. Well, it's a robust delivery mechanism, even if the technology has changed over the past few years. + + HENRIK: So really, the fact that you can build reliable web apps is not new is what you're saying. I mean, which part of it is robust, is what I'm asking. That's what you're getting at, right? + + ADA: Yeah, like, it works. You can deliver content through it, it drives revenue, it's a good technology. + + HENRIK: Absolutely. What about the offline aspect of that? How important is that to all of it? + + ADA: For us, well, for us as a news delivery company, like we, I couldn't think of the correct term there, offline was pretty important for us. But so we used AppCache at the time to gain offline support. Unfortunately, AppCache does encourage some very bad habits with regards to mindling URLs, in order to maintain the single page web app, ex, like, kind of experience. Which has been resolved if you can use a service worker. And although a service worker will eject an AppCache, if you have both, you can't really, if you have AppCache, you have to contort yourself into this horrible way of developing, which you don't need to do with a service worker. So definitely, I would say if you're gonna build an app now, build a service worker app, don't use AppCache. But there are tools out there which will allow you to convert an AppCache based website into a service worker one... such as oh, I think it's like, sw-AppCache or something. From the service worker tools, which Google'd been putting out there. So I don't really know where that went, but yeah. There were some words. + + HENRIK: (laughs) + + NOLAN: Yeah, so to Ada's point, just to let the audience in on some of the details of this stuff. So App Cache has been around since, what, 2007-2009 in broad browser support, and basically allows you to define a declarative manifest of all the files that you wanna cache, and it just caches them. And it's very coarse, and it's very difficult to work with. And there's an A List article from Jake Archibald about this API that I cannot repeat on air, because I've seen it violates the code of conduct, just the title itself. But, we can provide a link afterwards. But it basically sums it up. It's really difficult to work with. I've struggled with AppCache many times. We used it for the CouchDB website, I remember. And we thought, "Okay, you know, we make an offline database for JavaScript, we know how stuff works. We can figure this out." But if you go back, we had like, I think there's like seven issues that we ended up opening on ourselves over the course of weeks and weeks as we realized that we had messed this up so badly. I mean, migrating from HTTP to HTTPS, we almost put it in a situation where the site was locked down forever and someone visited the site twice, they would never ever see new content again unless they like, blew away their browser history. So it can be, it's definitely full of foot guns, whereas Service Worker is a lot more flexible, and allows you to basically build your own AppCache, which is really nice. + + But on top of that, Ada's totally right. There's been ways to add things to the home screen since 2009-ish like touch icons. Yeah, touch icons are what'll allow you to add shortcuts to the home screen in both iOS and Android. I mean, we've had IndexedDB since 2009, WebSQL since 2007, local storage since about the same time. But I think, what's genuinely new with progressive web apps, and I think one of the core reasons that everyone is really excited about them now is this prompt, I mean that is the one thing that is really genuinely new, and genuinely very interesting. And especially, when you show it to your boss, it's a very good way to convince them that, "Hey, maybe a progressive web app is the kind of thing we should invest in because it's the browser promoting your app for you, on its behalf, which is kind of amazing." + + KENT: I just wanted to touch on that, and the foot gun, and stuff that you're talking about. I actually did put an app into a situation with AppCache, where nobody could ever get updates again. (laughs) Luckily, it was just like a little toy project, so, it wasn't that big of a deal, but I realized, "Oh, like you really got to be careful with this technology," 'cause you can, like, you know, you do something like that to the Financial Times, and you're in, like, you're in a big bad situation. + + ADA: We had hacks upon hacks upon hacks to minimize the amount of content that actually touches AppCache. But we had like a tiny bootstrap, which just get us going, and everything else is pulled out of IndexedDB and local storage. Just because, yeah, if you broke AppCache, we would break the FT on our biggest platform. + + HENRIK: I would also raise that you can, in fact, do the exact same thing with Service Worker. I have done this in development, (laughter) but fortunately not on anything of significance. But basically, if you push some bad JavaScript that breaks before you register the new service worker, you can put yourself in the exact same position, 'cause it will keep serving from the old service worker, and doesn't know that there's a new one. And since it's cache first, you're back in that spot. So it is worth at least kind of being aware that you can do this. (laughs) + + NOLAN: Hey, that can actually have benefits. I remember there was a talk from substack where he kind of evangelized these things. He called them "hyperboot apps." + + HENRIK: I saw that. (laughs) + + NOLAN: The idea of an app that can be forever locked down, and so it's like, 100% secure, because you know the person visits the site, that is exactly the same version of the site that it will be forever. (laughs) So, if that's what you want, you can do that. + + HENRIK: As long as you don't care about, you know, pushing updates, ever, I guess it's a good thing. (laughs) + + ADA: Well, the nice thing with the service worker, though, is that the browser will check for updates to your service worker JavaScript file, and if it detects a byte difference, it will pull down and update the new service worker. + + HENRIK: Yes. + + ADA: So if you wanted to- + + HENRIK: But if you didn't ever, one of my point is, if the JavaScript breaks before it even tries to register the new one, in my experience, that check doesn't happen. + + BEN: It should. That's a bug if it doesn't. + + HENRIK: Okay, all right. I will make sure that that's been fixed then. (laughs) + + BEN: There was a bug in Firefox until 46.01 that had that issue, but we pushed a hot, or a patch release to fix that. + + HENRIK: Okay. So I have, what's the heuristic then for determining what, I mean, should it check the service worker any time it's online, to try to see? + + BEN: It's whenever the browser attempts to fire an event at the service worker, it will... if it's a navigation, like you're navigating to the window and it's a navigation fetch event, it will try to go to the network and hit the service worker. It may hit your HTTP cache, but if it's been over 24 hours, it will bypass the HTTP cache and go out to your server. + + HENRIK: Maybe it's the 24 hour thing that got me. So it would a maybe resolved itself in 24 hours. Regardless, I wouldn't wanna break a site for 24 hours, if it has any amount of traffic. (laughs) + + BEN: I think a common tip is to always, is just in general put cache control headers on your service worker script, so that you can always update as soon as possible, even if-- + + HENRIK: I'm gonna hafta look again to see what I was doing, 'cause something definitely went weird there, but. + + BEN: I opened a spec issue like, maybe we should just do this, if this is our recommendation, just always just bypass cache, but, that, currently it's not the spec. I'm sorry, Ada? + + ADA: So there is actually a very interesting post by Jake Archibald, about how, what you should do with your cache for, to make updating easy with service workers. I'll find it and drop a link, here, I can do that somewhere. Essentially, put the hash in the filename, and do unset some cache headers, which I'd forgotten. Yeah, it's very good, very useful, worth looking up. I'll go find it. + + KENT: Cool, thanks. So, I think, we're getting a lotta questions on Twitter, so we'll probably only chat for another 10 minutes. But if anybody watching live does have questions, keep asking questions on Twitter. I'll make sure to give us enough time to answer. So I wanted to actually ask, what does a progressive web app mean for the desktop? We talk a lot about mobile, and that cool toast that pops up, you know, saying, hey, or the prompt, "would you like to install this on your screen?" like, that's not really a thing for desktop, right? There's no, you know like, "Add this to your home screen," right, or is that coming? + + HENRIK: That is coming, at least at Chrome. There is a Add To Shelf, they call it, and you can turn that on as a flag right now. + + ADA: Ah yes, so it's actually on, yeah, it's on Linux, too. You can go Add to Home Screen. And I was gonna share my screen, but there is... a lot of people can actually see it. But you could go, all right, yeah. + + KENT: Well, you can show it, and if somebody wants to see it who's listening, they can check out. We're at around minute 30, so. + + ADA: Yeah, so, go More tools, Add to desktop. It's on Linux. And yeah, it appears in your, your bar, and you get a web app. It works quite nicely. + + KENT: Very cool. Thanks for the quick demo. + + BEN: I wish I could say whether or not Firefox was working on that, but I'm kind of disconnected from the product UX side. So I'm not familiar with our plans are. I think we had something like that in the past, but it was like a different mechanism, so I'm not sure where we stand, currently. + + ADA: I'm not actually sure what the status is in Chrome either, actually, because I've heard some stuff about it being removed. But, it's always been present. And this is a pretty recent version of Chrome in my browser, so, I'm hoping it's either coming back, or maybe it just hasn't been removed yet, but. + + NOLAN: Last I heard from the Chrome team, I'll maybe end up speaking, is that they're working on harmonizing their treatment of progressive web apps and Chrome apps, which I think is kind of the similar story with Firefox and Firefox OS. Like, Firefox OS apps are similar, but not exactly the same as progressive web apps. And so, they kind of need to be harmonized. But I actually tried, for what it's worth, I tried the Chrome thing behind, I think it's behind a flag, it was really nice. I could type into Spotlight on Mac, and actually get top suggestions for a progressive web app. It had its own icon and everything, was quite neat. + + HENRIK: Yeah, I think until this stuff, we didn't really have that much of a standard around how to go about any of this stuff, which is why we had Chrome apps, and why we had Firefox OS apps. And I think now, it just kind of makes sense to start unifying all these things under the same set of technologies, and then let the platform kind of pick exactly how to implement that for their users. But to me, like, now that this is, you know, getting some attention and becoming more and more standardized, I think it's inevitable that, you know, this is the way to do this kind of thing, and then hopefully, everything will support it eventually. + + KENT: So I take that you're suggesting we just use the platform, right? Just kidding, that was (laughs) we can talk about that later. + + (laughter) + + KENT: Well, that had to come in. So I do wanna get actually a little bit more technical before we go through our Twitter questions. Because we have Ben here, especially, I'd really like to talk about Service Worker, that technology. Maybe, Ben, you can give us an overview of how that technology works, and what role it plays in progressive web apps. + + BEN: Okay. I just, reminds me of the, there's an infographic, a tall infographic that was going around recently about this. Let me see if I can summarize this. Essentially, a service worker is like a web worker. In the past, web workers were associated with a window, a document to open them. A service worker's unique in that it can run without any window open. And this lets us, provide a way to run JavaScript for a variety of different use cases. The main one is when a network request happens. You get a fetch of it, and you can decide to create your own response, you can go to the network, you can go to a storage system like the Cache API, or IndexedDB, and get a result. And, it really lets you provide your, build your own AppCache functionality, or something completely different. Like on The Guardian, I believe, like they provide a crossword puzzle if you're offline, instead of going to the site that you were trying to see. + + However, it also lets us provide other, a place to fire other events, where you may not have a window. Like, a push event comes in but the window's not open. In the past, there was no way to run any JavaScript without the window open, as a security mechanism. So now we have a way to do that. And in the future, you know, background sync, I don't think there's anything spec'd yet, but you know, some sort of geo fencing, geolocation type API. Obviously, some security or privacy concerns around that. But that's sort of the goal, right, is provide a background process or a thread that can run JavaScript, and allow the site to build its own logic and functionality that used to be solely the domain of the browser, so that we can expose these primitives to sites. + + HENRIK: Yeah, right now it's limited to those two use cases, right? The push notification support, and the Chrome has implemented background sync, as well. Those are really the only two offline, or it's sort of, everything's closed events that are gonna occur for your service worker, right? Eventually, I would hope you would be able to do sensors and other things, you know, obviously with user permission, but, those are the only two I'm aware of right now. + + BEN: Right. + + ADA: Something which is quite fun for generating content is with the new Canvas API, you could dynamically generate the push notification icons, which I think is pretty neat. + + HENRIK: That's awesome. + + KENT: Wow, for those artists in the room, I am not one, but, you can use that Canvas API and make some pretty amazing things. (laughs) Cool. So I think that's all for, so Service Worker is one of the technologies that help us build PWAs, or Progressive Web Apps. Nolan, I know you wanted to talk about the web app manifest as well, that's another critical piece of this. + + NOLAN: Yeah sure, I'm happy to quickly go over that. So if you've built Firefox OS apps before, it's gonna look very, like, suspiciously familiar. Basically, it's a JSON file where you define a name for the application, you can define a short name as well, so that it has a different name when it's on the home screen versus when it's open. You can define icons in various sizes. You can define a theme color and a background color for when it shows a splash screen when it starts up, because maybe you want to, you know, kind of give the impression of loading a little bit quicker, so kind of psychologically, it's nice that you already have that, whatever background color your app is gonna start to show, kind of in that splash screen. And then it also lets you define whether you want to launch with or without the URL bar, so whether you kind of want the browser Chrome around it, or around the app, or if you want it to kind of launch in standalone mode. + + HENRIK: Orientation as well, right, portrait versus landscape? + + NOLAN: Yes, yes, that's true. And, oh wait, you can also define a custom start HTML page, which is really nice, because then you can say, like you can put like a query parameter in there, and that's how you know that it's starting from standalone mode, starting from the home screen, versus starting at, from the browser. + + KENT: Cool. So, I, we're really running down on our time, and we have lots of questions to ask. So I'm just gonna stop us on the web app manifest. It's cool, and it's really easy. So I wanted to get into a couple examples, and then I wanted to talk about some use cases that, like, that are really hard to accomplish with the technology we have. And maybe, you know, some things that are coming that will simplify those use cases a little bit. So first, some examples, I'll just give a quick example, javascriptair.com is a progressive web app. It actually, the service worker I think is broken right now. But you can go to javascriptair.com, turn your phone on airplane mode, and refresh, and you'll still get javascriptair.com. Everything looks great. But if you go to one of the episode pages, I think the CSS is broken or something like that. But, so if anybody here wants to help me fix that, that'd be great. It's open source, so. (laughs) But what are some other really cool examples like that you've seen of progressive web apps? + + HENRIK: Think Flipkart, Flipkart was one of the first ones to do a big one, I think, in terms of, like, a broad audience. They have quite a few customers, they're a very large retailer from India. So they have a very awesome example of a progressive web app. + + BEN: I feel compelled just to mention, I think what they built was great, and I'm glad to see them back on the web. Just going back to my previous statement, I don't think it's useful to have user agent checks, though, just because you don't have an exact set of features. + + HENRIK: I agree. + + BEN: So, I just, I wanna give 'em praise, but I don't want people to duplicate the user agent checking. + + HENRIK: They also, ah yeah, they're at least now doing iOS as well, which is good, which they weren't doing initially. But yeah, I was a little disappointed by that, too. + + KENT: Do you wanna talk about that a little bit? I think there's a little bit of background that we could use there. + + BEN: They, from what I understand, they used to have a website, then they went to pure native. And they came back to the web with this progressive web app. However, it was specifically targeted at a particular version of mobile Chrome. Like even if you opened Chrome on a tablet, it didn't show. You'd get shunted off to the Play Store, and that's just where I have some cognitive dissonance, hearing this is a great progressive web app, but if I open it in Firefox for Android, I get the Play Store without, you know, so. I know they're working on it, I know they have a business decision to make. I know that they're, I'm not their target customer. It's just, I would like to see the power of the web right, is reach, and so, allowing your site to work even if it's not 100% the ideal feature set you want across multiple browsers, I think is the best thing. But, I think there's studies that show, that gives you better conversion than a interstitial to the Play Store, or any store. And also, I think it's better for the web in general. + + NOLAN: Yeah, I wanna just really quickly echo Ben's concerns, 'cause I think I also saw Twitter's mobile site, which is a great mobile site, but I believe they kind of made the same choice, if I recall. I think they finally went back on, and you can actually access mobile.twitter.com from Firefox now. But for a time, they were doing user agent checking. + + BEN: That, yes, and there was like they had, they actually had a specific issue with their HTTP2 server... HTTP2 server stack, or sorry, client stack interacted poorly with their server. That was fixed, so it was a temporary situation. And it was more that, you know, it was completely broken for something that they were working to fix. I understand that sort of thing, but it's been. Flipkart, I think we, the CSS would work just fine in Firefox, you know, I think. + + HENRIK: Yeah. I think, you know, to some degree though, like, I'm fairly tolerant of that when they first launch. You know, I mean I understand they have, you know, as long as they iterate towards that, like, I feel like it's kind of okay. Because it was better than what they had, which was nothing, you know, like full on door slam. So I guess I can give them, I don't know, I give them a little bit of grace and leeway there in that I don't, you know, giving it a little bit of time, knowing what it's like to work in these large corporations, sometimes getting approval from various, you know, organizations and getting it through QA, or whatever might be challenging. They might have to make some, some cuts to kind of get it to go. + + NOLAN: Yeah, and I think in terms of health of the web, too, to add on to that, like, one of the progressive aspects of building progressive web apps, I think, like I hear a lot from people when I mention this. "Oh, but does it work in Edge? Oh, but does it work in iOS?" And that's kind of the point, is that it doesn't work in those things, because the idea is you build this app that gracefully falls back to just a normal website, perfectly fine website. And then you give those other browsers who have not implemented it yet, you give them incentive, right, to match that experience that people can get on other browsers. Like, if you just do a user agent check and you only give that experience to Chrome, then what motivation do the Edge team, or WebKit team have to actually work on it? Like, no, you're absolutely right. For the overall future health of the web, this is like one of those good web citizenship things we should be doing, I believe. + + HENRIK: Absolutely. + + KENT: I definitely agree, though, like, you should still give users an awesome experience. Like, you know, that I think that goes without saying. But I said it anyway. (laughs) + + HENRIK: Cool, so what are some of the use cases that are common for progressive web apps? Or, not, maybe not common because they're hard? So, what are some use cases that you can't really accomplish that you'd really think you'd want to with progressive web apps? + + BEN: So, one of the main ones that I'm aware of, actually, is podcast player, ironically, being on podcast, in that traditionally, podcast players, you know, the media tends to be on some CDN in order to reduce, you know, bandwidth costs. However, because it's been mainly native apps in the past, those are just served over HTTP without CORS, CORS headers. In order for Service Worker and websites to use it effectively, if you access these without CORS you get a, you know, a change in the UX that says this site's using mixed content. And that makes your site look dangerous. So there's this sort of industry, you know, chicken and the egg problem, where we need, we would like to get podcasts to serve CORS headers on all their media content, but they have no incentive to until there's web players. And so, it's like how do you bootstrap this problem without sacrificing the protection, the security that the web brings? + + ADA: So that the Fetch API, should I think will allow you to fetch with and be able to pull down a request without having the cross origin resource and stuff. So, if you, but you obviously can't do any, you can't mangle it with JavaScript or anything like that, but you can cache it. And I think that might work in a, inside an audio tag, 'cause I remember I've been doing 360 video viewing in a web app recently, and I was having some issues with the Range header, but like, it was working with CORS and stuff like that. + + BEN: Yeah, I think you can get, you get the media content out, but from what Paul, like Paul Lewis wrote a blog post about this, and what he, at least the experience on some browsers is you get a change in the user, like, there's like a lock icon that says "this is secure." You get something that says this is mixed content, you know, warning. And because you have a, when you're using a service worker, you're on a HTTPS site and you're going to a no CORS site, I think some browsers basically make a warning out of that. + + ADA: And because it's HTTP as well, that's-- + + BEN: Yeah, that was the other thing. + + ADA: That was the issue, sorry, I was not, I was focusing on that. + + BEN: Yeah, I think I might been confused, but yeah, maybe it's more of an HTP versus HTPS issue there. + + NOLAN: Yeah, you can put it in an audio tag, that's fine, but you couldn't do something like, say, save it to IndexedDB, which is, unfortunate because that's kind of one of the, like, fundamental things you'd wanna do with a podcast app, is be able to download your podcasts and then play them offline. If you can't do that, it's kind of like, what's the point? + + ADA: You can put them in the Cache API. + + HENRIK: I've done that with images and stuff that are not HTTPS. + + BEN: You can put them in the Cache API, but because they're opaque responses, you have no idea if they're actually there or not. You could have just cached a 501. Which is suboptimal, I mean. (laughs) Site thinks it's there, but, try to listen to it and nothing happens. + + KENT: Yeah that, it seems like this is, like, there's opportunity for improvement on this particular use case of the podcasts. Which makes me sad, because I'd love to have my podcast just be like full on web app, but. You know, what do you do? Is there anything else that the current tools... oh sorry, Ada did you have something else? + + ADA: Yeah, I was gonna say there's one more use case which I have seen, or two more use cases which I've seen brought up for the speaking people at conference setup, why they're not building a progressive web app. One is payments. They won't do payments through native, but for various reasons. And I think hopefully that should be sorted soon with the web app payments API. And the other thing I've seen mentioned is not as granular control over the camera, for people wanting to do camera apps. So yeah, and that one, there is, the API's kind of flat yet, so yeah. Those were just a couple. + + KENT: Yeah, so the web has a little ways to go yet, I think, to like be able to compete fully with native experiences on many use cases. Somebody on Twitter just asked, maybe we should explain a little bit about the Cache API. Does anybody wanna talk about the Cache API? What like, what role that plays in progressive web apps? + + NOLAN: I'm happy to take that up, as kind of one of the browser storage people. So, the web has many, many ways of storing data. We had cookies, and then we had local storage, and then we had Web SQL, and then we had IndexedDB. Now, for better or for worse, it's service workers and associated specs, we are blessed with the new one, which is the Cache API, which is actually available, it's actually available both in the main thread and in Service Worker. You can find it as window.caches, I believe, on the (mumbles). But basically, it's... no, I joke, but it's actually really nice, because it's optimized for caching requests. So it integrates really nicely with the Fetch API, like it's kind of part of that whole like family of standards that Ben can talk about. But basically, what it allows you to do is it allows you to just cache HTTP requests and cache exactly what the headers were, what the response was. Yeah, it's a fundamental part of doing Service Worker stuff. If you're not using cache within the service worker, you're probably not using Service Worker to its fullest potential. + + HENRIK: The other thing of interest, potentially, is you can very easily write a little wrapper around it, to just use it like a local storage, like promise based alternative. (laughs) Which I may or may not have done. + + (laughter) + + KENT: Let's get a link to that. + + HENRIK: I don't have a GitHub project on that yet, 'cause I'm not sure it's a good idea, so. (laughs) + + ADA: I actually saw something really interesting with that, for using, using, I feel this is using Fetch rather than the Cache API, but you could, if you have that stored in the cache, you can access it as local storage of work as well, in asynchronously decoding JSON. So although it's like a little bit slower from making the decode try to get a result, like it doesn't block the main thread, which is fantastic if you're decoding 50 megabytes of JSON or something. Not that you should ever be decoding 50 megabytes of JSON. + + KENT: (laughs) + + BEN: I remember reading about that blog post, and that might be something you'd wanna test in different browsers, because, it does have an async step to it. However, once it's all loaded into memory, it really does need the JavaScript global that's on the main thread. So, it probably is still a fairly large blocking step with that, unfortunately. But, that's one of those, it's hard to perform that off the main thread, because you need to create JavaScript objects. But yes, web workers, yeah, we'll see. It's complicated though, it's one of those things where the API makes you think it's doing something more magical than it might be. + + HENRIK: There's an awful lot of complicated things we can do these days with web workers and service workers combined. It's kind of interesting to cache your web worker code with Service Worker. It's just one of these moments when you're like, "okay, this is getting' pretty deep." (laughs) But, it totally works and you can build amazing apps. So you should definitely read Nolan's kind of breakdown of what he did for Pokedex. I'd added that as one of my links, 'cause he didn't, so I figured I'd kind of toot his horn for him, 'cause I think it's awesome. I also gave a talk similar in content at dotJS in Paris. That's online too, if you wanna find that. + + KENT: Very cool, yeah, let's add that one to the links too. Cool, yeah, we should probably jump into our questions on Twitter, (laughs) 'cause we've got plenty of 'em. So, unless there was anything else that anyone desperately wanted to make sure we bring up? (silence) Okay, cool. So, our first question is from just, actually, the very first question is from my good friend Mike Hardington, and he asks, "When do you think we'll be able to just say "web apps" instead of "progressive web apps?" When will be able to just call them web apps?" + + HENRIK: I hope this happens sooner than later. Dion Almaer said something about this. I tweeted something similar the other day, and he said, "you know, we used to call it color TV to delineate what a color TV is versus a regular TV. These days, obviously, it's just a TV, right?" And I think until now, we've lacked enough definition I think, around this, to really be able to make that delineation. I realize this is like a very, I don't know, complicated topic, a lot of people have strong opinions on this, but I feel like what we should work towards is the user's perception of what an app is, which is, can they install it, I can run it in my home screen. And I think that make sense to, like, have that be a web app, and have everything else be a website. But that's just me. + + KENT: Cool, all right so Jeff Whelpley asks, "Do you think that PWAs will reach a point where some big consumer-based companies won't need native apps?" + + ADA: (agrees) + + HENRIK: Yes. (laughs) + + KENT: (laughs) Easy question to answer, yes, one day we will reach that point. Cool, Jeff Whelpley also asks, here comes the use the platform reference, so, "What was the big deal with the post-Google I/O discussion about Use the Platform?" Anybody wants to take that? (silence) Nobody wants to take that. (laughs) Yeah, I think the platform is really awesome. Abstractions are important, okay. Yuri is asking, when PWA, or so, we have progressive web apps, and we also have hybrid, we have native. Where is the clear line between all of these? + + ADA: I've seen some companies start to move in a progressive, this is from speaking to people rather than actually seeing it myself, and they say they're moving in a progressive web app direction, by first turning all of their wrapped content and improving it so that it's a decent app when wrapped. And then, they're slowly planning to basically remove the wrapper, and make it available to get straight via the web. Wanna say, I've no longer any native components. + + KENT: So it sounds like it's a progression, like you can start, if you have a native app, you can like slowly move to a hybrid, and then progressive? + + NOLAN: Yeah, I'm, when Mike Hartington was just on, he does Ionic, right? Ionic recently added progressive web apps as a build target. So for them, it's just another build target, right? You can build your app in HTML, CSS and JavaScript, and then you can build for iOS, build for Android, in a wrapper, each one, or build for the web, as a progressive web app. I don't know if that's actually shipped yet, but they did declare that they were gonna support that at some point. + + KENT: Cool. So Juan is asking, I lost it, "What do you think is holding people back from writing PWAs most? Lack of education, resilience on frameworks... or a reliance on frameworks?" What's holding PWAs back? Or, people writing them? + + HENRIK: The lack of a bunch of big shift examples. + + ADA: Like, I've been asking around here, and so for some people, it is features such as web payments not being widely supported. Some people, it's... they want to get the offline support on iOS without relying on AppCache. And for some people, it's just momentum, and others, they're like, "Yeah, we're doing it," but it's gonna take time. But there definitely does seem to be a movement in that direction, 'cause it definitely gives you significant benefits with regards to click through rate, and actually getting people, like, "installing" your app. + + HENRIK: Of potential interest too, there is a Phone gap/Cordova plugin for basically implementing Service Worker, so, if you could potentially write your progressive web app, ship it like that for platforms that support it, and then on iOS, take the exact app and just wrap it with that, very minimal wrapper in that case to get the missing features. I don't know how good it is, I haven't used it myself, but it does exist. + + KENT: Yeah, that's actually really interesting. Let's get that in the links. We've got a lotta links today. (laughs) This is really great. Okay great, so next question, from Larry King, "My experience, users resist mobile browsers. They just think apps. We need more than performance to win them over. Thoughts?" And then Yuri jumps on top of that, and also adds another point, "What I often hear is on searchability, like, we want people to be able to find the app in the App Store." So what are your thoughts on those things, like users' resistance to use, like, mobile browsers, and they just kind of wanna use apps, and then the searchability aspect, as well? + + ADA: So if you're not in the top 0.1% of apps in the App Store, you're not getting visibility via the App Store. Users are going to be coming to you via the web, either via social media, or via just looking for your website, and you expose it via your website. And it's gonna, yeah, it's definitely worth it to, via the App Store isn't, unless you're Angry Birds, you're not getting anything from the App Store. + + HENRIK: I definitely wanna agree with that. In addition, I think, right now, I think we have a little bit of an issue with users in that, I think Add to Home Screen just isn't strong enough. I've heard people react to that saying, "Why would I wanna do that?" As I mentioned before, we need the verbiage to change to "Install This App," because that's how users perceive these things. I understand there's political challenges with that, with platforms that may not want that language, but I'm of the opinion until we get that point, we're not gonna get quite the traction that we want outta this, because it's just too weak. + + BEN: I'd love to see, like, web search engines, though, maybe add a flag or something that says this conform, this site happens to have a manifest. You know, like something that says, this is an appy link, and if you click here, it's something that you can install. And, maybe allow people to search for those. On the other hand, I hear a lot of people saying that they want a curated list, however, we have URLs, anyone can make a curated list. I think that's sort of the power of the web is now that they're addressable through a URL, we don't have to necessarily have a store as the gatekeeper. + + ADA: I remember there was a couple of 'em who was but someone mentioned it earlier, that perhaps the browser's heuristics should determine whether, to determine whether the app actually gives you content whilst it is offline. And I think rather than actually relying on the browser to do that, perhaps that's the kind of thing which big search engines, beginning with G, could use as part of their SEO heuristics. I know that usually gets stuff going quite well. + + HENRIK: I did. I may or may not have tweeted at Matt Cutts about that at one point. I definitely think they should do it. + + KENT: And they've got a lot of power, and I think they need to be really responsible, and considerate about that power. But yeah, very interesting stuff. Cool. So that is our questions from Twitter. I think we should rush into our tips and picks. And due to limited time, I'm just, we'll quickly go through these and then we can wrap up the show, so. I'll go ahead and go first, and then we'll go through our guests. + + So my tip of the week is, avoid nesting your tests. So if you use something like Mocha or Jasmine, you have these describe blocks, so you can nest those describe blocks. I say, have a single describe block. Don't nest those, and avoid beforeEach. I have a little podcast, like a three minute podcast that I recorded this morning about it, and you can see that in the links. + + For my pick, I was asked to pick this, and it looks really interesting, vaadin. I'm not sure if that's how you pronounce it, but vaadin progressive web app competition. Looks really interesting, you build a progressive web app, and you win stuff, and it's fun, so check that out. Nolan Lawson, why don't you go next? + + NOLAN: Okay, so for my tips, I basically got two tips from What's New in Chrome. So Chrome Canary how has an application tab if you build a progressive web app, which breaks down everything you'd wanna know. So you can debug, know what the icons are, how it launches, and then it also contains storage. And then my favorite feature is absolutely gonna revolutionize my own personal workflow, is that there's now a single button where you can just blow away all of the offline data for a website, which is amazing, I've been using browser extensions for that, it's been awful. Now there's actually something built in. Just blow it all away, and start fresh. + + KENT: Sweet, did you wanna mention your pick? + + NOLAN: Oh yeah, that's right, yeah. So I have one pick, a non-programming thing which is this documentary I saw recently. It's really, really good. It's a famous one, I guess maybe I was the last person on the planet not to see it. It's called Hoop Dreams. It's a 1994 documentary about inner city kids in Chicago who, it's kind of, it's kind of heartbreaking, but also really inspiring, 'cause basically, they're really passionate about basketball, and they sort of see basketball as being like their ticket out of poverty. But it's really, really worth watching. Very good documentary. + + KENT: Cool. Thanks for sharing. Henrik, let's hear your tips and picks. + + HENRIK: Let's see, yeah, a few different things here. I just randomly, I really, really like GraphQL. I think that we're gonna see some really interesting things happening with GraphQL over the next few years, just because it's a nice clean spec. A really amazing way to query for application data, which we're all doing now. And REST doesn't quite fit that pattern anymore. + + Also, a random other thing, I'm a huge fan of this library called reselect that I've been using a lot recently for Redux applications, for just kind of grabbing, basically being able to ask intelligent questions of your application state. Three other things in there. Specifically, so one link I'll point out is just the service, the sw-toolbox is a great set of tools that the Chrome team has released. That is a script that you can kind of import into your service worker that gives you, like, nice higher level abstractions for some of these things. 'Cause, writing raw service workers can be a bit intimidating at first. So, that's a good place to start if you're a little bit gun shy. + + KENT: I know that my service worker for javascriptair.com is copy paste. (laughs) + + HENRIK: But that said, I think it is worth learning, and to kind of battling through it. But, there's a lot of power in that toolbox. + + KENT: Very cool, yeah, I should probably give a shout out to you, Jake Archibald. I copied his example, so. And it works, most of the time. (laughs) + + NOLAN: I did it too. (laughs) + + KENT: (laughs) nice. Cool yeah, I think abstractions are valuable. And it'd be really nice to get a good one for, like, common use cases for service workers. + + HENRIK: Related to Webpack, also a real quick method that's out there. Using build tools like Webpack that are aware of all your assets are really useful for generating service workers. + + KENT: Sweet, yeah, and actually, just random other thing that has the word "worker" in it, Webpack actually can, I think they have a, a deploy or a packager for web worker. So you like, your target can be Web Worker, which is kind of like, what? So okay, cool. Yeah, Ben, we'll have you go next. + + BEN: Sure, I think the main tip I would, I had is that, I'd really, when you're writing your service worker, I'd really focus on if you're doing any asynchronous work outside of like your respondWith, and make sure it's in a waitUntil. I see lots of code examples on the web in guides and articles, and in people's applications where they are not doing a waitUntil. And the browser can just kill your worker while you're doing that. In testing, you often won't see that happen, because for example on Chrome, when you have the dev tools open, it will not kill your worker. It keeps it open so it can debug it. So this is a thing where like it can work perfectly in your development, and then die in the world, in like a heisenbug sort of situation, so. I would, like if you're, I would double check your service workers about that. + + And then I was thinking about, I'm not very good at picking things, but, I was thinking about this. I do think there's a really cool progressive web app called Sound Slice. I really think it's a great site that uses like Web Audio, Canvas. I think the music notation is Canvas, but it'll show you the web note, like the music notation and play it for you live. And it, I believe it works offline, they have a service worker. + + HENRIK: It does. It's made by Adrian Holovaty, the Django guy. Fantastic. + + BEN: It's really impressive. And as someone who's tried to learn how to play guitar before, I was like, this, this is awesome. And yeah, check it out. I'll put the link in. Oh, it's already there. + + KENT: I added it, actually, that's been picked before. I think Igor Minar picked it a couple weeks ago. So yeah, very cool. Ada? + + ADA: Cool. So I'd like to put in another, like, reference to sw-toolbox, 'cause now, like after writing a service worker myself a few times, just, there are a lot of edge cases and stuff you don't expect. So sw-toolbox took out a lot of the stress on that. And there's sw-precache. Again, this is in the Google Chrome GitHub repo, for generating pre-caches for your static websites. And finally, lighthouse, again, come out of the Google Chrome team. Very cool tool, it's not on the... it's a Chrome extension, which is still very early on. So is a little like, it's, you have to build it yourself and add it to your browser by the Add Extension, but it will look at your web app manifest and your app, and will determine whether it's, will give you a list of stuff to check off for being a good progressive web app. It's very, very good. So that's my three things. + + KENT: Cool. Thank you thank you. So, I'll just wrap things up for the show. So thanks all of you for coming on the show. This has been really interesting. Lots and lots of resources. I recommend you check out the links after the show. So yeah, let me just wrap up with a couple closing announcements. So Trading Technologies is our silver sponsor. They are hiring, check them out. Suggest.javascriptair.com is a place you can go that will take you to a form, where you can suggest shows for us. So, yeah, we've done several shows that were suggestions from people, and just like you, and so we appreciate those suggestions. We have a long backlog, though, so just be aware of that. But yeah, you can suggest guests or topics, or both. And then feedback.javascriptair.com is a place you can go where you can submit feedback about this show, or the show in general, or a previous episode. We really value your feedback. And then jsair.io/email will take you to our newsletter, where you can see previous weekly newsletters, as well as sign up for the newsletter to get an email in your inbox the day after the show every week, that gives highlights from the show, and the links, and tips and picks, and stuff. + + Yeah, and that's pretty much it. Next week, we're going to be talking about like, beginners in the JavaScript community, and so stay tuned for that. I, unfortunately, will not be hosting that show, but I believe Getify will lead us on that, and it'll be awesome. I will be out of town. So yeah, check us out next week, and as always, follow us on Twitter, Facebook and Google+ to keep up with the latest. And that's our show! So thanks again everyone for showing up, and we'll see you all next week. Bye. + `, }