Live data from Hacker News

Node v4.0.0

nodejs.org

241–250 of 277 posts

Re: Node v4.0.0

#241
post #62

Earlier quoted context omitted.

You seemingly have much more experience with Node than me. Perhaps my amateur anecdotes are just bad luck, but certainly my Bash scripts that talk to Node break frequently.

I think the npm project should document best practices, like when to use "*" version, when to use npm-shrinkwrap, etc... to limit problems. NPM is a very powerful tool. In fact, it's our deploy tool: we run `npm install` on servers (private Sinopia npm repository) to deploy. But to do that, you must follow many many rules that are written nowhere.

We used to do this and it caused a lot of issues. Shrinkwrap is a must to keep versions stable. NPM and network unreliability can cause failed installs, as well as other issues.

Our first major improvement to this work flow was a tar of the app with all of the dependencies coupled with `npm rebuild` after unpacking. This worked quite well.

However, recently, we have switched to using Docker to generated this sealed packages which is working great.

Re: Node v4.0.0

#242

Earlier quoted context omitted.

"On the right track" does not mean "production ready now". Some time needs to pass in order to create the confidence necessary.

Tell that to the big companies who use it in production right now. Microsoft, Netflix, PayPal, Walmart.

Because big companies never make mistakes? The people who work for big companies never get caught up in a circle-jerk of cool-kid syndrome?

Re: Node v4.0.0

#243
post #19

Guys, does V8 still deoptimize on ES6 features? For example, would using say const/lets in a function prevent V8 from optimizing it as a whole? That was the case some time ago when these features were still under a flag.

const/let in particular does not prevent optimization. You just need to use "use strict" in order to use them.

Re: Node v4.0.0

#244

Earlier quoted context omitted.

I didn't know what bad documentation was until I used Ruby. I'll take Node's docs over Ruby's any day.

> I didn't know what bad documentation was until I used Ruby. Really? I mean, you probably could have made any other point and have it hold even the slightest amount of water. OK, let's help you out on finding some good documentation on Ruby: http://ruby-doc.com/docs/ProgrammingRuby/ http://ruby-doc.org/ https://en.wikibooks.org/wiki/Ruby_Programming http://mislav.uniqpath.com/poignant-guide/book/chapter-1.htm... htt…

And btw that's one of the winning points of PHP. Let me find some great documentation for you: http://php.net . That's it, one link is enough.

Re: Node v4.0.0

#245
post #36

0.12.7 -> 4.0.0 Best versioning convention ever :)

Actually it went: 0.12.7 -> 1.0.0 -> 1.0.1 -> 1.0.2 -> 1.0.3 -> 1.0.4 -> 1.1.0 -> 1.2.0 -> 1.3.0 -> 1.4.1 -> 1.4.2 -> 1.4.3 -> 1.5.0 -> 1.5.1 -> 1.6.0 -> 1.6.1 -> 1.6.2 -> 1.6.3 -> 1.6.4 -> 1.7.1 -> 1.8.1 -> 1.8.2 -> 1.8.3 -> 1.8.4 -> 2.0.0 -> 2.0.1 -> 2.0.2 -> 2.1.0 -> 2.2.0 -> 2.2.1 -> 2.3.0 -> 2.3.1 -> 2.3.2 -> 2.3.3 -> 2.3.4 -> 2.4.0 -> 2.5.0 -> 3.0.0 -> 3.1.0 -> 3.2.0 -> 3.3.0 -> 4.0.0 You just weren't paying at…

If you include io.js, sure. Node did technically jump considerably.

Re: Node v4.0.0

#246
post #130

Earlier quoted context omitted.

For the benefit of any who are not sure what you are talking about, could you please elaborate on what some of these "better ways to handle that" are? It would make your comment much more helpful, IMHO.

Anything other: blocking in an Erlang like system, actors, CSP, real continuations, async/await, etc.

What are the differences between what you reference as "actors" and "CSP"?

Re: Node v4.0.0

#247
post #113
post #51

Earlier quoted context omitted.

...all you have to do is re-install it with the GUI installer and you're good to go And fix all the incompatible changes in your own code.

It's backwards compatible and works fine from what I see

this is not true. Had problems with webpack and flux packages on old projects. io.js and node.js 4.x is not always compatible to old 0.12.x node.js !

Re: Node v4.0.0

#249
post #241

Earlier quoted context omitted.

I think the npm project should document best practices, like when to use "*" version, when to use npm-shrinkwrap, etc... to limit problems. NPM is a very powerful tool. In fact, it's our deploy tool: we run `npm install` on servers (private Sinopia npm repository) to deploy. But to do that, you must follow many many rules that are written nowhere.

We used to do this and it caused a lot of issues. Shrinkwrap is a must to keep versions stable. NPM and network unreliability can cause failed installs, as well as other issues. Our first major improvement to this work flow was a tar of the app with all of the dependencies coupled with `npm rebuild` after unpacking. This worked quite well. However, recently, we have switched to using Docker to generated this sealed p…

We've never really had a problem... Our sinopia npm server is probably isolating some network problems, plus we don't start/update servers that often.

Our NPM workflow also ensures builds are easy to replicate. Most problems in development occur because of obsolete versions of some packages (our apps contain many private modules)... Clean npm-installs shields us from that in production.

Post reply on HN