
Node v4.1.0 - tomkwok
https://nodejs.org/en/blog/release/v4.1.0/
======
georgerobinson
> Buffers are now created in JavaScript, rather than C++. This increases the
> speed of buffer creation.

How can this be possible? How can allocation via JavaScript (which I assume
must call malloc underneath) be faster than just malloc in C++? Does Node have
a slab allocator for buffers like the Linux kernel has for task structs, or
are objects allocated on the heap on demand?

~~~
phpnode
It's not the allocation itself that's faster, it's faster because it avoids
the overhead of crossing the C++ -> JS barrier

------
HorizonXP
Uh, didn't 4.0.0 just come out? Seems rather quick, no? How much could
possibly have changed? The buffer creation change warrants a point bump?

~~~
bryanlarsen
Choose 2:

\- semver

\- small, infrequently changing major & minor version numbers

\- large, active project

~~~
wolfgke
No, choosing all 3 is possible, too: Let semver hold, we have to prove that
choosing 2 and 3 is then possible, too:

For 2: Since semver implies that the version numbers increase fast with the
number of releases, 2 can hold, if we only rarely release new versions. Note
that this does not imply that it isn't large and active. For an example: If
creating new releases takes a lot of time, few new versions will be releases,
but the project can still be very active. To give a (slightly artificial)
example: If (because of quality standards of the project) any release will
also contain a machine-checked proof of correctness, creating a new release
will take a long time.

TLDR: A large, active project that only rarely releases new versions, but
names them semantically has all three properties.

~~~
tracker1
There was a change that added or significantly changed functionality... this
necessitates asemver minor bump.

Point releases are generally for non-breaking patches or bug fixes.

~~~
wolfgke
I know what semver is. But my claim was that if you _want_ all three claimed
properties (which are claimed as incompatible), you can have them _all_.

------
kenOfYugen
Seems like the io - node merge is working well so far. Frequent releases in
the non breaking stable branch are the way to go.

------
applecore
Is v4 ready for general use? Or should we continue using v0.12? (The main
concern is compatibility with all the popular libraries in npm, the Node.js
package ecosystem.)

~~~
cvburgess
A lot of libraries have been following the iojs track (v1, v2, v3) so many
libraries are already in place to support v4 out of the box. The best way to
know though is test _your specific packages_ in a dev branch or sandbox
environment and see what breaks - tests help automate this if you have them!

~~~
mb22
webpack-dev certainly does not work.

~~~
chisleu
socket.io is a big deal, and it breaks on 4.0.

I've not tried 4.1

~~~
angersock
If possible, consider leaving socket.io.

If you can, check out
[https://github.com/websockets/ws](https://github.com/websockets/ws) .

~~~
chisleu
Never heard of it. Thanks!

I'll take a look at this. I only recently started using socket.io in my
express site, so I'm not too deep down the rabbit hole. It seems to have close
to the same syntax.

Any reason why you support ws over socket.io?

~~~
angersock
Socket.io is kinda big, the documentation is not great, there's a lot of
baggage there from it's history, etc.

ws is faster, and most browsers now support web sockets properly.

If you want some isolation, there are various shim layers that are available.

------
discreditable
Does it seem odd to anyone else that for verifying integrity they distribute a
GPG-signed list of SHASUMS? Why not create a GPG signature for each blob?

------
hammerha
In my laptop

$ node -v v0.12.7

What happened to Node?

~~~
dcchambers
io.js merged back in to node.js, and since they were so far ahead in version
number, node jumped to 4.0 from 0.12.x.

[https://nodejs.org/en/blog/release/v4.0.0/](https://nodejs.org/en/blog/release/v4.0.0/)

------
xigency
I don't like how they altered the scroll on their webpage.

~~~
currysausage
I don't like how they altered the font on their webpage to something that is
so thin that strokes are only visible as subpixels. Glad the API docs use a
readable normal-weight font instead.

If you need to visually "hide" the text in order to make it look "clean,"
you're doing typography wrong.

~~~
xigency
I'm fine with the fonts, I just noticed when I middle-clicked to scroll the
page, the page moved like it was underwater. Really unnecessary for a text
document.

The offending CSS is:

    
    
       html { scroll-behavior: smooth; }
    

Only noticing this issue in Firefox.

~~~
nilliams
As that is a CSS spec, the implementation of which you don't like, it's the
browser that's offending, not the CSS.

~~~
xigency
Sure, if you like to read while you're wading through butter. It's a usability
thing.

Anyways, they do it on their whole site, and it's more cohesive on the other
pages. It's better to view the release notes in readerview I guess.

