Node v4.1.0 | Hacker News Reader

Node v4.1.0

nodejs.org

108 pointstomkwok36 comments

> 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?

My guess is that it was previously implemented in nodejs C code instead of V8, and they switched the nodejs buffers to take advantage of V8 ArrayBuffers.

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

Malloc in C/C++ is not particularly fast.

Java for example does object instantiation much faster.

It's also common to replace malloc with an in house implementation for performance sensitive code.

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?

Choose 2:

- semver

- small, infrequently changing major & minor version numbers

- large, active project

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.

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.

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.

http://semver.org/

From the changelog it looks to be inline with this.

Ah yes, it does. Thanks!

There's no obligation to immediately update to 4.1.0 if you don't want to. Since there are no breaking changes all the same modules should work.

9 days. There is a bunch of commits, sure. But if nodejs team is really aiming for stability as was stated in the 4.0.0 announcement IMO they should give it longer time to stabilize.

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

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.)

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!

webpack-dev certainly does not work.

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

I've not tried 4.1

If possible, consider leaving socket.io.

If you can, check out https://github.com/websockets/ws .

Doesn't seem to have a fallback mechanism, which is pretty important considering the number of users behind proxies that don't support web sockets... of course this depends on your user base.

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?

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.

socket.io and ws are apples to oranges. ws does not provide hand-shaking, retries or fallbacks. These are important things if you're building a production app.

Consider using Primus [1] instead of socket.io, backed with either ws or sockjs.

[1] https://github.com/primus/primus

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?

In my laptop

$ node -v v0.12.7

What happened to Node?

It merged with iojs, switched to semantic versioning.

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/

The large version bump is because the Node and io projects have been reintegrating and they needed something that wouldn't be misleading for people coming from either background.

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

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.

I wonder if they changed it since this comment. It's about the same as HN for me now.

I thought it was odd how the page loads with normal text, then blinks for a second and the text gets 2x thinner. If it takes time to load your fonts, you're doing fonts wrong.

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.

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

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.

Reply on news.ycombinator.com