There are often multiple installs of spidermonkey too (IIRC recently there was an effort in FreeBSD Ports to consolidate everything onto the latest couple versions)
The most (in)famous consumer of that is polkit :) but also GJS
The problem for JSC I suspect is how you manage gtk/qt/wx bridges without need either all three or alternatively creating dependency hell due to the bindings directly interacting with internal (eg totally unstable) interfaces and structs.
Eg you’d ideally have
* libjavascriptcore - the actual engine, runtim, and c-api, etc
* libjavascriptcore-qt (only the bindings, it would link the root jsc lib)
* libjavascriptcore-gtk (same)
* etc
The problem is that because they talk directly to internal interfaces they need to update in lockstep.
On Mac the only frameworks that do that are the core webkit frameworks. Nothing else on the system can talk to the internals (Mac and iOS have fairly comprehensive support for distinct internal/project/public APIs). But the system webkit, webcore, jsc, etc all have to update and build in lockstep.
In an ideal world all the alternate language bindings would be built on top of the stable C API, but alas (as I said before) the C API is fairly clunky and also out of date wrt to modern JS features. Also there are fun performance things a given binding can achieve if it doesn’t need to go through some layer of abi stability limitations.
It doesn’t, but the major webkit ports all have bridging APIs to make interfacing from a <gtk,qt,wx,corefoundation,cocoa> cleaner, and potentially lower cost.
I recall there being a desire to make it easier for bindings to be done entirely through the API, but as said elsewhere the API is somewhat clunky. Of course any level of abstraction adds costs - for example by being tied to the innards of JSC the various bridges are able to directly bludgeon the tag bits in JSString (the jsc raw string type) so there’s zero copying.
It also theoretically means you can do automatic object bridging (see the objc bindings).
So it’s not “JSC has to have UI bindings” as much as “JSC can be built with bridging APIs for major embedding frameworks”.
There is a trade off to be made, and long term I’m sure everyone in the JSC team at Apple would rather they could pull the bridges out of core build, but API design is very hard when you are having to think about long term support, coupled with continued support for the existing APIs.
JSC is even better in that regard - it’s API and ABI stable so you can just link to the[1] system install and use it [2].
[1] on Linux there are multiple (although technically it could be made to have a single lib for qt,gtk,wx...
[2] ok, actually using the C API is very very clunky :-/