5 ms·

So the Node.js is dead now?

by CmonDev 12y ago

falcolas 12y ago
Doesn't seem like it, it's just the "RHEL" edition when compared to "Fedora" - slower, steadier release pace that focuses on stability, not features. EDIT: Downvotes ahoy. Let's be honest here. Stable code (especially stable threaded code) requires QA time after adding new features. There are commits in this release which are less than 5 days old. 5 days is not enough time to shake out bugs. Given that the developers are human, unit tests are incapable of finding all issues, and QA resources cost money, there is no way that this release could be considered to be stable. A company would deploy this at their own risk, knowing that it's likely to have bugs which will have to be reported and fixed. Not all companies can afford to take on that kind of risk, ergo a release like Node.js, which trails behind the bleeding edge of these technologies, makes sense to exist.
- oe 12y ago
  To be fair io.js also focuses on stability and communicating the stability through proper use of semantic versioning. It's not like io.js wouldn't be production ready.
  - mrcwinn 12y ago
    A versioning system does not ensure stability. Moving quickly in software generally means less stability over time, semantic versioning or not.
    - okal 12y ago
      > "Moving quickly in software generally means less stability over time..." Rather broad statement, that. Care to qualify it?
      - mrcwinn 12y ago
        I don't have a report to link to, but experience certainly says so. I'll make another broad statement: I don't think most experienced engineers would argue with me that the more quickly changes are made to software (which implies a large volume of changes as well) introduces less stability over time. Or certainly greater risk. I would also point out that the parent thread is good evidence. My point was that SemVer didn't save them from making a mistake, nor did the lack of SemVer save Underscore the other night. Volatility is what bit people.
        pekk 12y ago
        When old software has bugs that don't get fixed, that also poses risk (see many recent high-profile security flaws). People just tend to overlook these problems more. Simply waiting between commits reduces the rate of change, but does not increase the thoroughness of QA. In terms of defects, a project with very good, careful QA (any remotely acceptable strategy for reducing defects) will be at an advantage at every rate of change to a project which is just people pushing to master. Some forms of careful QA impose a lot of latency between the decision to change and the change actually hitting, but that doesn't necessarily imply a reduction in throughput of changes per unit time, and it isn't the time which is reducing the defects but what is being done with that time.
        tracker1 12y ago
        I think that depends on your workflow as much as anything else. There are ways to mitigate the risks of moving fast, unit testing, integration tests, sanity checks, rolling deployments, service layers (micro services), etc... By establishing the mindset that what you are pushing into master will make its way into production, you look at things very differently, with a much more critical eye. There are waterfall designed systems that took years to develop that made it to production with bugs... is a bug that breaks things for 5 minutes worse than one that sits for months, or a security fix that isn't deployed and might be exploited because your review process takes weeks?
- antouank 12y ago
  From what I understand, the "stability" argument, made by many for node.js, is a bit meaningless. Node.js uses an old V8 version ( Google doesn't support it anymore, and they don't even apply security patches to it ) while io.js has the latest V8, plus all the security patches and bug fixes from the io.js codebase, that node.js does not have. Same story with libuv, the "main" library under the hood. ( most of this explained in this podcast http://devchat.tv/js-jabber/147-jsj-io-js-with-isaac-schleuter-and-mikeal-rogers http://devchat.tv/js-jabber/147-jsj-io-js-with-isaac-schleut... ) If older === more stable, then I guess you should use the oldest version in everything. Makes no sense.
  - falcolas 12y ago
    Google offers support for v8 outside of Chrom(e|ium)? I can't find anywhere that Google lists what their supported versions of v8 are. Can you point me towards that list? More importantly, has Google shown genuine interest in supporting embedding v8? Their last blog post about this was in 2012. As for libuv, I would rather use a battle tested version, than stay on the bleeding edge. Threading is hard, and race conditions are rarely caught by tests. I'm happy to let others break their production and identify the regressions before I commit to it. Wanting to use proven software has no relation to using the "oldest" version. As software is used, bugs are found. The longer you wait to transition to using new features, the fewer bugs you will encounter when you make the transition. What's nonsensical about that?
    - coderzach 12y ago
      Even "proven" software gets bug and security fixes. The version of v8 they're using doesn't. Therefore, unsupported.
  - dap 12y ago
    The V8 question seems to come up a lot, but the V8 team only supports any branch for 6 weeks after it becomes stable for Chrome.[1] If this is your definition of supported, then if you plan to use any version of Node or io.js for more than 6 weeks, you'll wind up on an unsupported branch. [1] https://groups.google.com/d/msg/v8-users/UUyavs0KtwE/dhh4F8ciZwEJ https://groups.google.com/d/msg/v8-users/UUyavs0KtwE/dhh4F8c...
- ewegrump 12y ago
  Thinking that Node is somehow more "stable" means you've fallen for Joyent's marketing tendrils. When Joyent or other enterprisey Node users mean "stable" they mean it in the same sense as Windows XP is "stable". It means you have a bunch of dependencies designed to work with a specific version, and you don't want to do the work of migrating because you have bigger cheques to cash. Stable doesn't mean less features, less bugs, or a slower release pace. Those things just fall out as consequences. This is also the essence of why io.js happened in the first place. The intened audiences are completely different.
  - tracker1 12y ago
    That's probably true... with developers starting to favor things like docker and micro services, along with CI/CD flows all the way to production, it comes down to being very easy to create, test and deploy your services against new libraries, or even replace them with better performing versions as needed.
- tracker1 12y ago
  But shipping with dependencies so old that the upstream provider for that dependency is no longer backporting security updates is anything but stable.

So the Node.js is dead now?

by CmonDev 12y ago

So the Node.js is dead now?

Doesn't seem like it, it's just the "RHEL" edition when compared to "Fedora" - slower, steadier release pace that focuses on stability, not features. EDIT: Downvotes ahoy. Let's be honest here. Stable code (especially stable threaded code) requires QA time after adding new features. There are commits in this release which are less than 5 days old. 5 days is not enough time to shake out bugs. Given that the developers are human, unit tests are incapable of finding all issues, and QA resources cost money, there is no way that this release could be considered to be stable. A company would deploy this at their own risk, knowing that it's likely to have bugs which will have to be reported and fixed. Not all companies can afford to take on that kind of risk, ergo a release like Node.js, which trails behind the bleeding edge of these technologies, makes sense to exist.

oe 12y ago
To be fair io.js also focuses on stability and communicating the stability through proper use of semantic versioning. It's not like io.js wouldn't be production ready.
- mrcwinn 12y ago
  A versioning system does not ensure stability. Moving quickly in software generally means less stability over time, semantic versioning or not.
  - okal 12y ago
    > "Moving quickly in software generally means less stability over time..." Rather broad statement, that. Care to qualify it?
    - mrcwinn 12y ago
      I don't have a report to link to, but experience certainly says so. I'll make another broad statement: I don't think most experienced engineers would argue with me that the more quickly changes are made to software (which implies a large volume of changes as well) introduces less stability over time. Or certainly greater risk. I would also point out that the parent thread is good evidence. My point was that SemVer didn't save them from making a mistake, nor did the lack of SemVer save Underscore the other night. Volatility is what bit people.
      - pekk 12y ago
        When old software has bugs that don't get fixed, that also poses risk (see many recent high-profile security flaws). People just tend to overlook these problems more. Simply waiting between commits reduces the rate of change, but does not increase the thoroughness of QA. In terms of defects, a project with very good, careful QA (any remotely acceptable strategy for reducing defects) will be at an advantage at every rate of change to a project which is just people pushing to master. Some forms of careful QA impose a lot of latency between the decision to change and the change actually hitting, but that doesn't necessarily imply a reduction in throughput of changes per unit time, and it isn't the time which is reducing the defects but what is being done with that time.
      - tracker1 12y ago
        I think that depends on your workflow as much as anything else. There are ways to mitigate the risks of moving fast, unit testing, integration tests, sanity checks, rolling deployments, service layers (micro services), etc... By establishing the mindset that what you are pushing into master will make its way into production, you look at things very differently, with a much more critical eye. There are waterfall designed systems that took years to develop that made it to production with bugs... is a bug that breaks things for 5 minutes worse than one that sits for months, or a security fix that isn't deployed and might be exploited because your review process takes weeks?
antouank 12y ago
From what I understand, the "stability" argument, made by many for node.js, is a bit meaningless. Node.js uses an old V8 version ( Google doesn't support it anymore, and they don't even apply security patches to it ) while io.js has the latest V8, plus all the security patches and bug fixes from the io.js codebase, that node.js does not have. Same story with libuv, the "main" library under the hood. ( most of this explained in this podcast http://devchat.tv/js-jabber/147-jsj-io-js-with-isaac-schleuter-and-mikeal-rogers http://devchat.tv/js-jabber/147-jsj-io-js-with-isaac-schleut... ) If older === more stable, then I guess you should use the oldest version in everything. Makes no sense.
- falcolas 12y ago
  Google offers support for v8 outside of Chrom(e|ium)? I can't find anywhere that Google lists what their supported versions of v8 are. Can you point me towards that list? More importantly, has Google shown genuine interest in supporting embedding v8? Their last blog post about this was in 2012. As for libuv, I would rather use a battle tested version, than stay on the bleeding edge. Threading is hard, and race conditions are rarely caught by tests. I'm happy to let others break their production and identify the regressions before I commit to it. Wanting to use proven software has no relation to using the "oldest" version. As software is used, bugs are found. The longer you wait to transition to using new features, the fewer bugs you will encounter when you make the transition. What's nonsensical about that?
  - coderzach 12y ago
    Even "proven" software gets bug and security fixes. The version of v8 they're using doesn't. Therefore, unsupported.
- dap 12y ago
  The V8 question seems to come up a lot, but the V8 team only supports any branch for 6 weeks after it becomes stable for Chrome.[1] If this is your definition of supported, then if you plan to use any version of Node or io.js for more than 6 weeks, you'll wind up on an unsupported branch. [1] https://groups.google.com/d/msg/v8-users/UUyavs0KtwE/dhh4F8ciZwEJ https://groups.google.com/d/msg/v8-users/UUyavs0KtwE/dhh4F8c...
ewegrump 12y ago
Thinking that Node is somehow more "stable" means you've fallen for Joyent's marketing tendrils. When Joyent or other enterprisey Node users mean "stable" they mean it in the same sense as Windows XP is "stable". It means you have a bunch of dependencies designed to work with a specific version, and you don't want to do the work of migrating because you have bigger cheques to cash. Stable doesn't mean less features, less bugs, or a slower release pace. Those things just fall out as consequences. This is also the essence of why io.js happened in the first place. The intened audiences are completely different.
- tracker1 12y ago
  That's probably true... with developers starting to favor things like docker and micro services, along with CI/CD flows all the way to production, it comes down to being very easy to create, test and deploy your services against new libraries, or even replace them with better performing versions as needed.
tracker1 12y ago
But shipping with dependencies so old that the upstream provider for that dependency is no longer backporting security updates is anything but stable.