Node.js Node.js Interactive North America 2016, 15 Dec 2016

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Node.js & ChakraCore by Arunesh Chandra, Microsoft

Description

Node.js & ChakraCore - Arunesh Chandra, Microsoft

At Microsoft, Node.js represents a true cross platform technology that is enabling solutions ranging from cloud computing to Internet of Things and beyond. This is also aligned with Node.js Foundation’s mission of #NodejsEverywhere.

The Node-ChakraCore project wants to advance this mission and help Node.js successfully adapt to the proliferation of various device types and different workloads in recent years. In this session we will discuss the progress of Node-ChakraCore and the next steps. You can also, find out how Node-ChakraCore is innovating to improve debugging in Node.js with Time-Travel Debugging and helping grow the Node.js ecosystem.

About Arunesh Chandra
Arunesh Chandra is working on growing Node.js by extending it to use the ChakraCore engine. He is also working on supporting fresh ideas in the community like VM Neutrality for Node.js and bringing innovative diagnostic tooling like Time-Travel Debugging to Node developers.

A

Sorry, it's a positive reading, all right, very cool, all right, so my name is erina Chandra and I'm going to talk about no Chuck, our core and also you know we'll talk about some futuristic stuff, we're doing with no tracker core and also in the community project around beam neutrality. So let's get started so you know we'll talk about node in chakra, core time, travel debugging as part of this session. So it's true of hand. How do people know about chakra core?

A

Oh that's, great, pretty cool, so Chandra core is, is a a core part of the chakra JavaScript engine that powers, the the edge browser on Windows, 10 and the you know. The purple part you see here constitutes the chakra core, which is a standalone JavaScript engine on its own right and, if you add the gray parts which are windows specific bindings, that makes up the entire chakra engine that ships with Windows so.

A

Chakra core is open source. Only this year we went completely. The development is happening on. Github has been a really exciting time, working with all the smart people in the community. Ever since we have gone open source, we have received ton of PRS, and you know numerous issues found this overall, a lot of activity and engagement with the community.

A

So it's been it's been generally very great so far and as a indicate, the one of the benefits for chakra core to be open source, for you would be that you can use chakra core in your own scenarios and and also be able to kind of extend on the functionalities and maybe hopefully, contribute back. So you know open source generally. We embrace it and you know you're loving it. So far.

A

We also track record as a cross platform. It's available. It's early update, no grew up on Windows, so it's you know highly optimized on Windows. We are working on that. We have actually enhanced the experimental support for Linux and Mac OS. The the experimental support basically.

A

Is interpreter only for now, but very soon we will have a JIT and high performance GC available as well so stay tuned for that. So that's what you know about chakra core, but meanwhile you know nodejs.

A

When we look at the landscape in OGS, no Jace is everywhere, but one key architecture on arm to arm thumb to was missing when we start to look at note, no charcoal core thumb to arm temp to was important for us, because a Windows IOT core, apparently of platform. When we came out a couple years ago, it was supported, it was supporting a pump to instruction set and nodejs the default.

A

Node.Js did not target did not allow developers to target this this platform, so that actually led us to the birth of no tracker core, because we wanted node developers to be able to target this platform. We allowed no chakra chakra core, which is optimized for Windows and thumb, to thumb, to instruction set to power node and to bring that to to the node.js platform.

A

At the architecture we kind of start with was very simple: we created a shim that binded, with with the binary node with a v8 specific 8, V, 8, V bi shape and then routed. All the JavaScript calls to be served by the chocolate core engine. With this we we submitted PR and the CTC has accepted the no chakra core in a separate repo is not in the mainline, but is in a separate repo, and we are.

A

You can imagine that this was clearly a an unprecedented PR for the community to to to deal with, because you know it was never been done before, and the we are continually working with the community, the core contributors to understand and figure out a way to.

A

Responsibly, bring charter core to the main line, and you know there's we will talk about the the VM neutrality part as well, but this actually has led to those kind of discussion. So I'm going to talk about that in my landslides.

A

One important thing milestone for us that no chakra core binaries are now available at no tonight no just lightly, so it is available for all the platforms, Linux, Mac and Windows.

A

So it's easier than ever before to kind of try it out so I'll encourage everybody to you know, try them out and let us know how how you feel so. One thing I get asked there quite often is that it's all good, you know low chakras is you know doing whatever great stuff, but what's the point? What are we trying to achieve? So is the the answer is simple. No chakra core is basically trying to help grow. The node ecosystem and you know, example, would be the you know.

A

We brought in deserty core, which was not available to no developers to target.

A

The second is to bring fresh ideas on the table in a weight and advance the state of the art, so I'm going to talk about that also, and while we are doing this, we also want to absolutely make sure that we don't break this great ecosystem, which we absolutely want to ensure that nodes and ecosystem works, as it is today and also it'll, be open and transparent.

A

While we took this work.

A

So this brings me to you know the the innovation part which we talked about. We've all heard about debugging being a painful thing in nodejs, and this presents an opportunity for us to kind of figure out interesting ways to to help this community and keeping true to our purpose of innovation. As one of the guiding principle we do want to make the debugging great again, so we are partnered with Microsoft Research to push the state of the art in low GS diagnostic.

A

So, as some of you may know that we had released a time-travel debugging preview, a few months back and today, I'm going to show you some more some some other features. But now today we are also now seeing that you know it has stabilized more and we have reached a beta milestone on Windows and we are also releasing a preview bit of time travel debugging on Mac and Linux. So you know you should you should try that out as well so time from the buggin?

A

Basically, if you're familiar in the native programming languages is ability to kind of travel back in time, so it works in. You know. In a two step process, so you record a trace of the scenario you are trying to to debug and then you can debug the trace in in a familiar debugger environment and in this case vs code.

A

So I'll show you a quick demo of what it looks like so before I show the demo I want to kind of step set this up as the the sample app is actually going to mean something else.

A

So in a production environment, what happens is typically, you know um you would run into issue where you know a particular resource was intimately not available and and you're running into, and your code is running into problems and it's kind of hard to to debug that in your you know, developer environment, because that intermittent issue may not be happening.

A

So what I'm going to show here is is a sample app which is going to you know, mimic the same behavior of losing access to a resource while running. So let me just get this started here.

A

A

All right, how do I get this.

A

A

I'll have to kind of end the slide, so it looks like okay, alright. So let me get to my.

A

Tdd demo and what this demo is going to do is it's going to show that it is going to run app, which lets you browse a particular folder and show the file view of it. Okay, so I'm going to start this.

A

So this is the command line. You run node you pass in a record flag and a folder name where the trace is, is supposed to go and run your app and basically now you have this app running.

A

So this is a file viewer app. What it does is, is it.

A

A

Sorry about that.

A

It shows the the file viewer a content of a particular folder. So if you look at this, this particular folder here this app is actually showing the the view of that folder, so just to mimic that okay, there's some some resources that it is depending on is on the desk and let's say if you delete a file, so let's say the test output dialog. If we delete this file here, okay, what happens now.

A

So the app crashed, and then you know you you don't understand like sometimes what happens is like you, it happens in the production intermittently and you're, not sure.

A

What's going on, then you know you have to kind of instrument your your code for console or logs to understand what what's going on here, but instead because we have TDD going on, you can open up this code, which is you know, supporting this feature and just you know, pass TDD bug with the same trace file and then go launch this, and it is going to give you a full fidelity of the debugger to be able to diagnose that problem here.

A

So you can see, you can actually go step back, you know or or you can go step in and you know you could continue to step in the function and see what's going on and I know that this this function has an issue so I'll, just you guys cut to the chase here.

A

I'll put a breakpoint and I know that this error state is not supposed to be now, but it is coming out to be null so I'll say: okay, what happened here and it is not, but you know if we want to kind of step back in time. You know we'll see what happened here. You know we can see that we step in. Oh, it looks like we have a missing break so this you know going back and forth in your trace. You know with your trace inside a debugger. That's you know pretty powerful.

A

So this is a the TDD debugging which we are bringing to at no chakra and it's available today as beta on Windows and then preview on Mackinac, Mac and mix all.

A

A

So um about performance in my performances is a really important aspect for nose, chakra and basically, currently, what we see is what is going on sorry about that.

A

So performance is something really we care about a lot and checker core in its own is a really performant engine. If you look at the the browser benchmarks on octane and jet stream, you know it's doing pretty pretty good compared to to is competition, but on node we are making improvements and the things is moving in the right direction and obviously there's still some work to be done and we are currently working on it.

A

So that brings me to the part which is really exciting, that about William neutrality. So what is VM neutrality? The vision for VM neutrality is that nodejs becomes this ubiquitous platform application platform, which has which allows application to be run in a very highly performant way on any device and for any workload. And how do we achieve that?

A

Basically, there is a growing trend of you know, projects that are trying to fork node and claim that there are, you know the each each one of these projects actually claim that they're, better optimized for certain scenarios, so we have itj s no chakra core Mozilla has has something.

A

So, in order for note to embrace this trend of, you know people trying to make node optimize for certain scenarios.

A

Vm neutrality envisions a way that allows node to create this infrastructure for VM owners of VM authors to plug in their webs in the existing ecosystem and not having to fork it. So that's what VM neutrality is, and this is a long term multi-step process and will have to be kind of making incremental progress towards that, and in that, in our first step. What we're talking about today and I'm going to show you a demo of that is a bi-stable node. It's also called node API.

A

So what this is about is native modules, so I'm sure everybody is aware of problems related with native modules when node versions change like upgrading, you know and breakage is stuff like that, if you're, not, if you just do a Google search or a certian, github you'll understand what the native model problems are.

A

This actually a problem with native modules started the project called at the nan project, and now you know native modules are using nan to kind of shield themselves from these kind of breaks, but that also, even if there are not breaking changes in the bringing changes in node versions, you still have to recompile the the native modules for every version.

A

So, basically there's a you know, a bunch of people from race companies came together and wanted to take a second another crack at it and solve this problem in a way that you know, provides an ABI compatibility guarantee across different versions of node and also you know, different node VMs. So this actually no jsapi is going to create a layer on top of node something something along this line.

A

So the diagram in on your right is already left is the current state, where native modules are able to directly get into the JavaScript surface and every time there's a revanth at the modules break.

A

So what we are envisioning is that there's a nappy surface which native modules target and then they that's API surface- is guaranteed by node and its underlying VMs to to provide compatibility for.

A

So let me show you a demo for this, so the demo is very simple. What what we have done is that there is a level down native modules which has which has a so the level down a native module. Compile against this nappy surface is going to I'm, going to show how it kind of works, works across the different versions and and also different VMs.

A

So let me get this here. Real quick.

A

So uh what this is actually um e.

A

So node no 10, so I'm going to show you a native module which was compiled to work with no 10 and then, if we show that, if native might not be API server available to across different versions how it is going to be able to alleviate the pain of breakage so um I have this I.

A

Have this nappy demo app, which basically I could show it here?

A

It just uses level down and it just doesn't read and write on on the the database. So if you are, writing a writing, a value from a different version and reading a different version, that kind of actually shows that the module is working. So, let's say node um demo.

A

Ok, I'm not in the right folder.

A

Alright, so if I do this, so it is actually showing that the app is running- and here you can see the demo app is running with no 10 and I can actually add up for an entry to this database. If I go here and do.

A

Nvs, by the way, there is a handy tool to switch. So if I switch versions of well, it is going on.

A

So if so, no 10 was working and now, let's say if, if we go to node 12, which doesn't have nappies support and if I run the same app, it fails. It's saying: module 2, not self register, but if I go to a and not be enabled no 12 and if I run the same app again, we could see here that nappy node version is running this app and you can see that this node 10 version was read from the old API, the old demo. So I can add again.

A

It is adding another so he's showing the readwrite function from the the level down database with using the same same API surface without having to recompile and by the way we can try this out on node 6 too, you can see, note 6 and it has actually read the older entries written from the other database and, last but not least, if I use note, chakra and use the same app, you can see that the same app was running and got the the you know entries from written from the other note version.

A

So this is kind of a really powerful demo of what it is possible to do with the nappy, and you know this is already as initial prototype. We are working on there's ways to to kind of get involved in this project which is listed in our on our repo, so feel free to to go check it out.

A

So, at the end, what we want to say is nappy enables to VM neutrality. A VM neutrality enables node GS everywhere, and that is you know what the goals node is trying to achieve so quickly, a quick recap and we're trying to help grow. The ecosystem with you know, Windows IT, as a new platform. Advancing VM neutrality, innovating on to you know, push the state of the art by time. Travel debugging, ensuring this node system work. Ecosystem works.

A

Nappy is the the answer for that, and you know he refused some lengths to for you to try this out something road ahead items are you know we are working on the the chakra core, JIT and GC performance, and also for no chakra core. We are, you know, committed for nappy and advancing at TDD support in vs code. So with that I think we went over time, but thanks you.