Recent efforts in V8 and DevTools for Node.js | Hacker News Reader

Recent efforts in V8 and DevTools for Node.js

v8project.blogspot.com

109 pointstweakz24 comments

> "Async/await will land in Node with the next V8 update."

You can actually try the async-await functionality with Node Current (7.2.1 as of this writing) by passing the flag --harmony-async-await:

    node --harmony-async-await app.js

It will be available without flags in the LTS release in March (that is in 3 months). Say goodbye to Callback Hell, the future of Node.js is looking pretty good.

Yes, but:

> However, Node v7 is based on V8 54, whose async/await implementation has some bugs in it (including a nasty memory leak). I would not recommend using --harmony-async-await in production until upgrading to V8 55; the easiest way to achieve that would be to wait for Node 8.

https://github.com/nodejs/promises/issues/4#issuecomment-254...

He did say to "try" it, you can use a flag. You should assume that any feature behind a flag should never be used in production.

Also, Node v7 will likely get a semver-minor update with V8 55. So, simply waiting for v7.3 or v7.4 should be sufficient and it will be enabled by default.

https://github.com/nodejs/node/pull/9618#issuecomment-264641...

Those who are sticking with the LTS release for production will need to wait until April/May 2017. March is overly optimistic by the OP as the currently scheduled date is 2017-04-30.

https://github.com/nodejs/LTS

I said March because I read it somewhere. A couple of months further, it's going to be worth the wait anyway. And yeah, flags are pretty much "try it" territory, not "use it in production" territory.

If you want to use chrome devtools without changing your version of node, I'd recommend this implementation of node + devtool that uses electron (https://github.com/Jam3/devtool).

It literally changed my life. Thanks whoever is responsible for this project.

If you're already using a version of Node that supports debugging, is this any different or better?

Yes, this app launches a chrome devtools windows (as part of electron) and lets you inspect your code using the dev tools gui which I find much more productive than the text-based CLI debugger.

I believe the comparison was not with text-based debuggers, but with the more mainstream Node.js debugging options that also provide Blink or Chrome DevTools UIs:

1. Node Inspector (https://github.com/node-inspector/node-inspector), the most prevalent Node.js debugging tool, at least until Node v6.3.0. And which also happens to be mentioned by Jam3/devtool in the Comparisons section.

2. Built-in Chrome DevTools debugging support as of node v6.3.0 (https://medium.com/@paul_irish/debugging-node-js-nightlies-w...). Simply by running:

> node --inspect foo.js

Thanks for pointing these out. I tried using the --inspect flag like your article pointed out but I couldn't get it to work with Chrome 54.

I can't really give a compare and contrast between what I'm using and the --inspect flag. From the article, I feel like I'd like --inspect better if I could get it to work.

I was confused when writing a NodeJs script last night which ES* features were supported in the node runtime I had installed (6.9.x).

This blog posts mentioned Node already fully supports ES6.

Is there a table anywhere that lists ES6/ES7 features and which nodejs version supports it natively?

I assume async/await (which I love and use from TypeScript) will only be available in Node 7.x and not 6.x.

The Node.js home-page makes node 7.x look scary unstable, is there any real-world caveats to using it?

You might find this useful. http://node.green/

Yes!

I swear I googled for something like this and came up empty multiple times. Thanks!

fyi with typescript you can target all the way down to es3 for async/await now. Certainly if you target es5 you can support any currently-supported version of node.

Node 7.x is stable. The only caveat is that it won't be supported as long as node 6. That is, it will stop receiving security updates in ~6 months rather than ~18 months.

As long as you easily update your node version there's no reason not to use it.

> Is there a table anywhere that lists ES6/ES7 features and which nodejs version supports it natively?

Why, yes, there is: Kangax's Compatibility Table.[1]

[1]: https://kangax.github.io/compat-table/es6/

Well, v8 is no longer the only alternative. Now there's Chakra as well.

https://github.com/nodejs/node-chakracore

Many native modules are however v8 modules, not sure how that may work.

Are there any benefits at the moment?

Like, use V8 if you need X, use Chakra if you need Y etc.

Well, at a high level, mostly performance optimizations.

But in the future I would not be surprised if they try to support TypeScript natively.

Now, I still don't trust Microsoft so I am not going to use it.

Not yet particularly, but the goal will only make Node better and less coupled to V8.

With a runtime agnostic Node, different vms would certainly have differing esnext features but may also be optimized for specific platforms or use cases.

Chakra supports 'time travelling debugging with reverse continue':

https://blogs.windows.com/msedgedev/2016/11/29/node-chakraco...

The number one thing Google could do to improve v8, IMO, is to give it an easy to use cross platform build system. CMake for example. V8 has repeatedly changed build systems. From SCons to Gyp and now to GN. All of these systems have been fraught with errors. Just try building the latest v8 on OSX, Windows and Linux. The SCons system was actually the most reliable. It may not have had all the fancy features of the newer build systems but it was much easier to reliably reproduce the builds.

The second biggest improvement would be to simplify the API. Using Contexts, Isolates, HandleScopes, etc. is complicated and causes the code to crash in unpredictable ways when you get it wrong. The API was built with Chrome's internals in mind and this shows.

On your remark on the enbedder api: work is underway to define an engine agnostic C api for node.js compiled addons. See https://github.com/nodejs/vm

That would be great. You should work with the Chakra guys. I've created a engine agnostic API for C++ here: https://github.com/CauldronDevelopmentLLC/cbang/tree/master/... It currently works with v8 and Chakra.

One of the key advantages of my API is that by using a "sink" interface it can be very efficient because the implementation calls the engine's API directly with out creating intermediate data. As I mentioned this is in C++ but it could easily be translated into a C API.

Let me know if you would like help with this.

That all sounds great, but... modules. The biggest thing they could do is natively support ES6 modules.

Reply on news.ycombinator.com