Hacker News new | ask | show | jobs
by thayne 1626 days ago
That non embeddability is probably also a major reason why there isn't a significant node competitor based on spidermonkey. I get wanting to focus on Firefox as a whole, and that making components more independent can add quite a bit of work. But at the same time, if it was easier to use gecko in other browsers, and spidermonkey as JS environment outside the browser, I wonder if that would increase usage of and interest in the underlying technology.
6 comments

Spidermonkey is quite embeddable by itself [1]. On Linux things like polkit, couchdb, mongodb use it. Still, the compilation process seems to download the whole firefox tarball and only compiles the JS related parts [2, 3].

[1] https://spidermonkey.dev

[2] https://archlinux.org/packages/extra/x86_64/js78/

[3] https://www.linuxfromscratch.org/blfs/view/svn/general/js78....

And the fact that polkit uses it is why debian and ubuntu use an ancient version of polkit. And fwiw, there is an effort to replace spidermonkey in polkit with something else, like duktape.

Also js78 uses the version of spidermoneky from Firefox 78. The current Firefox ESR is 91 (released in august), but I don't see any js91 package, and https://github.com/mozilla-spidermonkey/spidermonkey-embeddi... still says to use the 78 ESR. Note that ESR78 is end of life and no longer receives security updates.

And from what I understand, there is no attempt at backwards compatibility in the spidermonkey interface, so each upgrade requires a lot of changes to the embedding program.

Yes, it is possible to embed spidermonkey, but there are a lot of challenges.

We embedded spidermonkey as the JavaScript engine for the prime video application on games consoles and smart TVs when I was at Amazon (5 years ago+ not sure if they still use it). I've not embedded any other JS engines, but it wasn't too bad to embed.
Actually, I just realised what I said above was slightly inaccurate, we also built an application that embedded CEF, so I technically have embedded another js engine (that was 7+ years ago though, and my memory is spotty).

CEF was also relatively straightforward to use. Both times we were embedding them in C++ applications.

This was the biggest fumble of the Mozilla strategy in the last 20 years. Instead of focusing on the developer market, particularly after the appearance of WebKit, they bet (half) the farm on a quixotic quest to build a mobile OS from scratch. By attempting to gain a level of control that was always unlikely, they endangered their own survival.
I would have made that same mistake if I was making decisions for Mozilla at the time. It's such an elegant, logical and tempting ideal to turn the browser into the OS. Too bad it didn't work out.
Well, now we have PWAs. I'd be more than a bit bitter if I was a mozilla dev tasked with making those work on android/ios instead of on firefoxOs.
Good luck getting Apple to allow basic features like storage without weird limits, notifications, and the rest of the list. They killed Flash in favor of HTML5+JS and then decided for the walled garden.
KaiOS though has had success. If anything FxOS was ahead of its time and targeting a market too small.
Interestingly there was a (never finished) Node fork based off SpiderMonkey (https://github.com/mozilla/spidernode had to write a V8 shim on top of SpiderMonkey), and GNOME Shell and some GNOME apps are written on gjs which uses SpiderMonkey. I don't know if it's bad at embedding compared to V8, but it's definitely been done.
MongoDB embeds SpiderMonkey. Embeddability of SpiderMonkey is fine. It is Gecko that is the problem.
Interestingly, MongoDB switched from SpiderMonkey to V8 only to switch back a few releases later.

https://engineering.mongodb.com/post/code-generating-away-th...

I embedded it in https://digiguide.tv/products/windows.asp around 20 years ago.

Aside from thread-wrangling I thought it was trvial to embed.

> 32mb RAM and 8mb Disk Space.

I miss such numbers so much.