Live data from Hacker News

Node v4.0.0

nodejs.org

111–120 of 277 posts

Re: Node v4.0.0

#111
post #93

Earlier quoted context omitted.

I think it means that the API is stable, it's not related to how well the software works.

Node's API stability is a wonderful and many-layered thing. While more and more of the API is moving towards stability in the colloquial "is this going to change between versions?" sense, it's still a mixture. See this section of the node docs for a description of the different classifications of 'stability' within the API: https://nodejs.org/api/documentation.html#documentation_stab...

Those are classifications, but are they definitions? It's still not clear to me that "stability" has much to do with the software performing in a consistent matter. Either way it's a careless choice of wording, I've never encountered anybody who saw the word "unstable" attached to a node.js release and understood that it might refer to the API (see surrounding comments).

Re: Node v4.0.0

#112
post #73

Earlier quoted context omitted.

> Isn't that true for many platforms? I would say that the ROI is lower for time spent learning Node. I've found that with all the other languages I've learnt, in a couple of days I've been able to build something useful, leave it running in production and reuse skills learned a year later. With Node, even the name of the language is not stable! A few weeks back I went to install Zombie, and now I have to install ioj…

Your latter paragraph seems a bit fuddy as people 'just dipping in and out' would never have to have contended with the iojs 'name' any more than Python/Ruby/PHP people have to switch to a different VM every time one is announced (e.g. PyPy/Rubinius/Hack). I'd agree with your first paragraph in that Node is a bit lower-level out of the box and probably takes more effort to get started building a web-app, but I think…

> Your latter paragraph seems a bit fuddy as people 'just dipping in and out' would never have to have contended with the iojs 'name' any more than Python/Ruby/PHP people have to switch to a different VM every time one is announced (e.g. PyPy/Rubinius/Hack).

One of my main use cases for Node is Zombie, and that required io.js after v3. No mainstream PHP, Ruby or Python application has required a different interpreter.

Re: Node v4.0.0

#113
post #51

This is crazy fast shipment..almost scary that you have to start keeping up with all the changes.. For anyone who wants to upgrade either from node 0.12 or iojs 3.30..all you have to do is re-install it with the GUI installer and you're good to go..for your personal computer at least!

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

Re: Node v4.0.0

#114
post #17
post #5

The io.js fork and subsequent merge back into Node.js, including the birth of the Node Foundation, has been one of the best examples of the power of open source I have ever seen in action. The situation went from bad, to worse, to the best possible outcome, and that's remarkable to say the least. Congratulations to everyone involved and thank you for the hard work.

As somebody who uses Node only at the periphery of my role (for things like the Zombie browser, and SASS parsing) the massive instability has put me off from relying on it for anything core. Documentation is quickly out of date, libraries seem to have incompatibilities which only become obvious when they don't work, there's no 'recommended' approach for even basic tasks. I won't pretend I'm speaking for everyone, as…

I am a bit curious about what "massive instability" you have in mind?

Re: Node v4.0.0

#115
post #100
post #66

Earlier quoted context omitted.

Anything. I'm a pragmatic developer who just wants solutions that help me pay the bills. It's precisely for that reason that Node has been a problem for me - it's caused much more than its fair share of headaches, when compared to Ruby, Python, PHP, Bash, Go. Perhaps using a framework would make things easier, but I'm reticent to rely on it in the main part of the project when it causes so many problems just in the s…

Software development is not about chasing the latest shiny fad or trend on the market, it's about solving real-world problems by researching available solutions. So, if you think that Node doesn't fit or not equipped enough to solve your problems, you're welcome to check other solutions till you find the one most suitable to the problem at hand. So, if you think that Ruby or Python could get things done for you and y…

It's not absurd to say "I'd like to use Node because of its performance and because it's easier to hire for, but only if it were more stable and had better documentation". As somebody who has to consider trade-offs between short-term and long-term costs for clients, these are very real problems for me.

Re: Node v4.0.0

#117

Earlier quoted context omitted.

Your latter paragraph seems a bit fuddy as people 'just dipping in and out' would never have to have contended with the iojs 'name' any more than Python/Ruby/PHP people have to switch to a different VM every time one is announced (e.g. PyPy/Rubinius/Hack). I'd agree with your first paragraph in that Node is a bit lower-level out of the box and probably takes more effort to get started building a web-app, but I think…

> Your latter paragraph seems a bit fuddy as people 'just dipping in and out' would never have to have contended with the iojs 'name' any more than Python/Ruby/PHP people have to switch to a different VM every time one is announced (e.g. PyPy/Rubinius/Hack). One of my main use cases for Node is Zombie, and that required io.js after v3. No mainstream PHP, Ruby or Python application has required a different interpreter…

Sounds to me like your issue is with the author of Zombie.

Re: Node v4.0.0

#118
post #97

> ARMv6 32-bit Binary: Coming soon Is there more information on what's holding back this build?

The fact that the little Raspberry Pi building it is still...well, building it! :) https://ci.nodejs.org/job/iojs+release/168/nodes=pi1-raspbia... It does look like it's very nearly done though, given that it's tar'ing stuff up at the moment. The decision was made not to wait for it here - https://github.com/nodejs/node/issues/2522

just finished building :)

Re: Node v4.0.0

#119
post #53

Earlier quoted context omitted.

it's difficult to use it for anything serious without investing a lot of time into it. Isn't that true for many platforms? Either way, I have multiple apps running Node in production, and I've never had the issues described. You don't have to be as breakneck as Node itself - some things I have are still running v0.10x just fine.

I use Java/Spring, Ruby, and Node.js in production, and Node.js is by far the hardest to stay up to date with without introducing major problems. The only framework I have used that is harder to update is Finagle. It's not just Node itself to blame. There seems to be a culture of breaking things in the Node.js ecosystem. Breaking changes in third-party libraries are common. I have to specify exact dependency versions…

have to specify exact dependency versions in my package.json, and almost every time I update one of them, something goes wrong.

That's where semantic versioning comes in. Most libraries follow it - if the major version number changes, it's a breaking change. If it doesn't, you're safe to upgrade.

Re: Node v4.0.0

#120

Earlier quoted context omitted.

Can you give an actual example of the 'so many problems' you describe? Your previous comments address the paradox-of-choice idea, but the uncontroversial path in Node is to 'just use Express' right? How it that a worse situation than in other languages where there are also trendy frameworks competing against the default option. You name PHP as a better situation but from what I gather PHP is even worse at casting off…

Sure. There was the decision a couple of years back to stop using self signed certificates. I spent a couple of hours wondering why a server I was running that compiled SASS on deployment suddenly stopped working, and it turned out to have been this. A more recent example comes from Zombie, which I use for functional testing. When they moved to v3, they required io.js instead of Node. So eventually I decided to go wi…

I don't have a dog in this fight but the certificate thing sounds a lot like they corrected a significant security issue rather than API instability.
Post reply on HN