4 ms·

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

by tbrock 11y ago

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.

nevi-me 11y ago
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.
- Touche 11y ago
  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.
  - shadowmint 11y ago
    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.
    - Touche 11y ago
      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?
      - shadowmint 11y ago
        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.
    - tbrock 11y ago
      The obvious choice would be mozilla's spider monkey.
      - TazeTSchnitzel 11y ago
        What's Apple's Nitro (i.e. JavaScriptCore) like?
      - sonnyp 11y ago
        https://github.com/zpao/spidernode https://github.com/zpao/spidernode
    - rodgerd 11y ago
      > Dont be silly. While not silly is existing at the whim of a single commercial vendor's browser decisions? Quaint definition.
    - sandGorgon 11y ago
      With Graal maybe. http://www.oracle.com/technetwork/oracle-labs/program-languages/overview/index.html http://www.oracle.com/technetwork/oracle-labs/program-langua...
cwyers 11y ago
The thing is, Node needs to keep up with those same APIs.
- smegel 11y ago
  It needs to call them, not implement them. I am guessing the former is a lot simpler than the latter.
- STRML 11y ago
  And it (and native modules) do this pretty well via nan (https://github.com/nodejs/nan https://github.com/nodejs/nan).
cpeterso 11y ago
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 https://github.com/nodejs/nan
- steveklabnik 11y ago
  ... and this integration uses that as well, so that nan stuff still works.
- morebetterer 11y ago
  Keep in mind that native modules coded against NAN1 do not work with NAN2. Not sure about forward compatibility of NAN.
  - baudehlo 11y ago
    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.

by tbrock 11y ago

nevi-me 11y ago

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.

Touche 11y ago
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.
- shadowmint 11y ago
  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.
  - Touche 11y ago
    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?
    - shadowmint 11y ago
      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.
  - tbrock 11y ago
    The obvious choice would be mozilla's spider monkey.
    - TazeTSchnitzel 11y ago
      What's Apple's Nitro (i.e. JavaScriptCore) like?
    - sonnyp 11y ago
      https://github.com/zpao/spidernode https://github.com/zpao/spidernode
  - rodgerd 11y ago
    > Dont be silly. While not silly is existing at the whim of a single commercial vendor's browser decisions? Quaint definition.
  - sandGorgon 11y ago
    With Graal maybe. http://www.oracle.com/technetwork/oracle-labs/program-languages/overview/index.html http://www.oracle.com/technetwork/oracle-labs/program-langua...

cwyers 11y ago

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

smegel 11y ago
It needs to call them, not implement them. I am guessing the former is a lot simpler than the latter.
STRML 11y ago
And it (and native modules) do this pretty well via nan (https://github.com/nodejs/nan https://github.com/nodejs/nan).

cpeterso 11y ago

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 https://github.com/nodejs/nan

steveklabnik 11y ago
... and this integration uses that as well, so that nan stuff still works.
morebetterer 11y ago
Keep in mind that native modules coded against NAN1 do not work with NAN2. Not sure about forward compatibility of NAN.
- baudehlo 11y ago
  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.