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

191–200 of 277 posts

Re: Node v4.0.0

#191

Post by drumdance »

notNow wrote: post #100
blowski wrote: post #66

Earlier quoted context omitted.

Anything. 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 s…

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…

Preach. I inherited a Node project for which Rails was a much better solution for our use case. It's been fun learning a new platform, but for our needs Rails would have been fine. The only conceivable reason I can see they chose Node is because it's cool.

Re: Node v4.0.0

#192

Post by [deleted] »

grandalf wrote: post #102
blowski wrote: post #28

Earlier quoted context omitted.

It promises a stable future, so let's say I'm being cautiously optimistic.

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

[deleted]

Re: Node v4.0.0

#193

Post by jtblin »

blowski wrote: post #17
dcwca wrote: post #5

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…

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

Re: Node v4.0.0

#194

Post by WalterSear »

Touche wrote: post #180
hcon wrote: post #117

Earlier quoted context omitted.

Sounds to me like your issue is with the author of Zombie.

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.

Re: Node v4.0.0

#195

Post by WalterSear »

codecurve wrote: post #43
msoad wrote: post #32

When node supports `import` how you'll import node modules? I hope it works like this import {readFile} from 'fs'; import {clone} from 'lodash'; rather than explicitly providing "correct" URL to the modules. EDIT: edited the syntax.

You'll be able to achieve that behaviour when node also supports destructuring. import { readFile, writeFile } from 'fs'; import { clone } from 'lodash';

As I understand it, that still involves importing the whole file, rather than just the part you need. If that is an issue, lodash is parted out by method, so you can do this instead:

  import clone from 'lodash/lang/clone'

Re: Node v4.0.0

#196

Post by AdieuToLogic »

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.

> 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 which callback-based systems often produce, a person can familiarize themselves with the Win32 API (disclaimer: this is a masochistic exercise not recommended for anyone).

1 - https://www.cypherpunks.to/erights/history/actors/AIM-410.pd...

Re: Node v4.0.0

#197

Post by weddpros »

TheHydroImpulse wrote: post #67
weddpros wrote: post #57

Earlier quoted context omitted.

in fact, to my surprise, I've just tested our app (v0.10.x in production) on v4.0.0 and all our unit tests pass, the server works... I'm amazed. A single module had to be bumped (Elasticsearch@8) while we directly rely on 50+ third party modules... Our npm-shrinkwrap is 2600 lines long. That's not really a sign of instability to me, but rather great work

Most of the instability is related to compiled modules. Hopefully they'll be updated to support v4.0.0 shortly.

mongodb and redis are two compiled modules and we didn't have problems with those. Honestly, there may be others, I don't even know!

We try hard to keep our dependencies up to date to limit the risks of an upgrade. We progressively apply dependencies updates to dev->staging->sandbox->production environments.

Was I worried when node.js forked? sure! but the situation is much better now. I think node.js can move forward smoothly now.

Re: Node v4.0.0

#198

Post by DCoder »

dickeytk wrote: post #164
lucio wrote: post #142

Earlier quoted context omitted.

*incompatible

that's not what he meant

> where a new major version number indicates backwards-compatible changes

lucio was probably referring to this part, where "incompatible" is indeed correct.

Re: Node v4.0.0

#199

Post by AdieuToLogic »

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.

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

http://rubylearning.com/satishtalim/tutorial.html

Re: Node v4.0.0

#200

Post by weddpros »

blowski wrote: post #62
weddpros wrote: post #57

Earlier quoted context omitted.

in fact, to my surprise, I've just tested our app (v0.10.x in production) on v4.0.0 and all our unit tests pass, the server works... I'm amazed. A single module had to be bumped (Elasticsearch@8) while we directly rely on 50+ third party modules... Our npm-shrinkwrap is 2600 lines long. That's not really a sign of instability to me, but rather great work

You seemingly have much more experience with Node than me. Perhaps my amateur anecdotes are just bad luck, but certainly my Bash scripts that talk to Node break frequently.

I think the npm project should document best practices, like when to use "*" version, when to use npm-shrinkwrap, etc... to limit problems.

NPM is a very powerful tool. In fact, it's our deploy tool: we run `npm install` on servers (private Sinopia npm repository) to deploy. But to do that, you must follow many many rules that are written nowhere.

Post reply on HN