
Recent efforts in V8 and DevTools for Node.js - tweakz
http://v8project.blogspot.com/2016/12/v8-nodejs.html
======
franciscop
> "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.

~~~
wolfgang42
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...](https://github.com/nodejs/promises/issues/4#issuecomment-254159118)

~~~
sscotth
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...](https://github.com/nodejs/node/pull/9618#issuecomment-264641321)

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](https://github.com/nodejs/LTS)

~~~
franciscop
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.

------
alistproducer2
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](https://github.com/Jam3/devtool)).

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

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

~~~
alistproducer2
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.

~~~
hallmark
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](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...](https://medium.com/@paul_irish/debugging-node-js-nightlies-
with-chrome-devtools-7c4a1b95ae27#.knjnbsp6t)). Simply by running:

> node --inspect foo.js

~~~
alistproducer2
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.

------
hackcrafter
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?

~~~
eunoia
You might find this useful. [http://node.green/](http://node.green/)

~~~
hackcrafter
Yes!

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

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

[https://github.com/nodejs/node-chakracore](https://github.com/nodejs/node-
chakracore)

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

~~~
k__
Are there any benefits at the moment?

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

~~~
mastax
Chakra supports 'time travelling debugging with reverse continue':

[https://blogs.windows.com/msedgedev/2016/11/29/node-
chakraco...](https://blogs.windows.com/msedgedev/2016/11/29/node-chakracore-
vm-neutrality/#UOcG8uW9JDikObLg.97)

------
jcoffland
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.

~~~
piscisaureus
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](https://github.com/nodejs/vm)

~~~
jcoffland
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/...](https://github.com/CauldronDevelopmentLLC/cbang/tree/master/src/cbang/js)
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.

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

