SpiderMonkey JavaScript/WebAssembly Engine
spidermonkey.dev
spidermonkey.dev
https://twitter.com/SpiderMonkeyJS/status/138998511262073651...
https://twitter.com/FirefoxNightly/status/139020827204140236...
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.
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.
Also, I've heard that it is comparatively hard to work with compared to V8, what's your experience?
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.
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.
My growl moments come more often with SM over V8. :-D
But I got paid for it so it got done.
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
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.
Has this been considered?
This isn't a major change; we're just polishing up our outwards-facing information a bit.
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...