Live data from Hacker News

Node v4.0.0

nodejs.org

231–240 of 277 posts

Re: Node v4.0.0

#231
post #216
post #58

Earlier quoted context omitted.

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

Now out only problem is how to build decoupled/distributed micro services.

I'd argue only Erlang and Elixir are going to survive into the multi core multi server future, but that would be little more than a slightly educated opinion unless I take the time to write a very large explanation with cited references. I don't have time for that this week.

Re: Node v4.0.0

#232
post #62

Earlier quoted context omitted.

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.

Bash scripts talking to Node sounds like a recipe for disaster.

Please explain.

Re: Node v4.0.0

#233

Anyone know when Node will get IndexedDB?

I agree with you that it'd be nice, but I don't think there are any plans for it.

I wrote https://github.com/dumbmatter/fakeIndexedDB which does run in Node (albeit really slowly and only in memory). It wouldn't be that much work to make it run on a real DB backend (LevelDB like Chrome, SQLite like Firefox, etc), at which point it would be everything you want. PRs are welcome :)

Re: Node v4.0.0

#234
post #193
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…

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

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

Re: Node v4.0.0

#235
post #230
post #86

Earlier quoted context omitted.

Since it's the first and only release so far in 4.x.y, I got away with `nvm install 4`. ;)

Using `stable` is also another way. > nvm install stable v4.0.0 is already installed. Now using node v4.0.0 (npm v2.14.2)

nvm maintainer here: this is true - but please use `node`, since the concept of "stable" and "unstable" has died with the advent of node v4.0 using semver.

All node versions are now stable, and version numbers now communicate breakage, not stability. As it should be.

Re: Node v4.0.0

#236

Earlier quoted context omitted.

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

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

I lot of people (myself included) have been using IO.js in production for a while now.

Re: Node v4.0.0

#237
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';

Not really. The destructuring syntax used in the imports is not the same as the standard array and object destructuring.

Section 15.2.1.16 of the current stable ES6 specification specifies how the import syntax is resolved, and it doesn't use destructuring.

P.S. Sorry too lazy to get a clickable link from the spec :P see http://awal.js.org/especser/#15.2.1.16 if you really wanna read it

Re: Node v4.0.0

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

Actually, IIRC it's the exact same reason as the io.js split. The maintainer of jsdom had changes that weren't being merged into node's VM module.

So jsdom 3.x used a lib called "contextify". When io.js was released and the changes included, node support was dropped. Now node 4.0.0 is out and has those changes, jsdom now works on node again.

Re: Node v4.0.0

#239

Earlier quoted context omitted.

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

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

Re: Node v4.0.0

#240
post #216

Earlier quoted context omitted.

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.

Now out only problem is how to build decoupled/distributed micro services. I'd argue only Erlang and Elixir are going to survive into the multi core multi server future, but that would be little more than a slightly educated opinion unless I take the time to write a very large explanation with cited references. I don't have time for that this week.

We are an (almost) completely node.js team and are having quite a bit of success using it for microservices. gRPC makes communication fast and easy, while Docker and Kubernetes make deployment and composition just as simple.
Post reply on HN