Hacker News new | past | comments | ask | show | jobs | submit login
SpiderMonkey JavaScript/WebAssembly Engine (spidermonkey.dev)
90 points by twapi 40 days ago | hide | past | favorite | 24 comments

The tarot-style images of the monkeys in the docs are amazing :) https://spidermonkey.dev/docs/

As one who has been incorporating SpiderMonkey as an engine for malicious JavaScript detection research efforts continually since Firefox 56, this is a big milestone.

No longer have to cut your teeth incognito in making a GUI-less customized Firefox jerry-rigged with numerous instrumentation points … repeatedly for each version.

This is it, researchers; have at it.

If SpiderMonkey works for you for this purpose, what's changed? It has been available (but officially unsupported) as a standalone embedding target for many many years. Though it hasn't necessarily been easy to figure out the state of things; we're hoping to do better with this new site. The examples repository https://github.com/mozilla-spidermonkey/spidermonkey-embeddi... makes it a lot more approachable.

Also, if you come find us on https://chat.mozilla.org/#/room/#spidermonkey:mozilla.org or https://discourse.mozilla.org/c/spidermonkey we're happy to help out with the kinds of projects you're talking about. We might even be able to assist with making at least some of the instrumentation points more stable.

LLVM’s treatment on C++ vtable has improved.

Out of curiosity, why did you chose Spidermonkey over V8?

Also, I've heard that it is comparatively hard to work with compared to V8, what's your experience?

(I work on SpiderMonkey.)

I'm also curious about the answer to this. From what I've heard, SM and V8 are both fairly painful to embed. This is all hearsay, but I think V8's API is a bit more stable, it's a little easier to play nicely with its GC though apparently it doesn't fit well with some setups, SM tries hard to handle out of memory conditions (crashing on OOM is a dealbreaker for some embedding scenarios), and the SM devs are said to be friendlier and more willing to help random people.

Related to the previous there's much less of a distinction between core SM devs and community -- there's a steady ramp from showing up on Matrix as a rando to becoming a trusted core member with equal permissions and respect, regardless of employment.

But that last is is from my personal experience as a long-time SpiderMonkey developer, and I've never personally attempted to embed V8 or hang out on their forums.

In practice, people tend to start with one or the other for a variety of reasons, some of them based more on happenstance than anything else. And it's hard enough to figure out how to get going that you'll tend to stick with what you're somewhat familiar with. Strong path-dependence.

> From what I've heard, SM and V8 are both fairly painful to embed

Not sure what's the state now, but years (9?) ago I created the scripting layer for a very popular 2D open source game engine at the time. Had to do it twice: once with JavaScriptCore and the second time with Spidermonkey. Turns out that Spidermonkey was really not that hard to embed and I also ended up creating some nifty auto-generated bindings from the C++ code (using llvm) to Spidermonkey. The runtime to keep track of spidermonkey <> C++ objects was very lean. Overall I had a really good experience and if I had to today, I would probably start looking at Spidermonkey again.

You are absolutely correct on all points, @sfink

My growl moments come more often with SM over V8. :-D

But I got paid for it so it got done.

Driven by customer demand. And I agreed (then, before Edge came out).

Also, Sourcetrail made it so much easier to navigate the entire Firefox code repository and take in the entire design quicker.

The “hard” … part is the build, long build. Even with 24-CPU, creating and working with instrumentation API points often necessitate a very long but complete rebuild. Long builds eat into what we developers are most comfortable with, a tight turnaround build time. But that is a feature of C++ (and offtopically, Ada as well) even with vtable support.

Reference: https://en.wikipedia.org/wiki/Sourcetrail

To both the_duke and sfink, as one who did both embeddings, there were multiple issues during multi-prong integration efforts:

Each has their own challenges based on various JavaScript bytecode detection algorithms (as well as disparate JS engine design) and its varied requirements on the multiplexing of selected external stimuli that it requires.

As a result, after placements of many instrumentation points were inserted throughout both browsers and many custom JS engines based on various detection researches, there are needs to have multiple but separate executables having one or more combination of the following:

- custom ES6 pre-loading,

- Rendered layout memory access

- DOM shadowing

- selectable UI external stimuli (event, drag)

- variable wall-clock timescale compression/expansion

- translated memory access

And that belies my next project, centralization and merger of all these many executables. Various desired functionalities got dropped in the code by Mozilla and Google devs so code reduction/refactoring were done over time for those.

That’s about as detailed as I can put forth.

I could see Mozilla adapting this to be a serverless engine - like that of Cloudflare workers and Deno (based on V8) - could charge for enterprise usage and adaptions.

Has this been considered?

Does CF workers use Deno? Or you’re just referencing those as two separate implementations of sandboxing?

No, CF workers does not use Deno. Workers uses a custom runtime built on V8.

Sorry to ask, Apart from the website, what is new here for SpiderMonkey?

The logo!

This isn't a major change; we're just polishing up our outwards-facing information a bit.

What is new here ... I think this has been around a while? I looked at the blog and the last entry was in May ... I must not be seeing it.

The notes on the TC39 meetings look really nice. Hopefully this will make it easier for people to get involved.

Can I compile the engine to wasm? Yes I want to run JS on wasm. Yes I have a reason.

Why not have a look at QuickJs. I assume your reason is to run js in the browser in an isolated environment for security reasons? I’ve found this article from figma to be an excellent starting point [0] Also useful to consider this benchmark [1] of js runtimes.

We’ve found quickjs-emscripten [2] to work really well thus far. You can see my implementation of it here [3] in Lowdefy. If still has a few rough edges, so would be really keen to make it better.

I’m interested to know, is spidermonkey more comparable to V8 than QuickJs?

[0] - https://www.figma.com/blog/how-we-built-the-figma-plugin-sys... [1] - https://bellard.org/quickjs/bench.html [2] - https://github.com/justjake/quickjs-emscripten [3] - https://github.com/lowdefy/lowdefy/blob/main/packages/operat...

I want to run it in DFINITY’s ICP.

New website?


Mozilla must be looking to get rid of the engine and throw it out to the community. Then they can fire more developers.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact