Comment by the_why_of_y
4 years ago
"Their own JavaScript engine" is Mozilla SpiderMonkey 91.
https://gitlab.gnome.org/GNOME/gjs/blob/master/doc/Home.md
It appears to be broadly competitive with V8.
https://www.anandtech.com/show/16078/the-2020-browser-battle...
Maybe it is competitive now, it hasn't always been like that.
https://gitlab.gnome.org/GNOME/gjs/-/issues/231
https://gitlab.gnome.org/GNOME/gjs/-/issues/361
https://feaneron.com/2018/04/20/the-infamous-gnome-shell-mem...
Just to give you a taste of the issues.
When I complain about something, usually it is based on experience and knowledge.
And if I wanted to have a desktop where JavaScript gets used everywhere I would buy a Chromebook instead.
My reading is that performance problems are caused by interactions between reference-counted GObjects and tracing GC, nothing to do with "not having a V8 class implementation".
> https://gitlab.gnome.org/GNOME/gjs/-/issues/361
Now what can we learn here? Well, the most important lesson is that getting properties from GObjects seems to be very expensive and a major bottleneck [...] Also generally (and as expected), recursive processes like Clutters allocation machinery round tripping between C and JS land are a bad idea and should probably avoid JS land altogether
> https://feaneron.com/2018/04/20/the-infamous-gnome-shell-mem...
This fix is strictly specific to GObjects wrapped by GJS
From my point of view, the whole experience end to end counts as having a V8 class implementation, and not the bare bones runtime.
ChromeOS isn't only V8 without anything else.