21 ms·
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 re
by blowski 11y ago
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 clearly there are lots of people doing great things with Node. However, it doesn't seem to be a language like Ruby or Python where I would feel comfortable using it for a small but important project.
I'm always grateful to everyone who works on open source projects, but I wouldn't hold Node up as a great example of the open source community.
- dcwca 11y agoInstability 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-board/ https://nodejs.org/en/blog/announcements/foundation-elects-b...
- blowski 11y agoIt promises a stable future, so let's say I'm being cautiously optimistic.
- grandalf 11y ago> 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.
- deleted 11y ago[deleted]
- radu_floricica 11y ago"On the right track" does not mean "production ready now". Some time needs to pass in order to create the confidence necessary.
- grandalf 11y agoI lot of people (myself included) have been using IO.js in production for a while now.
- Killswitch 11y agoTell that to the big companies who use it in production right now. Microsoft, Netflix, PayPal, Walmart.
- hexchain 11y ago> One of the big goals of IO was to move to semver And of course they failed right from the start. From semver.org: Version 1.0.0 defines the public API. So their jumping to 4.0.0 from 0.x.x means they don't care to have a public API!
- kbutler 11y agoI'm not sure you're not trolling, but in case you have serious concerns, node.js 4.0.0 incorporates the history of io.js. io.js defined 1.0.0 in early 2015. See https://github.com/nodejs/node/blob/master/CHANGELOG.md https://github.com/nodejs/node/blob/master/CHANGELOG.md and search for 1.0.0
- untog 11y agoI mean, Ruby was created in 1995, Python in 1991. Node was first released in 2009. That's not an entirely fair comparison since, of course, JavaScript was created long before Node, but Node introduced the language to a new environment, and a lot of complications needed (and in some cases, still need) to be sorted out. As for no recommend approach - that's deliberate. I don't think most people working on Node want a Rails equivalent.
- blowski 11y agoI 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.
- untog 11y agoit'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.
- blowski 11y ago> 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 iojs and not Node. Assumedly it's now Node again. If you live and breathe the language, subscribe to the mailing lists, go to the meetups, etc, these things might be obvious. But when you're just dipping in and out, it really dents your confidence in the language.
- 11y ago
- simplyluke 11y agoThis 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.
- balls187 11y agoWhat mission critical software do you write? Does your code review process require multiple meetings that go over a single line of code in excruciating detail?
- hugozap 11y agoThe Node ecosystem is a great example of the open source community. The large number of libraries released on npm, active participation of the community and frequent events around the world related to Node proves it. Besides of course the large list of companies using it. Not sure about your problems with node and the 'massive instability'issues you've had, or if they are related to a third party library and not the Node core.
- blowski 11y agoI meant stability not in the sense of 'frequently crashing', in the sense of the API and 'how things work' remaining the same over time.
- notNow 11y agoIt's 0.x.x for a reason, don't you think? The leading 0 denotes probable instability in the API that devs are willing to take the risk for and act upon. You're familiar with SemVer, aren't you?
- iends 11y agoNode.js has never followed SemVer. That's why when io.js forked they adopted 1.0.0 and now Node.js went from 0.12.x to 4.0.0...
- collyw 11y agoAs a back end Python / Perl dev, everything in JavaScript seems this way to me.
- sanderjd 11y agoI 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.
- blowski 11y agoYou 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 by a nobody?". I don't like thinking that way about production code I'm writing for clients, so I use languages where I don't have to think that way.
- dcwca 11y agoWhen you say languages, do you really mean frameworks? It seems like languages are fairly general purpose and don't go out of their way to tell you how to build your application. Node is more in the "language" camp than the "framework" camp, and there are bunch of frameworks on top of it that give you the structure you're looking for.
- blowski 11y agoAnything. 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 small parts.
- nilliams 11y ago
- nandodrw 11y agoWhy instability, how many times your Node app shouted down in production? Your concept of instability is not related with software development.
- namuol 11y ago- Ruby: 20 years old - Python: 24 years old - Node: 6 years old Maybe your comparison is somewhat unfair...
- venomsnake 11y ago- language - language - io loop + vm
- namuol 11y ago- language + environment + ecosystem - language + environment + ecosystem - language + environment + ecosystem
- dasil003 11y agoIn that case "Node" is 20 years old, and "Ruby" (for web development) is 11 years old.
- namuol 11y agoWhat? It's fair to say Ruby didn't take off until 1.8 which came out in 2003, but how in any way is Node 20 years old?
- nnethercote 11y agoThe logic being used is that JavaScript is 20 years old.
- igl 11y agoI am a bit curious about what "massive instability" you have in mind?
- balls187 11y ago> 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. -- 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.
- blowski 11y agoI agree that it's possible to build successful Node apps, but of all the languages I use, it's the most difficult to keep up to date with and most likely to cause problems. If you're reading the mailing lists, going to meetups, etc, these things might not seem like huge issues. But if you're just trying to run a small Node project as one amongst many bits of software in many languages, Node causes a disproportionate number of problems. I've given a couple of examples below - Zombie switching to io.js, and the whole self-signed certificate debacle from a couple of years ago.
- deleted 11y ago[deleted]
- mattkrea 11y agoDo you have an example of the out of date documentation? The Node.js built-in modules have remained largely unchanged (as far as my use goes) since around 0.6.0 if not earlier. Streams underwent some big changes but most heavily used modules were updated relatively quickly. This went far more smoothly than the Python 3 transition IMHO.
- ap22213 11y agoGeez, that's a bit harsh, don't you think? I've used node on several high-volume production apps, and I haven't seen any instability. And, if the documentation is poor, then it's only poor forsomuch as one unwilling to delve into the code. Node has its place, and it's not for everything, but for quickly whipping together sturdy, flexible web APIs, it's great.
- _greim_ 11y ago> I've used node on several high-volume production apps, and I haven't seen any instability. Not sure if this is what you meant, but I read the ancestor comment not as being about "will the process crash randomly?" but "will an upgrade break something in my app?" It's just that I've seen whole comment threads go by with people tripping over this misunderstanding without ever acknowledging it.
- ap22213 11y agoMakes sense, on a rereading. npm coupled with drastically and frequently changing libraries (and transitive dependency clashes) does make a hell of a dependency mess; I agree. But, on the plus side, most node libraries are easy to modify. In fact, I have a private repository full of github forks that I've had to make over the years (and not had the time or patience to submit pull requests). Luckily, npm supports private repos easily.
- rhinoceraptor 11y agoI didn't know what bad documentation was until I used Ruby. I'll take Node's docs over Ruby's any day.
- AdieuToLogic 11y ago> 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.com/docs/ProgrammingRuby/ http://ruby-doc.org/ http://ruby-doc.org/ https://en.wikibooks.org/wiki/Ruby_Programming https://en.wikibooks.org/wiki/Ruby_Programming http://mislav.uniqpath.com/poignant-guide/book/chapter-1.html http://mislav.uniqpath.com/poignant-guide/book/chapter-1.htm... http://rubylearning.com/satishtalim/tutorial.html http://rubylearning.com/satishtalim/tutorial.html
- joesb 11y agoDocumentation in Ruby is bad not because of the amount of resource available. But because the community's love on language's meta-programming. Module are dynamically included. Methods are dynamically generated. The generation static document can only give a partial view of the running objects.
- spdionis 11y agoAnd btw that's one of the winning points of PHP. Let me find some great documentation for you: http://php.net http://php.net . That's it, one link is enough.
- pdpi 11y agoOut of curiosity, what about the Ruby documentation makes you say that? I personally rank Ruby's documentation (at least for the core language) as being pretty damn good (only a few I can think of are better), and node's core documentation is, in my opinion, a great example of how _not_ to write documentation. A personal favourite is how the first line of documentation for ClientRequest and IncomingMessage is about what creates them rather than in terms of what abstraction they represent[1]. Also, nothing in the documentation documents the types of things. In that regard, the Ruby docs are a bit weak (with the type documentation being a bit more informal than I'd like), but at least they put in the effort to document it. Also, I personally find the code samples in the Ruby docs to be much nicer than those in the Node docs (though YMMV). [1] - https://nodejs.org/api/http.html#http_http_incomingmessage https://nodejs.org/api/http.html#http_http_incomingmessage
- jtblin 11y agoThat really smells like FUD. Sass is Ruby for example not node. Ruby has been much more unstable than node AFAIK. And python hasn't even been able to move to version 3 so not sure it's the best example. I really like both python and Ruby BTW. Haters gotta hate...
- ryanthejuggler 11y agoAs a Node coder I used to avoid SASS since it was Ruby-based; now there's a fully-featured SASS parser in Node that keeps up with the specification. Bootstrap is moving from LESS to SASS, and they've always had their build step in Node.