CHUCK: Hey everybody, we are back. We’re doing another interview here at Build. AJ is here.
AJ: Yo, yo, yo, coming at you live from Microsoft Build.
CHUCK: Yeah, I know, right? We’re also here with Gaurav Seth. He’s a Microsoft engineer on Chakra. Is there anything else you want to say [inaudible] introduction?
GAURAV: Yeah, I love to be on your show. Thanks. Hello everyone. I work on both Chakra as well as TypeScript projects. So, happy to talk to you guys today.
CHUCK: And I think we’re going to be talking to Anders later on about TypeScript. So, I think we’re going to…
GAURAV: [Inaudible] is on the list.
CHUCK: We’re just going to focus on Chakra.
GAURAV: Yeah, that would be awesome, yes.
GAURAV: Yup, yup.
CHUCK: V8 is becoming much more of a thing with Node.js.
CHUCK: And so, when we see Microsoft backing Node.js…
CHUCK: So, where does Chakra fit in with all this? We see it in IE and Edge.
CHUCK: But are there other…
CHUCK: Oh, that would be cool.
GAURAV: So, if you look at it even though a lot of people know about Chakra only thinking it’s only Edge or IE, it is actually a lot more spread out than just being used in those two scenarios.
CHUCK: And we’re not talking like Electron and Node. We’re talking Chakra?
CHUCK: And can you write… so, now I’m going to throw a whole bunch of platforms at you and you can say yes or now. Windows Phone?
CHUCK: No kidding.
CHUCK: That’s awesome.
GAURAV: Yes. So basically, it’s the whole motto of universal Windows platform, is you can write apps in any language that you want and they are supported across the entire device family that is supported by Windows, right?
CHUCK: Right. So…
AJ: So, well two things. One, Mozilla had a project where they tried to abstract Node and that just fell by the wayside.
AJ: So, are you guys committed to seeing this through and helping that funding, like it’s going to happen? We will have Node?
GAURAV: Yes, we are a hundred percent committed to make that happen.
GAURAV: And we’ve been talking to a lot of people. I think everybody has a different point of view. I think when Mozilla started doing this that was way early when Node was really, really young. And I think at some point in time they lost a couple of people who were actually working on that effort. And they didn’t support it beyond that point.
AJ: Well, and before Microsoft got involved in Node it probably wasn’t abstracted enough…
AJ: To really take that on.
GAURAV: Yes, exactly.
AJ: And it’s been Microsoft’s massaging of getting those critical pieces separated that’s…
GAURAV: That is so true. And then that’s… I mean, one of the things for us is we are a hundred percent committed to help Node succeed. The biggest thing we see here why Chakra would help Node is because having more than one engine being available in the Node ecosystem is really going to help the Node ecosystem growth. It is going to help take Node to different, newer platforms or different platforms or different places. Different people can actually optimize the developer experiences, the tools that are available, based on multiple engines that are being available today. Everything is just constricted or restrained to, “Hey, here’s the stack and you can only work against that stack” and it’s all about opening that thing up. So…
AJ: So, it kind of makes Node almost like a browser in the sense that you have a common standard API set but different backends…
GAURAV: That is [correct].
AJ: And different specific features.
AJ: Except that they do right now.
GAURAV: No, and again…
CHUCK: Yeah, some do.
GAURAV: Yeah, some do. And again, the thing is even in those features it’s not that the VM implementers are very far behind. One VM has implemented it but the other virtual machine is going to implement it years later. It’s just a matter of months that we are looking at. And all of those, like I think with evergreen browsers becoming a reality, everybody first puts things out in experimental mode and then brings it in.
AJ: And that’s what I meant by specific features.
AJ: I didn’t mean necessarily that you’re trying to diverge but rather like right now Node has command line flags.
AJ: That if you pass it you’ll get experimental features that may or may not…
AJ: Make it into a future version of stable [inaudible].
GAURAV: Yes, exactly. And I think from Chakra’s perspective what we have been trying to do is we created a shim which makes Node think that it’s talking to the V8 engine itself. But that shim actually talks to Chakra instead of V8. And our goal has been to light up the exact same experience that devs have today when they’re using Node which is working with the V8 engine. One of the things I can take as an example here is one of the things our team has been working on is providing the same amount of debugging support that Node developers are used to. So today, if you go open Visual Studio Code you can actually start debugging Node. We’ve been hearing from developers it’s a great experience debugging Node in VS Code.
And over the last three months since we took Chakra open source, one of the things we announced was we’re going to be working on these modern debugging APIs that are going to be… we can make them inter-operable with other implementations and take them across tool chains. And we now have made such progress that now we have such APIs where you take Node running with V8, you can debug it with VS Code. You replace it, you have Node running with Chakra, it just works. And that’s the thing that we are trying to work towards is, “Hey, what is that neutral API surface that we got to look at so that from a Node development perspective it remains very easy for Node developers while others in the ecosystem can come and differentiate?”
Our goal here is not at all… I mean I want to be very clear, our goal here is not at all to try and replace V8 in Node because I think having more than one engine is going to be great for Node. And our plan is to just help Node grow its ecosystem.
CHUCK: So, you’ve said two things that kind of make me wonder a little bit. So, the first one is you basically said that it would be a good thing for Node to be able to run V8 or Chakra or maybe something else.
CHUCK: The flip side of that is that you also talked about how both V8 and Chakra are mostly interchangeable. So, I’m wondering what would be the advantage then of having Chakra on Node?
CHUCK: Other than maybe being able to debug something on a system side runtime instead of having to fire up a browser. I’m trying to figure out, okay, so what circumstances would lead me to say, “Okay, I want my Node to be running Chakra instead of V8.”
CHUCK: Oh yeah, that makes sense.
GAURAV: [Inaudible] performance, right? And as a developer when you’re writing a particular application in the browser you end up testing, where is my application actually running fast or running slow? So, we have different performance characteristics. V8 has different performance characteristics. And for specific scenarios, a specific engine might do better. So, that’s one way where developers, having choice for developers is great.
CHUCK: That makes sense.
GAURAV: Another such example is in terms of the architectures of the engine, that itself is different. For example, Chakra has always supported an interpreter from the get go. We have a multi-phased pipeline where we start with the interpreter and then we compile code and start executing code. That’s really useful for very early, very, very quick startups. V8 today does not have that. And having an interpreter basically implies that you can actually port an interpreter to any other platform very, very quickly because you don’t have to rewrite the JIT compiler which is all written. Of course, both of them are in native code. But it takes a lot more time to take a JIT compiler and make it portable or make it work on another platform. Whereas if you have an interpreter it can go to another platform very, very quickly.
I’m kind of hypothesizing here, but let’s assume that you had to take Chakra to PowerPC. So, the amount of work that is needed to take just the interpreter piece to the PowerPC is much, much smaller. It is much easier to go there. However, taking the full JIT to that point is a much more involved effort. So, that’s how we are imagining that this ecosystem will grow.
AJ: So, if I wanted Node on a MIPS router that will probably never happen with V8 Node. But with Chakra Node it might be more possible?
GAURAV: Possibly. An interpreter is a very easy thing to port.
CHUCK: Gotcha. So…
GAURAV: That said, I should also say I think the V8 team is also working on an interpreter. So, once that becomes a reality probably in perspective that is doable. These are just some examples. And I would also call out, sorry I’m cutting you but…
CHUCK: No, go ahead.
GAURAV: Most of the standardization typically happens from a web [inaudible] perspective, like the web browser perspective. And as TC39 has progress, ECMA has progress, now we’ve defined stages of, “Hey, we would want…” like there’s stage zero, stage one, stage two, stage three, and stage four for different proposals that we have. And to get any feature, to get to stage four which means that it is going to come into the specification you need more than one VM implementation to be there. So, Node today has only one VM which is running there. At least having two VMs, there are two implementers who can also think about features from a server-side perspective instead of just thinking about them.
AJ: And that would be so nice because I’ve wondered so many times why Node seems to get ignored. It’s almost like it’s the red-headed stepchild of the community sometimes because the community should be together but it seems they fight.
GAURAV: I completely [inaudible]
AJ: They want to ignore each other. Node wants to specifically sometimes do things not the browser way just to be incompatible and vice versa. Browser implementers, I can’t remember what it was but I remember during the standardization process Node has already solved many problems and some of the standards that are written for HTML5 that came well after Node like buffers…
GAURAV: Yes, yes.
AJ: Completely incompatible implementations. Like, why?
AJ: That’s good.
CHUCK: Yeah, that makes sense. I can also see that some people may dismiss Node by basically categorizing it as V8 and then saying, “Well, if it works in Chrome” but in reality that’s not the way that it actually works.
CHUCK: So yeah, it’s really, really interesting. I’m curious as you talked about the standards. And so, we’ve got the ES 5 standard and now we have the ES 2015 standard. So, where is Chakra with implementing that? And maybe ES 2016, 2017, some of the standards that are now coming down the line, where are you at with implementing those features and how do you decide and how do you make that all work?
GAURAV: Yeah. Great question. So, I think ever since… when it was released it was still ES 6 before it became ES 2015. So, Chakra has been actually leading in the implementation of ES 6 or ES 2015. ES 2015, I always get confused in the year…
CHUCK: Yeah, [laughs]
GAURAV: That you connect. So, we’ve been leading. And today I think one of the things we will be doing soon in the previews to come is we are actually now, we’ve already implemented almost all of the ES 7 or ES 2016 feature set. So for example, the array includes is there, the exponentiation operator is there. And we already are also supporting some of the more future stuff. For example with have experimental support for [Assembly] JS. We already have experimental support for async functions which we would like to enable by default. So we are, being ahead in the whole standardization process is like a two-pronged thing. It has its pros and cons. When you do things early from an engineering perspective at times the spec changes and you have to throw away that work, right?
GAURAV: But the thing that it actually really enables and the reason we want to be at the forefront of picking up those features and implementing it is that it actually gets implementers feedback back into the standardization process. So, as part of the whole ES 6 evolution or ES 2015 evolution there were so many instances where we implemented that feature set, ran it across the web, got some data back to the committee and say, “Hey, this particular functionality or capability, if we do it this way is going to break the web in this way.”
CHUCK: [Laughs] That’s the truth.
GAURAV: That’s the thing I would say. So, it comes with its own pros and cons. But I always look at it and we feel that the pros really over-weigh the cons. Being ahead, being early helps get that implementation feedback back into the standardization process to help evolve the spec in a better way.
CHUCK: So, what’s coming down the line with Chakra now?
GAURAV: So, I think one of the biggest things as I said, we went open source in January. It’s called ChakraCore. ChakraCore is similar… it’s the same exact core that Chakra shares with a couple of differences.
CHUCK: That makes me want to cheer.
CHUCK: I love it when these projects that people are using are out there that can make a difference, make a statement.
CHUCK: They go open source and say “Hey look. We appreciate the community and we want the community to be involved.”
GAURAV: Yes. And for ChakraCore one of the biggest things on our agenda, our road map is published publicly on our GitHub repo but one of the biggest things we are tracking is taking ChakraCore cross-platform. We are actually going to start with Ubuntu. We’ve actually started making very good progress on that. And we now have our GC actually running on Ubuntu which is great. In the last three months we’ve made such good progress. So, that’s number one. Taking Chakra cross-platform is number one on our [inaudible] map.
And number four I would say is one of the big things we did was between Chakra and ChakraCore our takeaway was we took back the debugging APIs which Chakra supported because they were Windows specific. And given that cross-platform was our goal, we wanted to have these new modern APIs. So, we’ve actually now made a lot of substantial progress in those modern APIs, modern debugging APIs that I was telling you. That you can now take VS Code and just run Node with Chakra there. And the goal is to bring them to mainline and ship them out. So, those are the four big pillars I would say that we are working on.
GAURAV: Yup, that’s correct.
CHUCK: Can I pile on with that?
CHUCK: You said that Outlook.com or whatever, was written in Chakra.
GAURAV: I mean they’re using Chakra. They’re hosting Chakra for some of the work that they do.
CHUCK: Okay. So, is that what AJ as how they’re using it?
GAURAV: Yes, yes. Basically…
AJ: So, it’s a .NET framework is interfacing with it and…
GAURAV: It could be .NET. It could be C, C++, it could be anything that you want to interface with.
AJ: Well, what is Chakra?
AJ: No, I mean like the language that it’s written in.
GAURAV: Oh, Chakra is written in C/C++.
AJ: Oh, okay. I thought it was…
GAURAV: No, no. It’s all written in C/C++.
AJ: I thought it was .NET. Okay, okay.
GAURAV: Yeah. So, it can interact with any languages though. There’s always, you can do marshalling across different languages and work across it.
GAURAV: And so, it’s Chakra that is powering that service as an example.
AJ: Okay. And then so, you’re talking about how you’re trying to make the API interface the same as V8 so that tools that are currently built around Node with V8 will work just as well. But you’re also targeting performance. So, is there any conflict there where your shims decrease performance? Or is it all negligible? Or is it arbitrary?
GAURAV: So, I think that’s a great question. And I would say that from the preliminary results that we are seeing, it’s a mix. There are certain cases where we are faster, we are much faster. There are certain cases where we still need to catch up. I think this was what we really wanted to do as a first step was to actually write the whole thing so that we can believe ourselves that first it is doable. And the first step is now that we have crossed that first step, now comes the second step of, “Okay, let’s make this [mode] performant as well. All of those things can be made performant. So, that’s just a matter of time is all I think. But eventually yes. If it’s a mixed bag it’s not like I can say it’s one way or the other. There are certain things that definitely perform better. There are certain that don’t.
CHUCK: Yeah, my experience… so, listeners to the show know that I have come mostly from a Ruby background.
CHUCK: But four or five years ago, a lot of the conferences would have at least one or two talks comparing different Ruby VMs.
CHUCK: So, they would have the timestamps or where they measure the speed and they would basically yeah, it would be “So, this Ruby implementation is way faster than this one doing this” and then the next slide would be “And it’s not so much faster doing this.”
GAURAV: Right, right.
CHUCK: Or “It’s much slower doing it” and so it just depends on the way it was implemented and how things came together.
CHUCK: And then what they could optimize afterwards.
AJ: So, I’ve noticed on Raspberry Pi when I run Node, oh it can be so slow. And same thing if you’re using an Android phone, their processors on Android phones are sub-par because I don’t think the browsers get implement to use multiple cores. So, visiting web pages on Android phones is slower. And I think that’s in part due to that ramp up time that it has.
GAURAV: It possibly is. I am not an expert in that.
GAURAV: I’ve not looked at how they perform on the Android phones. I have looked at them from a desktop perspective [inaudible].
GAURAV: Right, right.
GAURAV: You have to imagine that it’s a pipeline where you have steps of work to be done. So, let’s go through it.
GAURAV: Native code that runs.
GAURAV: In Chakra we start running with the bytecode but give that to the concurrent threads that we have. So, we take advantage of concurrency that is available on multiple cores that are available on your hardware. And this is true across any devices like be it the Raspberry Pi, be it phones…
AJ: Okay, that sounds really, really…
AJ: Cool. Because I try to track down where some of my problems were on starting an application.
AJ: And it’s Node’s vm.compile.
AJ: That is…
GAURAV: Yes. So, it does take time. It’s not free.
GAURAV: So, there are these steps that you have to go through. Some of these steps you’ll have to go through even when you’re interpreting. But with interpreting you can just start running very quickly.
AJ: Yeah. That sounds awesome.
CHUCK: Now, I know that you wanted to get to this other session. So, we’ll go ahead and wind down. One thing that we do as part of our show though before we let you go is we do what are called picks. And basically it’s just, some people pick TV shows. Some people pick coding tools. It can be anything that you’re just into right now.
CHUCK: So, what is it that you’re into right now? Just one or two things.
CHUCK: Awesome. And then if people want to check out ChakraCore or find out more about Chakra and where it’s implemented and how they can start experimenting with it, where do they go?
GAURAV: I would say start with the ChakraCore GitHub repo. That’s the best place for you to get started.
CHUCK: Awesome. And then are you on Twitter or GitHub where people can follow you?
GAURAV: Yes, I am on Twitter.
CHUCK: Okay, what’s your handle?
GAURAV: My handle is @gauravseth. That’s G-A-U-R-A-V-S-E-T-H.
CHUCK: Okay. Awesome.
CHUCK: And then just to wrap up I also am just going to kind of pick Richard Campbell and Carl Franklin from ‘.NET Rocks!’ for inviting us out. It’s been fun. We’ve gotten to talk to a whole bunch of really interesting people. And this has just been a great experience. So, thank you and thanks also to them for setting all this up.
GAURAV: Oh, thanks for having me over. And it was great talking to both of you guys.
[Bandwidth for this segment is provided by CacheFly, the world’s fastest CDN. Deliver your content fast with CacheFly. Visit CacheFly.com to learn more.]