No links, tips, or picks this week
No links, tips, or picks this week
Kent C. Dodds
No links, tips, or picks this week
No links, tips, or picks this week
No links, tips, or picks this week
No links, tips, or picks this week
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)
KASSANDRA: I did. I did. It was really good.
ALLEN: It's ES2016.
KENT: Can you explain a little bit about the reasoning behind that?
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!
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?
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.
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)
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?
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?
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?
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.
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?
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.
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.
BRIAN: You'll be programming in Haskell soon.
KENT: That's exactly what I'm planning on, actually.
KENT: Thank you for that. (laughs)
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-
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.
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.
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.
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.