Hacker News Reader

Comment by tbrock | Hacker News Reader

This is awesome, but before anyone uses this for something real keep in mind that the way this works is that Microsoft has created a shim on top of Chakra that exposes a V8 API.

If V8 changes its API drastically (which it frequently does) this little experiment is basically over. There is only so much work people can do to keep up with a moving target.

Barring NodeJS creating an abstract JS engine API that developers can create v8/chakra/spidermonkey adapters for I can't see this being a success.

That being said, I hope that Node and V8 coupling becomes less tight and the interface between the two does become abstract so that we can all benefit from a choice of engine that implements the requirements of NodeJS.

View on HN

The thing is, Node needs to keep up with those same APIs.

It needs to call them, not implement them. I am guessing the former is a lot simpler than the latter.

And it (and native modules) do this pretty well via nan (https://github.com/nodejs/nan).

Well said!

One of the issues that spawned io.js was the lack of keeping up with V8 changes. I was asking the same question of what happens when V8 does something MS don't follow? It'll be interesting to see in the future. Good thing this happened when Node has an open governance model, so we can follow developments in future.

I think the long-term solution is to drop V8. The V8 developers pretty much do not care about Node at all. Perhaps Chakra can come to some agreement to keep their APIs stable and if so they can become the new default engine.

Dont be silly.

There may at some point be an effort to build an 'abstract node api interface' and main maintain bindings to various engines...

...but there's no way v8 will be dropped at any point in the foreseeable future.

What would you replace it with?

This? no way. We're years away from that even being plausible.

I said long-term. V8 makes changes all the time that breaks Node, degrades performance in certain ways and essentially says "tough shit". Why wouldn't you look for an alternative?

Sure, but we're talking realllllly long term here.

Is there any real point in trying to write a roadmap for something more than 2 years (at least) in the future?

No one has any idea what will be going on at that point; there isn't even a roadmap for an engine independent node api; and even when one is made (never mind implemented...), it will certainly not include 'drop v8' as part of it.

So we're talking about some nebulous future in which something may or may not happen after another thing which may or may not happen at some point in the future.

It's pointless to speculate about such obscure possibilities.

V8 isn't going away any time soon.

The obvious choice would be mozilla's spider monkey.

What's Apple's Nitro (i.e. JavaScriptCore) like?

https://github.com/zpao/spidernode

> Dont be silly.

While not silly is existing at the whim of a single commercial vendor's browser decisions?

Quaint definition.

With Graal maybe. http://www.oracle.com/technetwork/oracle-labs/program-langua...

Node's and V8's APIs changed so frequently that someone created an abstraction layer called NaN ("Native Abstractions for Node.js") for people developing Node binary plugins.

https://github.com/nodejs/nan

... and this integration uses that as well, so that nan stuff still works.

Keep in mind that native modules coded against NAN1 do not work with NAN2. Not sure about forward compatibility of NAN.

Even NAN2 is breaking some things. Or at least deprecating. It's hard to keep up, and the docs and examples suck. I tried converting a node v0.10 module to using it and flailed horribly.

Edit: I don't mean to say the project sucks - docs sucking is just a general open source problem I can't really blame the authors for.

Reply on news.ycombinator.com