Kent C. Dodds
Okay, so let's go ahead and introduce everybody who's here. So for our panelists, we have Brian Lonsdorf. He's muted.
BRIAN: Hi! Now I'm unmuted.
KENT: And we have Kyle Simpson.
KYLE: Hello, everyone.
KENT: And Lin Clark.
LIN: Hey there.
KENT: And for our guests. Oh, I didn't even practice these names, I hope I get your name right. It's Gaurav Seth?
GAURAV: Hi there.
KENT: Is that right?
GAURAV: That's almost right, Kent.
KENT: Almost right. Alright, and Steve Lucco?
KENT: And Ed Maurer.
ED: Yeah. Ed Maurer, howdy.
KENT: Maurer, okay. Yeah, I should've practiced ahead of time. I have a history of getting names incorrect, (laughs) so it's nothing personal. Okay cool, so let's get an introduction through our guests before we get into the core, no pun intended. Actually, there was a pun intended, totally intended, of our subject today. So, yeah, Gaurav, if you could introduce yourself, give us a brief background on your history.
KENT: Awesome. Steve, why don't you go next?
STEVE: Okay. I wrote some of the original code of Chakra. I'm the architect of the engine, and I've been functioning as sort of trying to help Microsoft get really passionate and committed to the web development space and to open-source around that. And so I've been working on that for a number of years.
KENT: Cool, thanks for your efforts, that's awesome. And Ed, what can you tell us about yourself?
ED: I've been working in developer tools here at Microsoft for 11 years, (mumbles) times. Spent a lot of time working on the C# compiler a whole lot of time, probably 8 - 9 years, something like that. And then before that, I worked with Microsoft in the video game business, so I have a whole other separate career that's very different from my developer tools one.
KENT: Cool, I think we're actually going to change the subject of this podcast and talk about your video game history?
Just kidding. Tthat would be an interesting topic though. (laughs) So, I think a really great intro question to get our conversation started is let's say that I'm totally new to the whole idea of Chakra and I've never heard of it before. Can you give us a basic idea of what is ChakraCore?
STEVE: Right. Mostly done with Lua, right?
GAURAV: Another thing I would add is yes, it's class C so you do have the flexibility, you know, whatever you want to use, you know, C++ on the top of it, or there's also like from manage site like from C# side, we have another shim layer which kind of can fall into those class C APIs. The thing I would say in terms of documentation and getting started right, to embed ChakraCore in your projects is go get the repo and for ChakraCore, you know, we have a bunch of information there including a lot of documentation, embedding guide, link to samples, where I think we are we have or we will shortly be publishing sample as to like how do you start embedding from a C# app, there's a C++ sample as well.
KYLE: So it sounds like there is an option of going down the route of what would be more traditionally seen as like Windows application development in the sort of .NET-ish world, but there's an option of going at ChakraCore just like straight out from the gnc you know, the C compilers sort of thing, is that what you're saying?
STEVE: That's right. When you were experimenting with V8, were you using C++ or C?
KYLE: Yeah, well they basically only had a C++ set of bindings, so yeah, it was just C compiler.
STEVE: ...comparison between what it looks like to bind to Chakra versus V8?
KYLE: Um, we don't have to get into too much of the details. But I just wanted to get my head around am I... if I wanted to work with ChakraCore, am I sort of getting into you have to understand Windows development, or is this more of a just straight up C, C++ kind of a thing?
PAM: Have you already covered if, do you need... I was reading that you need a Windows machine in order to build ChakraCore. Is that true?
GAURAV: So, that is correct. So today, you know, and we just open-sourced, we were primarily working on... Chakra was mostly Windows-only. And today, you need a Windows machine to build it. But one of the things that we are very actively working on is taking ChakraCore cross platform, and that's one of the top-most things on our priority list. And we're actively working with it. I think we're starting with a port to Linux, which our team was already working on, starting with I think the win tool is what we will be targeting. So as we start expanding, you know, this thing will not be a Windows-only thing. We definitely envision taking ChakraCore to a lot more platforms.
STEVE: The Linux is built with clang, so it'd be entirely independent of the Windows tool chain.
KENT: Did you have a question, Kyle?
KYLE: Yeah, I was just going to ask, so there was a story awhile back about the move from Internet Explorer to Microsoft Edge browser. And I know one of the big moves there was to remove a bunch of Microsoft-specific stuff that had been added into the environment. So as it stands today, is ChakraCore completely and entirely just ECMAScript? Or are there additional things in there that are part of the Microsoft world that are still being pulled out? Where does that stand?
GAURAV: No, it is completely and fully just pure ECMAScript at this point in time. So one of the things we did during the Windows 10 timeframe was we did this biforcation of, you know, kind of Chakra or like in the entire platform you can think about, and it is a part of that. What we did was, you know, there was this new Chakra thing that was born for supporting the evergreen browsers and we removed all of the old, you know, "Microsoft" so-to-speak things, from Chakra. And, just as an example, its active-x objects, right? ChakraCore or Chakra do not support this active motion of Active-X object now. So all of that is only supported for IE11 and the older versions, but in the Edge version of Chakra that we started shipping, we removed that. And ChakraCore actually builds out of that all-new core like we talk about, so it does not have anything that is non-standard, except of course, there might be bugs, which one cannot say that there will be no bug, but if there is, we will love to hear that from any of the users and we would work to make sure that those things go away.
KENT: So, since you brought it up, I'm curious about Internet Explorer and I sort of have two basic questions about it: first, what was the driving factor in deciding to rewrite the engine from scratch? And second, what is the future of Internet Explorer?
STEVE: Well, so first of all, we can't really speak for the Internet Explorer team, so in terms of policy questions, we'll let you have a show with them. But I would say Microsoft as a whole is moving toward supporting the web platform in its standards form and trying to be as compliant as possible. And so in order to really do that, you can't just do it from a policy level, you have to do it from a code level. You actually have to separate yourself from the old code and make sure that you have a model that actually is compliant with everything in the set of web standards. And so, I think the effort of building Edge is largely to get enough of a new code base so that you can know that you are implementing the standards correctly.
GAURAV: Also one of the questions is about why did we start with Chakra? That's a great one for you.
STEVE: You mean why was that the first effort even long before Edge?
KYLE: I had another question, sorry I'm dominating all these questions, but I'm super curious, so. Last week's episode I actually was the one that brought up the announcement that you all had made the official pull request for inclusion into node. And I'm super excited about that, but I would love for you to speak a little bit about where you see the differentiating factors between Chakra and V8 and maybe even Spider Monkey, if you could speak to it. But what makes Chakra different and what makes it compelling as an option for building something like node, for example?
KYLE: Can I stop you right there and ask you to actually explain that to the audience a little bit more? I think I know where you're going, but can you explain what you mean by JIT and why that would matter to the instruction set?
KYLE: So to summarize here if I understand, for the audience's sake, to summarize what you're saying is that one of the strengths you feel about ChakraCore is that you can have the option of running this addition JITing stuff, which target specific knowledge about the platform and the instruction set, but you have the option of not doing that, which means that it's easier to get into other environments, is that correct?
ED: Yeah, the part about not doing it is the one that I was trying to make, yeah.
I think that another is if you look at the way the TypeScript's open source project has interacted with the community, the Chakra team is planning to interact with the community in a similar way, so taking a lot of pull requests, having a very active issues list where we really take the community seriously and take their input seriously in terms of the direction that the engine will go. I think there are some differentiations there in how we plan to be an open source project. So one of the things we're hoping to do is give the community a lot more input than, for example, they have had in the direction of V8. And you can see the proof of that in how we handled the TypeScript experience.
STEVE: Like time travel.
KENT: Cool, I...
BRIAN: So, can I ask a quick question? You mentioned about memory constrained environments and I've heard things about IoT being a really interesting application for Chakra and I was curious about if you feel that's a good target. And also, I wanted to ask about some of the security features you put into the engine.
ED: I think, we'd love to hear what people want to do with it, so what scenarios they want to take it to and then help see if that is applicable, if ChakraCore is applicable there if we could, you know, maybe make it so.
KENT: So just to verify my assumption then, the reason that you would take out the JIT compiler is just so that it saves on memory because the JIT compiler like takes a lot of memory. And on these memory constrained devices that's a problem. And so am I right in assuming that that makes the tradeoff performance for size of memory? Is that kind of the tradeoff you're making there?
STEVE: That's correct. And so the Chakra interpreter has been... we started with an interpreter back in late 2008, 2009 when we started because we thought it would be the best way to make fast page loads and that's been proven out, like it's proven that most of the code on most page loads runs in the interpreter because that's the fastest path to getting the page fully loaded. And so we've had, you know, about six years of experience making that interpreter small and fast and so we think that that would be a good thing to benefit IoT environments because we've had that amount of time to tune the thing.
KENT: Sweet! Cool. So I also was kind of curious, you talked about this a little bit but I know that there's a pull request out on node right now to make node work with Chakra and I wonder if you have any updates on the status of that or like what does that mean for the node community?
GAURAV: I think the only thing that I would say to that is I think we are starting the process of having a good conversation with the CDC members and the TSC members. I think there has been a lot of, I mean, it's been a great discussion in certain ways because I think when we see and we talk to the CDC members there are some good questions that are being raised. And I think it's great for them to be given so much thought to how to evolve node, so it's going to be great for the community. I think we don't have anything concrete to say as of now as to (garbled audio), but we are really looking forward to working with them. And I think they are in the process of kind of setting up a couple of meetings to make sure that, you know, we set up those communication bridges. Because I think initially what would be the key is setting up those communication bridges and making sure that we all can work together to help them in whatever ways we can.
KYLE: I'll yield to my other panels in just a moment but just to follow up and say I 100% agree with you that performance is a major issue because that's what everybody talks about with node. The transpilation story in the browser, there's things that are slowing down a little bit... not so big of a deal, but if you take even a slight half of a percent for performance off of code that's designed to run hundreds of millions of times, people get a little bit antsy. So I think there is a little bit of concern around that and I'm glad to hear that smart people like yourselves are thinking closely about it, so that's good. Thank you.
ED: You're giving us a lot of credit.
GAURAV: Yeah. (laughs)
STEVE: Was that your question?
ED: Yeah, did I answer your question?
STEVE: I was just wondering like were you asking are engines irrelevant at this point because we're all going to have a much higher level view of what's going on or...
PAM: I mean yes, a little bit of a chaos question, but I'm just trying to get the other panelists to talk a little more too. But I know Brian had a point, maybe his will stick better.
BRIAN: (laughs) No, I just have a quick question about do you have any thoughts on formalizing which engine could run with a code? So maybe a flag or some kind of npm line for the module system. Perhaps there's a way to actually tell that this code can work with your engine only. Have you thought any about that or...
ED: I wouldn't say that we've got to that sorts of details. At this point really it seems like mostly around the conversations are directed around node community, you know, deciding it all, whether or not multiple VMs is good for them. And then, once we cross that bridge and should they believe that it is indeed a good thing, then we can start talking about how to actually go and execute on such a thing.
BRIAN: Well I guess the reason I bring it up is I've seen stuff in the Scala community where they actually in a package manager justify what compile version and things like that. And I think it at least helps the community a little bit more saying like, "Oh, I'm using specific stuff and if anybody is going to partner with npm with someone..." (laughs)
ED: It's certainly a reasonable suggestion to think about and being explicit about your dependencies is always a nice thing to do. So it makes some sense.
And one of the last things I would add like you said that there were questions about why certain features were being done a particular way or what was the ordering. I think one thing that we have tried to change over the last year or so, year and a half starting with Edge, we've been publishing a road map for what the features are getting implemented and coming online at status.(unintelligible) it's not IE, but we do have a platform priority and a road map that is published at the Edge status site. And with ChakraCore going open-sourced, we have actually taken it to the next step that all of our road map is now actually are at our GitHub repo, so get ahead and print it out and check out our road map. If you have question, et cetera, we'll be happy to answer it, like if you are looking at specific things over others.
ED: Yeah or if people have feedback. Say, "Hey, we have a good reason for why we want this to..."
GAURAV: To come first, I mean that's...
ED: Because we can hear that stuff, you know?
GAURAV: Totally. It's a two-way communication.
STEVE: So for a thing like that for the tail calls, if you look at the TypeScript open source project, which has been open sourced for a number of years now, you'll see that there's a whole bunch of issues on the issues list that are just discussions of priorities in the road map. And so we anticipate that the same thing will happen with Chakra where you can, right now, go to the ChakraCore site and you can create an issue and you can start a discussion of whether we should accelerate proper tail calls versus other things. And if it's anything like the TypeScript experience, there will be very good, high quality discussion of those sorts of things by the community. And in TypeScript, we've changed a lot of priorities based on these types of discussions. Because the community is smarter than any one team can be, right? By interacting with a broad community of people, you do get a lot of insights that you couldn't otherwise get.
KENT: Great, I think I'm afraid we're going to have to start wrapping things up. So this has been a great discussion, thank you so much for coming on. We do have one question on Twitter and if anybody is watching live and would like to ask more questions, just tweet the #jsAirQuestion and your question will be heard. So Alex Booker is just an awesome person, but he asks, "What is the origin of the code name Chakra?"
STEVE: It wasn't the original code name of the project; the original code name of the project was Eze which is a little town in France that I, I went to on my honeymoon and really liked,
But what happened was Jim Allchin and Soma, Soma is the head of Dev Div but he's, until recently now he's a venture capitalist. And Jim Allchin was the head of Windows, but he has left for other pastures as well. They made that code name up together because they were like, "We need a really great code name for this project to compete with things like Spider Monkey." And so it was made up by like two Microsoft Executives jamming in a room together.
KENT: So I was hoping you were going to say it had something to do with Naruto. If you don't get the reference, that's okay. (Laughs) Cool, okay so that's our Twitter question. So let's jump into our tips and picks and we'll let our guests go last. And again if you don't have any, that's fine, you can skip. So Brian, why don't you go first?
KENT: Cool. Thanks. Kyle?
KYLE: Okay, a couple of quick picks. This is timely, so I'm thankful that Chakra has so much great support for ES6 and has really led the way. And I'm also thankful that today, it was announced that the V8 release 49 came out and they basically are catching up to Chakra in terms of ES6 support. They're in the 90s now too. So that's a huge deal. There's a ton of ES6 features that land with that one release. So hopefully that'll filter it's way not only to browsers, but also node. As well, so ES6 is looking really good in a lot of those environments. So that's exciting. Another one is a blog post that wasn't written today, it was written a while back, but I just discovered today, it's fantastic. It's called Developer Fallacies and I had quite a bit of a Twitter rant earlier and this was one of the topics that featured in that. But developer fallacies by Haydon Works. I recommend every single listener to go and read through that blog post.
And lastly, this is going to sound strange since a lot of people know that I'm not a huge proponent of frameworks, but I'm actually going to recommend this as my final pick. I saw a friend of mine, sat down and taught me some Ember stuff and he was using a thing called Mirage, specifically Ember-CLI-Mirage which is a tool for test mocking. And it's not just for test mocking, but also for actually development mocking. He was using it to mock out API responses while he was doing development. I thought it was very cool, I'm certain there are tons of great ones out there, but I just wanted to give that one a shout out.
KENT: Great. Lin?
LIN: Okay. I only have one pick this week because this has been kind of a busy week for me, but I just finished up my Code Cartoon series on relay, which means that I'm starting a new one. (laughs) I'm starting a new set of code cartoons which are going to be about components and about the virtual DOM. And so since I've started that research, there was one article that I came across that I thought was really good if you're interested in learning more about the virtual DOM and React's diff algorithm. Christopher Chedeau actually wrote up a really good post that I hadn't seen before. It's been around for a while, but I hadn't seen it before and I thought some of the listeners might not either.
KENT: Cool. Looking forward to that new installment. (laughs) Pam, I didn't mention Pam at the beginning of the show because she showed up a little bit later, so hi Pam.
KENT: Great. Thank you. I love friendly to new contributors repositories, that's good stuff. Okay, so my first or my tip for today is get involved in open-source. There are so many benefits in doing that. And if you need help I'll actually leave a link for my answer to the question, "What project should I contribute to?" And then my pick is, "How to become a better hacker" by Gleb Bahmutov. And if you've watched my picks and my links, you'll know that I'm definitely a Gleb fan boy. He is an amazing engineer with really, really great advice and this is a great blog post about just becoming better as an engineer. So yeah, check that out. Okay, so let's go to our guests, so why don't we start out with Ed, do you have any tips or picks for us?
KENT: Awesome, we'll have a link to that in the show notes. Why don't we go with Gaurav next.
GAURAV: Yeah I think for me, Ed covered the main tip, that we all probably thought of or like we were thinking of saying, so I'm going to say something different. I think in terms of the tip, I would like if you are definitely new to open source, we would love to hear your feedback, don't hesitate to get to us. We would love to engage with you, be it on Chakra, be it on TypeScript. I think on the TypeScript site they've been doing it for a while, but get in touch. We would love to get that community feedback and be responsive. We would love to set up those communication channels, don't hesitate in reaching out. That would be my tip.