121–130 of 277 posts
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!
`nvm install v4.0.0` and you're ready to go.
Earlier quoted context omitted.
I think there are two separate things in your comment: the recent instability is due to the leadership power struggle that has been resolved, but the "no recommended approach" problem is more the result of a philosophy that encourages tiny pieces, new ideas, and reinvention, which is both a blessing and a curse, and seems unlikely to change.
You can have both. An 'officially recommended approach' does not preclude 1000 unofficial but working approaches. However, it does it make it a lot easier for someone dipping their toes in. With Node for core and basic problems, I find myself thinking "Should I follow this blog post written by a highly respected developer but which is a year old and therefore forever in Node-land, or this blog post written last week…
The flexible experimental approach inevitably conflicts with the constraint of back-compatibility (e.g. of x86, java).
Node seems more like the Drosophilia-like JS frameworks.
Earlier quoted context omitted.
No software is bug free, but AFAIK Node v4 was very thoroughly tested in a vast array of platforms and configurations, which provides certain degree of certainty, when talking about stability. At any rate, if you ran into issues with 0.12, the best you can do is give 4.0 a go and report issues!
If you're concerned with stability, the best thing you can do is wait for the LTS release to come off the 4 branch. A quick glance at outstanding issues will show a number of integration bugs are still outstanding, and the new v8 was landed only a few days previously - incompatibilities with new versions of v8 can take a while to surface in node. It's important to remember that semver makes no promises about stabilit…
A = Marketing number B = Breaking Change number C = Non-breaking change number D = bugfix number
Earlier quoted context omitted.
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.
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…
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.
--
Do you have examples? My counter to your anecdotal evidence is my own--we've successfully built and managed multiple projects in production, that service millions of customers, which were written in nodejs, and have been doing so since 2013. The issues with Io led to no discernible conflicts to our businesses.
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.
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.
The same episode happened with GCC and EGCS in the 90s. It's the power of free software.
Earlier quoted context omitted.
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…
This is why we won't use it for client work. I'd use it for a personal project, or hackathon, but I'd be really cautious of developing mission-critical software in it.
Earlier quoted context omitted.
I can't reply to the grand-child of this post, so here's my reply. It seems that you don't like Node and are intent not to use it. I respect that and am not trying to push it. I think asynchronous programming in the reactor pattern is a good solution pattern for many types of problems, and Node.js is a solid application of that pattern. But it certainly is more complicated than synchronous programming in the kinds of…
> I think asynchronous programming in the reactor pattern is a good solution pattern for many types of problems, and Node.js is a solid application of that pattern. Asynchronous programming a la Node (with callbacks etc) is an anti-pattern. We've had better ways to handle that for 4 decades now.
It would make your comment much more helpful, IMHO.