Comment by pjmlp
4 years ago
Mine is that they kind of abandoned Vala and then started using their own JavaScript engine for everything beyond bare bones Gtk+.
The slowness and leaks of not having a V8 class implementation, has made me embrace XFCE for the surviving device I still run GNU/Linux natively on.
And to think 22 years ago I was arguing for GNOME, advocating for Gtkmm versus Qt.
"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
1 reply →