Node v9.4.0 | Hacker News Reader

Node v9.4.0

nodejs.org

88 pointsstablemap39 comments

I'm always impressed by some of the optimisations they find: 0aa403b649 improves readDouble/readFloat in buffers by 200-800% simply by...moving the code to plain javascript binary operations instead of the C++ runtime.

My understanding is that transitions between C++ runtime and JS context are relatively expensive.

What generates that improvement percent confidences that was included in that commit?

Yeah, could be that you see 200% improvement on first call and then proceed to suffer 2000% slowdown unless this is benchmarked properly.

Given the context it's likely the other way around

Nobody really cares if your 1 call is 20x slower though. Much better to make it 2x faster when there's 100 calls

I was talkiing about the tooling that generated the output, but this is a valid point too. Still want to know what the tooling is.

They probably just timed execution with a few thousand samples and compared results. Nothing too fancy either way, I think.

AWS Lambda is still only supporting Node.js 6.10, they need to move faster...

And Google Cloud Functions are running v6.11.5 [1]. Not much better. Ancient LTS release, and three months behind on patch release.

[1] https://cloud.google.com/functions/docs/concepts/exec

You can run any Linux binary you'd like if you bundle it yourself. Just use the built-in node runtime as a shim to run your process. It doesn't have to be newer node version Node either ... you can use it to run any standalone executable.

So this mean having a multi megabytes zip for the function instead of 1kb with a native runtime, this also affect cold start loading time of the lambda function ...

Does this really affect the cold start? Even if you use the native runtime it still is running in a separate container and you need to start the node process anyway. (Honest question, didn't measure it).

The size would definitely be affected.

True.

I read that someone builds a Reason/OCaml library with Node.js like API that compiles to native binaries, but uses OCaml standard libary functions in the background, which could probably get much smaller than Node.js.

Azure App Services / Functions support up to 8.9.3. They move pretty quick to add new node releases.

Bluemix's OpenWhisk has been much better about keeping up with Node.js releases FWIW. (I used to work for IBM.)

For the longest time they were still on 0.10. (deprecated 11/16, fully removed 4/17)

I'm still awaiting async iterables [1] in Node.js. It's not part of ECMAScript yet, but I'm still excited for it. Chrome 63 and v8 6.3 enables async iterables, but this Node.js version (v9.4) uses v8 6.2 so no async iterables yet. Does anyone know whether a version of Node sticks with the same version of v8 throughout? So, is there any chance that a node version 9 will have v8 greater than 6.2?

[1]: https://github.com/tc39/proposal-async-iteration

I believe that Node has been treating v8 upgrades as semver major breaking changes as it changes the ABI for native extensions, even though there are enough mitigating tools these days that most native extensions don't break on v8 upgrades.

I hope they release a cross platform installation script or binary that can manage multiple versions like nvm(doesn't work on windows). Hmm, since I'm learning Go now this might be a good exercise.

Depending on what you're doing, you could try npx: https://medium.com/@maybekatz/introducing-npx-an-npm-package...

Im talking about installation in a new system or a docker container.

nvm works on Windows for me?

Same here. It's a separate application from the non windows versions though. I seem to remember having to search explicitly for the windows version.

Do you use Chocolatey? I just did `choco install nvm`.

https://chocolatey.org/

You may be running nvm-windows, which is a separate project run by different developers.

I use 'nodist', which happens to be written in Go, if you need some inspiration!

oh yeah great one. Thanks.

It's a shame that updating node via homebrew is such a pain that I probably will skip this version.

Maybe it's just me, but every upgrade corrupts the global node_modules.

http://yoember.com/nodejs/the-best-way-to-install-node-js/

I'm not sure how homebrew works but most of the node version managers will keep independent global installation folders for a version of node.

You could try using something like nvm which has a command to migrate your old global modules.

nvm install node --reinstall-packages-from=node

Are you talking about native modules that need to be rebuilt when the V8 version used by node is also upgraded?

Shouldn't nvm (node version manager) work? I rarely install node via any package manger, nvm provides some nice management features.

https://github.com/tj/n is also a good version manager for node.

--no-check-certificate for something that is intended to install software is unacceptable.

https://github.com/tj/n/pull/475/files

I guess nvm is better, needs some polishing, though (error prone for scripted usage, because of unpredictable exit > 0 behavior.

https://github.com/creationix/nvm

I tried nvm and it didn't even install correctly. I tried n just now and it works beautifully! thanks for the ref. Nice that it is from tj.

Why not use a version manager like n or nvm?

any signs yet of support for Web Workers?

Web Workers are a browser only framework. You can use child_process.fork: https://nodejs.org/api/child_process.html#child_process_chil...

or maybe WebWorker Threads for API compatible framework: https://www.npmjs.com/package/webworker-threads

Take a look at microsoft's napajs: https://github.com/Microsoft/napajs

Reply on news.ycombinator.com