Live data from Hacker News

Node v4.0.0

nodejs.org

251–260 of 277 posts

Re: Node v4.0.0

#252
post #177
post #140

Earlier quoted context omitted.

Using abstractions like http://koajs.com/ and https://github.com/tj/co make Node code feel like every other language. var user; try { user = yield db.insertUser('foo') } catch(err) { if (err.code === '23505') { this.flash['error'] = 'Username taken'; this.redirect('/register'); return; } throw err; }

no because you can't write a library which apis are thunks. And your code needs to run in a generator, something you omitted. Fibers are a better alternative , no need for yield and generators everywhere.

Well, I was earnestly sharing run-of-the-mill Koa code since you made async abstractions sound elusive. Didn't realize you just had an agenda.

The thing is that people are actually using Koa/co to solve this problem. I've yet to see someone use fibers as their core webapp control flow abstraction.

Re: Node v4.0.0

#253
post #100

Earlier quoted context omitted.

Software development is not about chasing the latest shiny fad or trend on the market, it's about solving real-world problems by researching available solutions. So, if you think that Node doesn't fit or not equipped enough to solve your problems, you're welcome to check other solutions till you find the one most suitable to the problem at hand. So, if you think that Ruby or Python could get things done for you and y…

It's not absurd to say "I'd like to use Node because of its performance and because it's easier to hire for, but only if it were more stable and had better documentation". As somebody who has to consider trade-offs between short-term and long-term costs for clients, these are very real problems for me.

Node's documentation really is terrible. The fact that it doesn't show what arguments functions take, what types are expected, etc. is pretty sad in 2015. The documentation is barely better than your typical side-project readme.md file, at best you get 1 example of an api's usage (always the most basic use-case only, of course).

Re: Node v4.0.0

#254
post #252
post #177

Earlier quoted context omitted.

no because you can't write a library which apis are thunks. And your code needs to run in a generator, something you omitted. Fibers are a better alternative , no need for yield and generators everywhere.

Well, I was earnestly sharing run-of-the-mill Koa code since you made async abstractions sound elusive. Didn't realize you just had an agenda. The thing is that people are actually using Koa/co to solve this problem. I've yet to see someone use fibers as their core webapp control flow abstraction.

What agenda do I have ? I have none, I'm just saying using generators do not abstract async calls. The only way to do that is by using fibers. I'm not pushing for anything, i'm just saying that something like rails couldn't be written in nodejs , (and no sails , is nothing like rails in terms of complexity ).

Re: Node v4.0.0

#255

Earlier quoted context omitted.

"On the right track" does not mean "production ready now". Some time needs to pass in order to create the confidence necessary.

Tell that to the big companies who use it in production right now. Microsoft, Netflix, PayPal, Walmart.

I suspect he means one-man-set-and-forget-production.

Re: Node v4.0.0

#256
post #142
post #23

Earlier quoted context omitted.

Joyent were incompetent stewards of the node project, so it was forked into "iojs". The iojs project adopted the semantic versioning system, where a new major version number indicates backwards-compatible changes (which mainly happen when they update the version of V8). Eventually Joyent recognised they were on the losing side, and so they agreed to merge back together, under a new foundation which was set up with th…

*incompatible

Whoops! That's a bit of a glaring error, sorry about that.

Re: Node v4.0.0

#257
post #142
post #23

Earlier quoted context omitted.

Joyent were incompetent stewards of the node project, so it was forked into "iojs". The iojs project adopted the semantic versioning system, where a new major version number indicates backwards-compatible changes (which mainly happen when they update the version of V8). Eventually Joyent recognised they were on the losing side, and so they agreed to merge back together, under a new foundation which was set up with th…

*incompatible

[deleted]

Re: Node v4.0.0

#258
post #180

Earlier quoted context omitted.

Actually it's with jsdom, Zombie's major dependency which dropped Node support pretty soon after IOjs was released.

That sounds political, more than anything else.

It was. The maintainer of jsdom decided to no longer support node after 3.x and made the library throw a condescending exception if you tried to run it with node. The docs were also filled with childish "tm" symbols whenever node was mentioned.

I see things like this all the time and it really puts me off OSS.

Re: Node v4.0.0

#259
post #254
post #252

Earlier quoted context omitted.

Well, I was earnestly sharing run-of-the-mill Koa code since you made async abstractions sound elusive. Didn't realize you just had an agenda. The thing is that people are actually using Koa/co to solve this problem. I've yet to see someone use fibers as their core webapp control flow abstraction.

What agenda do I have ? I have none, I'm just saying using generators do not abstract async calls. The only way to do that is by using fibers. I'm not pushing for anything, i'm just saying that something like rails couldn't be written in nodejs , (and no sails , is nothing like rails in terms of complexity ).

It's your fiber agenda. My mother used it to try to make me eat my brussels sprouts and I thwarted that, too.

Re: Node v4.0.0

#260
post #35
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 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…

There is http://sailsjs.org/ for people who want a Rails equivalent.
Post reply on HN