
Node 8.3.0 released - binarray2000
https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V8.md#8.3.0
======
bdefore
Shame about npm5 being significantly broken, taking the wind of the node 8
sails.

[https://github.com/npm/npm/issues/16991](https://github.com/npm/npm/issues/16991)

~~~
Androider
NPM 5.x in Node v8.1 consistently only installs 481 out of 493 packages in our
node_modules folder. No errors, everything looks absolutely fine, except 12
packages are straight up missing. That was fun to debug! Both NPM 3 and yarn
produce the expected result.

That was the last straw for me and NPM is now banned in favor of yarn.

~~~
whatever_dude
I actually had the opposite happening: a project was having some real issues
with not installing proper dependencies until we started using npm 5.3+.
Things work fine now and are a bit more deterministic it seems.

It's an odd project with a lot of super strange peer dependencies, many of
them in beta or as pre-releases, so I'm sure it's nothing that happens all the
time (the joys of using React Native and Relay where everything is at an
imaginary release state). But still glad npm 5 made it work consistently.

~~~
hinkley
Same. One team is running npm@3 installs twice in CI to pick up half a dozen
modules that don't install the first time. On another project I managed to
massage the package.json to stop it from happening.

------
Phlow
Still can't get a debugger; statement to break...
[https://github.com/nodejs/node/issues/7593](https://github.com/nodejs/node/issues/7593)

~~~
erikpukinskis
It's amazing to me how blazé the Node community is about breaking the
debugger. In other language communities that would be considered sacrilege,
but in Node the response is often "meh... I just console.log everything".
Transpiling, source maps, so many hacks that barely work.

------
jnbiche
Still disappointed that Node has backed out of optimized tailcalls (edit:
should have written proper tail calls here, since that's what the past _3_ now
specs have called for, ES5, ES6, and ES2017). I think it's the only part they
haven't implemented.

I think a lot of the pushback I'm seeing against TCO comes from traditional
programmers who don't like functional programming and who think that recursion
shouldn't play any role in production software. I get that there are also some
who have legitimate implementation concerns, but the reflexive pushback TCO
gets from a lot of the V8 maintainers compared to any other new ES6 feature
seems telling to me (correct me if I'm wrong here).

What they don't understand is that JavaScript programmers are rapidly moving
toward functional programming. Already, there's a heavy functional influence
on the React community, probably the dominant frontend framework/library at
the moment. Clojurescript and Elm have had an outsize influence on the
JavaScript community, and I see more and more programmers using functional
paradigms in their everyday code (particularly maps, filters, and reductions).
I know we'd see much more recursion if it were technically feasible.

Edit: Absolutely right, my critics. I brain farted on this one. It's not Node,
it's V8. I did refer to this in the second paragraph, but stupidly blamed Node
for it in the first paragraph.

Edit 2: As I said, I shouldn't have singled out Node, particularly since it's
V8 that's making this call. But my criticism was more directed toward most of
the JavaScript implementers who seemed to have single-handedly decided that
the es6 spec was all cool except for the one part they don't like. And I could
accept the criticism that implicit tailcalls are problematic, except they seem
opposed to labeled tailcalls as well. I think there are lots of implementers
who simply don't believe that recursion has a place in "real" software. I've
not heard these exact words from an implementers before, but I've known quite
a few senior developers of my generation (40s) who have said this exact thing
to me (they also can't seem to get the difference between structural and
generative recursion).

~~~
specialist
Huh. No tailcall optimization? Then I don't understand something and have to
recheck.

I just wrote a Redis REPL (wire protocol) parser using recursion. Being so
simple, I wasn't worried about stack depth. But while stepping thru with
WebStorm's debugger, I noticed the tailcalls were (apparently) being
eliminated. An unexpected surprise.

Using nodejs 6.11.1, npm 3.10.10.

~~~
eric_bullington
It's behind a flag now, but they're eliminating it, so it will not be
released.

------
sparrish
I've been waiting for this DNS behavior change for years. Great release!

------
nessup
From the Medium post about speed improvements in this version:

> The size of a function, including it’s signature, the white space and even
> comments can affect whether the function can be inlined by V8 or not. Yes:
> adding a comment to your function may cause a performance hit somewhere in
> the range of a 10% speed reduction.

Uhh... byeee

~~~
dbbk
I can't even think of a reason why a comment would cause a 10% speed
reduction. Something has seriously gone very wrong there.

~~~
sonthonax
Agreed. What the absolute hell? This entirely contradicts how I understand
programming languages work. Whitespace, tokens, formatting, should be
irrelevant once it's all in an AST.

~~~
hdhzy
This is just a simple heuristic that's good enough for real code on the web.
Usually whitespace and comments are stripped out during build step. I imagine
this heuristic was implemented as something simple and working and that's
that.

Remember that they are not writing a monument of perfect software but
something pragmatic that should work good in most cases.

------
k__
Nice.

Any noticeable performance gains in everyday use?

~~~
__s
They link [https://medium.com/the-node-js-collection/get-ready-a-
new-v8...](https://medium.com/the-node-js-collection/get-ready-a-new-v8-is-
coming-node-js-performance-is-changing-46a63d6da4de)

I'm mostly glad it'll come with an updated WebAssembly, hopefully fixing this
bug:
[https://bugs.chromium.org/p/v8/issues/detail?id=6204](https://bugs.chromium.org/p/v8/issues/detail?id=6204)
which blocks Luwa from working in node (handwritten wasm has a tendency to run
into things emscripten would not.. I expect the same vice versa)

Will also enjoy not having to use a TextEncoder/TextDecoder shim. Kind of
weird that they went full out with Unicode there, last I recall browsers were
moving towards only supporting utf8

~~~
romanovcode
> write high performance JavaScript

Does anyone with high performance requirements writes JS? Isn't that setting
yourself up for failure on the first step?

~~~
skibz
> Does anyone with high performance requirements writes JS?

It's possible to call into C from Node. So there's nothing stopping you from
implementing performance-critical parts of a system with native code, and then
invoking it from JavaScript.

~~~
coldtea
Nothing except of it being messy and you ending up with two problems (to
paraphrase JWZ).

------
xori
I wonder if this will lead to Electron using less RAM... nah.

~~~
v0lta
It's the Chromium part of Electron that uses that much RAM.

~~~
xori
Yea? But only because the old V8 had Crankshaft running in parallel. New
version has this disabled IIRC.

