3 ms·

I don't. A lot of code out in the wild already relies on v8, and won't work with Chkara. Node 5 is up-to-date with v8. Though, I would like to see Mozilla devsv

by frik 11y ago

I don't. A lot of code out in the wild already relies on v8, and won't work with Chkara. Node 5 is up-to-date with v8. Though, I would like to see Mozilla devsvwpuld revives the unofficial spidermonkey Node.js support (https://news.ycombinator.com/item?id=2469786 https://news.ycombinator.com/item?id=2469786 , https://github.com/zpao/spidernode https://github.com/zpao/spidernode ).

adrianlmm 11y ago
>and won't work with Chkara Is your lost.
- frik 11y ago
  I meant many npm modules ;) Not my code. So it would be your problem too.
  - deleted 11y ago
    [deleted]
  - adrianlmm 11y ago
    That's the interesting part, even with V8 updates NPM packages get brocken, I don't see the migration to Chakra as something different to migrating to a newer V8 engine witch also break a lo of stuff.
aravindet 11y ago
This is definitely a problem today, but NAN (https://github.com/nodejs/nan https://github.com/nodejs/nan) which is now the recommended way to build native modules, offers a way out. That project provides a stable API to insulate module developers from changes between v8 versions. Sometime down the line, a NAN-spidermonkey or NAN-chakra project might become feasible.
- lmeyerov 11y ago
  Sort of -- in practice, we found ourselves instead playing catchup to NAN (many changes across Node 10, 12, 4, etc.). It insulates from minor changes, and increasingly, part of that has been Node waiting longer and longer between v8 changes.
- ndesaulniers 11y ago
  > which is now the recommended way to build native modules, offers a way out On paper. In reality, HELL NO. I maintain node native addons, and the thing is, NAN is great, but they simply cannot foresee what will break next in v8. Once something breaks, they provide a node-version-independent feature-shim, but every time there's a new version of Node, I DREAD the work I'm going to have to do to maintain my add ons. It's simply less work to cross compile C++ to JS w/ Emscripten or write it in JS (or higher level language and compile to JS) in the first place.

by frik 11y ago

adrianlmm 11y ago

>and won't work with Chkara Is your lost.

frik 11y ago
I meant many npm modules ;) Not my code. So it would be your problem too.
- deleted 11y ago
  [deleted]
- adrianlmm 11y ago
  That's the interesting part, even with V8 updates NPM packages get brocken, I don't see the migration to Chakra as something different to migrating to a newer V8 engine witch also break a lo of stuff.

aravindet 11y ago

This is definitely a problem today, but NAN (https://github.com/nodejs/nan https://github.com/nodejs/nan) which is now the recommended way to build native modules, offers a way out. That project provides a stable API to insulate module developers from changes between v8 versions. Sometime down the line, a NAN-spidermonkey or NAN-chakra project might become feasible.

lmeyerov 11y ago
Sort of -- in practice, we found ourselves instead playing catchup to NAN (many changes across Node 10, 12, 4, etc.). It insulates from minor changes, and increasingly, part of that has been Node waiting longer and longer between v8 changes.
ndesaulniers 11y ago
> which is now the recommended way to build native modules, offers a way out On paper. In reality, HELL NO. I maintain node native addons, and the thing is, NAN is great, but they simply cannot foresee what will break next in v8. Once something breaks, they provide a node-version-independent feature-shim, but every time there's a new version of Node, I DREAD the work I'm going to have to do to maintain my add ons. It's simply less work to cross compile C++ to JS w/ Emscripten or write it in JS (or higher level language and compile to JS) in the first place.