4 ms·

Does node.js have the same problem with the big API changes in v8?

by fotcorn 13y ago

kevingadd 13y ago
My instinct is that node probably doesn't interface as tightly with v8, or have as much of a surface area on those interfaces, as something like v8-juice. Given Stephan's claim that the new version of v8 is incompatible with all applications, though, I suspect some energy will be expended to make node compatible. Node at least has a huge pool of users and developers to draw from when tackling a change like this.
- baudehlo 13y ago
  The porting for Node was entirely done by one person. The bad news is it will also break all C++ extensions, which frankly I'm not looking forward to (both as a developer of said extensions, and a user).
- sgbeal 13y ago
  The claim that it breaks "all v8 applications" is based on the fact that the v8::InvocationCallback signature (which is used by all client applications who actually embed anything) is now different. It can't NOT be incompatible.
aegiso 13y ago
Yeah, we're feeling this in nodeland too. The core team has actually done a great job making sure that the core of node works with the new V8 API; this is already working in the unstable branch, without too much fuss. The much, much bigger issue is the native modules in npm. They all basically have to be ported by hand, and only a handful actually have been. So, transitioning to the next version of node will be an exercise in masochism for us makers. On the other hand, improving V8 with breaking changes is the V8 team's perogative and I trust they're doing it for the right reasons.
- shmageggy 13y ago
  I'm interested to see how Go progresses over time, as they consciously made the design decision to keep the language easily parseable so that API breaking changes can be accounted for programatically rather that requiring manual porting. See gofix -- http://blog.golang.org/introducing-gofix http://blog.golang.org/introducing-gofix In theory, this should allow them greater flexibilty to iterate and refine the language over time without the negative backlash that we're seeing here.
  - lttlrck 13y ago
    The API in question here is the C++ embedder API. It's altogether a different issue to Google changing some Go library APIs.
    - shmageggy 13y ago
      So are you saying there's nothing that the V8 devs could have done to ease the transition?
      - sgbeal 13y ago
        To their credit, they warned us some months ago (April?) on the list that the InvocationCallback signature and Persistent would change. That was a new step for them - the first time i was warned about breakage before it happened. But without concrete change details and a reference build to work against, one can't even prepare for the change until v8 has released something. A flood and backlog of client breakage was inevitable the moment they decided to make the change.

Does node.js have the same problem with the big API changes in v8?

by fotcorn 13y ago

Does node.js have the same problem with the big API changes in v8?

My instinct is that node probably doesn't interface as tightly with v8, or have as much of a surface area on those interfaces, as something like v8-juice. Given Stephan's claim that the new version of v8 is incompatible with all applications, though, I suspect some energy will be expended to make node compatible. Node at least has a huge pool of users and developers to draw from when tackling a change like this.

baudehlo 13y ago
The porting for Node was entirely done by one person. The bad news is it will also break all C++ extensions, which frankly I'm not looking forward to (both as a developer of said extensions, and a user).
sgbeal 13y ago
The claim that it breaks "all v8 applications" is based on the fact that the v8::InvocationCallback signature (which is used by all client applications who actually embed anything) is now different. It can't NOT be incompatible.

aegiso 13y ago

Yeah, we're feeling this in nodeland too. The core team has actually done a great job making sure that the core of node works with the new V8 API; this is already working in the unstable branch, without too much fuss. The much, much bigger issue is the native modules in npm. They all basically have to be ported by hand, and only a handful actually have been. So, transitioning to the next version of node will be an exercise in masochism for us makers. On the other hand, improving V8 with breaking changes is the V8 team's perogative and I trust they're doing it for the right reasons.

shmageggy 13y ago
I'm interested to see how Go progresses over time, as they consciously made the design decision to keep the language easily parseable so that API breaking changes can be accounted for programatically rather that requiring manual porting. See gofix -- http://blog.golang.org/introducing-gofix http://blog.golang.org/introducing-gofix In theory, this should allow them greater flexibilty to iterate and refine the language over time without the negative backlash that we're seeing here.
- lttlrck 13y ago
  The API in question here is the C++ embedder API. It's altogether a different issue to Google changing some Go library APIs.
  - shmageggy 13y ago
    So are you saying there's nothing that the V8 devs could have done to ease the transition?
    - sgbeal 13y ago
      To their credit, they warned us some months ago (April?) on the list that the InvocationCallback signature and Persistent would change. That was a new step for them - the first time i was warned about breakage before it happened. But without concrete change details and a reference build to work against, one can't even prepare for the change until v8 has released something. A flood and backlog of client breakage was inevitable the moment they decided to make the change.