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?
I swear I googled for something like this and came up empty multiple times. Thanks!
As long as you easily update your node version there's no reason not to use it.
Why, yes, there is: Kangax's Compatibility Table.[1]
https://github.com/nodejs/node-chakracore
Many native modules are however v8 modules, not sure how that may work.
Like, use V8 if you need X, use Chakra if you need Y etc.
https://blogs.windows.com/msedgedev/2016/11/29/node-chakraco...
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.
With a runtime agnostic Node, different vms would certainly have differing esnext features but may also be optimized for specific platforms or use cases.
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
> 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...
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.
It literally changed my life. Thanks whoever is responsible for this project.
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.
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.