Is this project still active?

[papercuptech]

Has this project stalled (there seems little recent activity)?
Is there a realistic objective to enable spidermonkey as a production-quality option for node's vm?
Are there some kind of major roadblocks, and if so what are they?

[tbsaunde]

I'm working on updating to recent SpiderMonkey. After that I may look at updating Node. I still think the idea is interestingand want to spend some time getting it to work. I'm not exactly sure what the best long term direction is though. I think in my ideal world Node would use something like WebIDL to define the APIs Node core and native extensions expose to JS. Then ideally we could have C++ code in Node that didn't know about JS things and just delt with reasonably standard types and passed them off to a code gened marshalling layer that was specific to the JS engine in use, but that's a bit of work and I'm not sure how interested Node would be in it. that said I think it would be good for both performance (the JIT has a better idea what is going on and can optimize based on that), and simplicity of the hand written code. At least I think that's the experience Mozilla has had with DOM related things and I would expect would work here too. The rust neon bindings are some interesting steps in that direction, but I'd like to see work to tell the bindings what the expected argument / return types are so that the API implementation doesn't have to deal with raw JS values.

[tbsaunde]

Also I'm curious what your interest here is?

[mykmelez]

Has this project stalled (there seems little recent activity)?

The project has only mostly stalled, as I haven't made progress on it, and I haven't managed to interest other Mozillians in it, with the exception of @tbsaunde, who has been making some progress, as he described earlier.

I'm still interested in the project, although I remain uncertain about its potential, especially now that the V8 team has decided to treat Node.js as a first-class citizen, which reduces the value of alternative JS engines to the Node.js team.

Microsoft's work on "VM neutrality" in Node.js might make this more promising over time, although there's also a chicken-and-egg problem with that approach, since VM neutrality would itself be more promising if SpiderMonkey supported it.

Is there a realistic objective to enable spidermonkey as a production-quality option for node's vm?

No, there isn't a realistic objective to make SpiderMonkey a production-quality option for Node's VM. Our only objective at the moment, as reflected in this milestone, is to pass Node tests.

Are there some kind of major roadblocks, and if so what are they?

There's work to do on the SpiderMonkey integration, which @tbsaunde has been tackling. There's work to do to support more recent versions of Node, which is tracked in the merge-node pull request. And there's work to do to fix Node tests, which is tracked by the aforementioned milestone. None of these are major roadblocks, as far as I know. It's just a bunch of work.

[papercuptech]

@tbsaunde My interest correlates to how much faster and standards-implementing spidermonkey is to v8, and to facilitate competition in js on the backend, in a production capacity.

Just some thoughts:

It seems Node is working towards a VM agnostic type layer N-API to decouple VM's from binary add-ons, but this will likely be at the cost of even more work (cpu) for marshalling.

But I propose binary addons are a small portion of all that Node is, and that there's probably a fundamentally better way to deal with them to begin with.

Node is a command line launched executable that contains libuv, a standard js library, and a js vm, that can also interop with binary addons.

If addons didn't exist, there'd still be lots of things that node could be used for.

If spidernode is looking for purpose beyond just "passing node tests" and usable in production settings, maybe it can be "mostly" node, but with a better addon/platform-iterop story.

In other words it would run atop libuv, and contain the same js library, but would promote/leverage wasm as one part of it's 'addon' story, specifically all the O/S-agnostic use cases, and a built in FFI for O/S-specific interop (and also agnostic libs not yet compiled to wasm).

I think a wasm/FFI approach would be much easier for Node/V8 proper to also adopt, as well as MSFT/Chakra, and would in the long run likely be more efficient than N-API.

Again, just thoughts....

[Serkan-devel]

Are there maybe efforts to use node with the servo engine?

[mykmelez]

Are there maybe efforts to use node with the servo engine?

I'm not aware of any such efforts at the moment.