Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Node v4.0.0

nodejs.org

Post reply on HN
Print view View original

101–110 of 277 posts

Re: Node v4.0.0

#101

Post by twblalock »

untog wrote: post #53
blowski wrote: post #41

Earlier quoted context omitted.

I believe that Node can and will become more stable. It feels like it has too much momentum not to. But until it does achieve stability, it's difficult to use it for anything serious without investing a lot of time into it. Perhaps Go is a better comparison than Ruby and Python.

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 in my package.json, and almost every time I update one of them, something goes wrong.

Re: Node v4.0.0

#102

Post by grandalf »

blowski wrote: post #28
dcwca wrote: post #22

Earlier quoted context omitted.

Instability is the very thing this merge and the foundation seek to address. Where there was once an uncertain future, there is now a Board of Directors and a Technical Steering Committee bound by a Open Governance Model. The future has never looked more stable for Node, just take a peek at the names of the companies sitting on the board: https://nodejs.org/en/blog/announcements/foundation-elects-b...

It promises a stable future, so let's say I'm being cautiously optimistic.

> It promises a stable future, so let's say I'm being cautiously optimistic.

This doesn't make sense in light of your initial comment. One of the big goals of IO was to move to semver and address unpredictability/instability that you describe.

If anything, the merging of Node and IO should give you confidence that project governance will be on the right track moving forward.

Also, when you consider the advancements in transpiled js, the js/node community is looking very wise compared with other language maintainers.

Re: Node v4.0.0

#104

Post by namuol »

blowski wrote: post #17
dcwca wrote: 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…

- Ruby: 20 years old

- Python: 24 years old

- Node: 6 years old

Maybe your comparison is somewhat unfair...

Re: Node v4.0.0

#105

Post by blowski »

nilliams wrote: post #95
blowski wrote: 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…

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 with Zombie 3 and moved to io.js, but then another library broke which required Node instead of io.js.

They're the two big ones that stand out, but there have been lots of other small annoyances.

Re: Node v4.0.0

#106

Post by netcraft »

The arm support is great too. Great work from everyone involved, io.js was short lived but will have a lasting impact for the better.

Re: Node v4.0.0

#107

Post by azernik »

pfooti wrote: post #99
atburrow wrote: post #6

This is great news. I'm especially excited about the new ECMA6 features (arrows, etc.)

Yeah, this is rad, as I imagine there's some overhead to running the transpiled babel ES6 code compared to running the native ES6 features. At least some things may be faster - I remember lexical block scoping (let and fat arrow) causing perf issues in traceur. Now I just need to be able to rely on these features being present in the browser so I can just write native ES6 everywhere and skip that build step entirely.

Not just performance overhead, but also the overhead of maintaining and configuring the extra bits of toolchain.

Re: Node v4.0.0

#108

Post by actualprogram »

pags wrote: post #93
Florin_Andrei wrote: post #24

Earlier quoted context omitted.

Just curious - what makes it "stable"? We've tried 0.12, then went back to 0.10 for stability reasons.

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

Re: Node v4.0.0

#109

Post by ploxiln »

bsimpson wrote: post #25
georgerobinson wrote: post #9

What happened with the version numbers? I could have sworn Node was on v0.10 just a couple of months back?

A group of contributors got tired of Node not using semver when the rest of the ecosystem does (among other gripes). They forked it and shipped io.js v1.0.0. In keeping with semver, they bumped the major version number on every breaking change. According to iojs.org, the most recent version is v3.3.0. Joyent and the io.js team reconciled and merged their codebases, maintaining everyone's versions. Since io.js had use…

No api stability promises before 1.0 is technically part of semver. It sounds like io.js should have stayed below 1.0 if they broke backwards compatibility three times in less than a year!

I always found the naming-and-proclaiming of semver in the javascript community silly. Old style C libs have been doing what semver describes for decades, and while the js community talks it up like crazy, the compatibility and stability is terrible (and as a result they find the need for private recursive sub-dependencies, and the resulting thousands of unique libs/copies is impossible to audit or patch).

Re: Node v4.0.0

#110

Post by nathankunicki »

atomi wrote: 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

Post reply on HN