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

211–220 of 277 posts

Re: Node v4.0.0

#211

Post by pdpi »

AdieuToLogic wrote: post #196
nocman wrote: post #130

Earlier quoted context omitted.

For the benefit of any who are not sure what you are talking about, could you please elaborate on what some of these "better ways to handle that" are? It would make your comment much more helpful, IMHO.

> For the benefit of any who are not sure what you are talking about, could you please elaborate on what some of these "better ways to handle that" are? While I am not certain what the GP specifically references, I can say that about 40 years ago the Actor model[1] was officially documented. The literature documenting benefits of an Actor model over a callback approach are easily found. For understanding the pain whi…

Even if you don't go the actor route, if you're going to use continuation passing style as much as Node wants you to, having a language with better CPS support would be much nicer

Re: Node v4.0.0

#212

Post by Gigablah »

blowski wrote: post #78
dcwca wrote: post #71

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'm not 'shitting all over Node'. I do use it for certain applications, and would love to use it more because it is a fantastic solution for some problems. As a back-end for websockets it's in a league of its own, and 'Isomorphic JavaScript' is very exciting if you ever need to hire developers. I am using this discussion as a means of saying "here's what I think Node needs to get more people using it in production".…

This is an announcement about the Node open source community finally overcoming their differences and making strides towards platform stability, yet your first response is to complain about "massive instability" (which turns out to be more about individual libraries than the platform itself) and how you "wouldn't hold Node up as a great example of the open source community". I can't see this as anything more than a slap in the face.

My opinion? You probably should withhold your judgement of the "open source community" if you only have superficial knowledge about their efforts.

Re: Node v4.0.0

#213

Post by joesb »

AdieuToLogic wrote: post #199
rhinoceraptor wrote: post #188

Earlier quoted context omitted.

I didn't know what bad documentation was until I used Ruby. I'll take Node's docs over Ruby's any day.

> 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.org/ https://en.wikibooks.org/wiki/Ruby_Programming http://mislav.uniqpath.com/poignant-guide/book/chapter-1.htm... htt…

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

Re: Node v4.0.0

#214

Post by pdpi »

rhinoceraptor wrote: post #188
blowski wrote: post #17

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…

I didn't know what bad documentation was until I used Ruby. I'll take Node's docs over Ruby's any day.

Out 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

Re: Node v4.0.0

#215

Post by pluma »

AdieuToLogic wrote: post #203
untog wrote: post #35

Earlier quoted context omitted.

I 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 R…

> ... 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... Actually, no, it didn't. JavaScript was first introduced "on the server side" about 20 years ago in the Netscape web server[1]. We learn from history that we learn nothing from history…

The JS of 2009 was an entirely different language from the JS Netscape originally created. Plus Netscape's web server was an evolutionary dead end and a proprietary closed-source product.

Node was in part influenced by CommonJS, which tried to unify the various competing but relatively obscure (mostly non-browser) JS environments. To say that it learned nothing from the history of SSJS (or JS environments in general) is, frankly, wrong.

That said, Netscape's SSJS is entirely unrelated to Node or anything like it[0]. Node lets you write application servers, Netscape's SSJS effectively was more like Rhino-meets-JSP or maybe GWT (i.e. the heavy lifting was apparently implemented in Java, not JS).

[0]: http://docs.oracle.com/cd/E19957-01/816-6411-10/jsserv.htm

Re: Node v4.0.0

#216

Post by pluma »

dcwca wrote: post #58
untog wrote: post #35

Earlier quoted context omitted.

I 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 R…

> As for no recommend approach - that's deliberate. I don't think most people working on Node want a Rails equivalent This is a useful way to understand what Node is. Node's core API is for building any sort of network service: A DNS server, an SMTP server, HTTP server, socket listener, etc. and so it applies to a wide and varied set of problems. Rails is for building a very specific type of database-backed web appli…

Exactly. I don't think Node is a good fit for monolithic CRUD apps. These are already solved problems in various other languages. Instead Node lets you compose small purpose-built modules.

Re: Node v4.0.0

#217

Post by coldtea »

nocman wrote: post #130
coldtea wrote: post #98

Earlier quoted context omitted.

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

For the benefit of any who are not sure what you are talking about, could you please elaborate on what some of these "better ways to handle that" are? It would make your comment much more helpful, IMHO.

Anything other: blocking in an Erlang like system, actors, CSP, real continuations, async/await, etc.

Re: Node v4.0.0

#218

Post by xg15 »

bsimpson wrote: post #135
ploxiln wrote: post #109

Earlier quoted context omitted.

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 sta…

The Node library is massive, and tightly coupled to V8. The changes that bumped the major version weren't major changes for most people, just for those who happened to be using the parts of the library that changed. Maybe that's a deficiency in semver (or the way io.js used it), but going to v4 in one year isn't as unstable as it sounds; it's just following Chrome's example of not caring how big the version number ge…

> ... but going to v4 in one year isn't as unstable as it sounds; it's just following Chrome's example of not caring how big the version number gets, so long as the semantics make sense.

Except that Chrome is mainly an application for end users and not a library, so the implications of "breaking changes" are a lot less severe anyway. In the parts where it does provide APIs (e.g. to websites or add-ons), the compatibility policies are a lot stricter than semver would require.

Re: Node v4.0.0

#220

Post by Ciantic »

tomphoolery wrote: post #153
mark_l_watson wrote: post #91

ES6 support is nice, especially if there is no performance hits for using ES6 features. I slightly prefer Typescript, but the extra language features in ES6 really make JavaScript development more fun for me. Thanks to the newly re-combined Node team!

Good news for you: ES2016 will support optional type annotations, clearly inspired by TypeScript. The idea is we shouldn't need a damn transpiler just to get the features most people want out of a language...

Interesting, can you give a link? I tried to find it, it's not here https://github.com/tc39/ecma262 Only mention is "Typed objects" but that is not TS-like annotation.
Post reply on HN