4 ms·

Recent efforts in V8 and DevTools for Node.js

109 points by tweakz 10y ago

hackcrafter 10y ago
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 10y ago
  You might find this useful. http://node.green/ http://node.green/
  - hackcrafter 10y ago
    Yes! I swear I googled for something like this and came up empty multiple times. Thanks!
- netcraft 10y ago
  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.
- nicoburns 10y ago
  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.
- __derek__ 10y ago
  > 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/ https://kangax.github.io/compat-table/es6/
alistproducer2 10y ago
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 10y ago
  If you're already using a version of Node that supports debugging, is this any different or better?
  - alistproducer2 10y ago
    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 10y ago
      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-with-chrome-devtools-7c4a1b95ae27#.knjnbsp6t https://medium.com/@paul_irish/debugging-node-js-nightlies-w...). Simply by running: > node --inspect foo.js
      - alistproducer2 10y ago
        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.
partycoder 10y ago
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__ 10y ago
  Are there any benefits at the moment? Like, use V8 if you need X, use Chakra if you need Y etc.
  - sscotth 10y ago
    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.
  - partycoder 10y ago
    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.
  - mastax 10y ago
    Chakra supports 'time travelling debugging with reverse continue': https://blogs.windows.com/msedgedev/2016/11/29/node-chakracore-vm-neutrality/#UOcG8uW9JDikObLg.97 https://blogs.windows.com/msedgedev/2016/11/29/node-chakraco...
franciscop 10y ago
> "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 10y ago
  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-254159118 https://github.com/nodejs/promises/issues/4#issuecomment-254...
  - sscotth 10y ago
    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-264641321 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 https://github.com/nodejs/LTS
    - franciscop 10y ago
      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.
- deleted 10y ago
  [deleted]
jcoffland 10y ago
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 10y ago
  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 10y ago
    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/src/cbang/js 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.
deleted 10y ago
[deleted]
cwp 10y ago
That all sounds great, but... modules. The biggest thing they could do is natively support ES6 modules.

109 points by tweakz 10y ago

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 10y ago
You might find this useful. http://node.green/ http://node.green/
- hackcrafter 10y ago
  Yes! I swear I googled for something like this and came up empty multiple times. Thanks!
netcraft 10y ago
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.
nicoburns 10y ago
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.
__derek__ 10y ago
> 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/ https://kangax.github.io/compat-table/es6/

alistproducer2 10y ago

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 10y ago
If you're already using a version of Node that supports debugging, is this any different or better?
- alistproducer2 10y ago
  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 10y ago
    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-with-chrome-devtools-7c4a1b95ae27#.knjnbsp6t https://medium.com/@paul_irish/debugging-node-js-nightlies-w...). Simply by running: > node --inspect foo.js
    - alistproducer2 10y ago
      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.

partycoder 10y ago

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__ 10y ago
Are there any benefits at the moment? Like, use V8 if you need X, use Chakra if you need Y etc.
- sscotth 10y ago
  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.
- partycoder 10y ago
  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.
- mastax 10y ago
  Chakra supports 'time travelling debugging with reverse continue': https://blogs.windows.com/msedgedev/2016/11/29/node-chakracore-vm-neutrality/#UOcG8uW9JDikObLg.97 https://blogs.windows.com/msedgedev/2016/11/29/node-chakraco...

franciscop 10y ago

> "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 10y ago
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-254159118 https://github.com/nodejs/promises/issues/4#issuecomment-254...
- sscotth 10y ago
  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-264641321 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 https://github.com/nodejs/LTS
  - franciscop 10y ago
    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.
deleted 10y ago
[deleted]

jcoffland 10y ago

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 10y ago
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 10y ago
  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/src/cbang/js 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.

deleted 10y ago

[deleted]

cwp 10y ago

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