Fully agree, Ubuntu dropping Unity for GNOME made me an happy XFCE user.

I still tried to use it for a couple of months, but the performance difference is quite noticeable.

I don't think the JS interface is the main performance bottleneck, honestly. I would start to look at Clutter and modernizing the GPU backend (e.g. using UBOs, using the depth buffer, batching texture binds, etc.) before thinking about killing the JS interpreter.

It may be or may not be anymore, but at one time not long ago it definitely was. When I cared enough to actually profile its performance, you could literally just move the mouse to the top corner to expose the dashboard, and back. Each time doing this, 4MB of memory gone for good. That particular bug has been fixed. JS engine memory leak. In fact, I invite anyone to look at the number of 'memory leak' commits in Gnome 3/Gnome Shell regarding its JS use.

Might be, but it is does really lag behind what Unity was capable of, regarding performance.

With Gtk 4 being based on a GPU accelerated scene graph thing, isn't it time to deprecate Clutter?

This is a complex question. Using GTK+ in a window manager / compositor is tricky because GTK+ itself wants to talk to the window manager / compositor. So it's easy to end up in a deadlock. A DRM/libinput backend would have to be made for GDK and that's not an easy task, there are a lot of conceptual mismatches. I'm torn on whether it's the right way to go, basically.

Wait what? There are hundreds of popular gnome extensions.

With various degrees of CPU hogging.

which programming language has a similar popularity and would exhibit less CPU hogging?

If you want specific examples, C and C++ to start with, as the old GNOME plugins used to be written on, before they went JavaScript crazy with the UI.

And doesn't need to be C or C++, anything else that compiles to native code AOT would do as well.

Neither C or C++ have the same developer reach or safety.

Developer reach in what sense?

Script kiddies writting GNOME extensiosn with 100% CPU use and memory leaks?

As for safety, yes C++ and specially C are quite good at memory corruption bugs. Which I am quite aware, if you look at my comments history.

Exactly because of that I took care to expressly mention "And doesn't need to be C or C++, anything else that compiles to native code AOT would do as well.".

And while JavaScript might be safe in terms of memory corruption issues, there are enough WAT opportunities in the language.

Disagree. "Dash to Panel", "Gnomesome" and "Topicons redux" extensions have got GNOME back to where I wanted it exactly. They're not extensions that add any appreciable CPU usage, because they're altering shell behaviour, rather than rendering stuff in a tight loop.

My favourite tiling WM is awesome, and the majority of the interesting functionality for that is scripted in Lua, which is fast but more of a niche language.

However, awesome doesn't support Wayland, and the awesome-clones for Wayland are all early-development and don't work very well for me.

GNOME supports wayland, has session management, styles things consistently, has sensible defaults, and thanks to the JS engine and the extensions repo, can do exactly what I want it to do.

(Except for those !£$"£$% gigantic title bars which GNOME apps like to stuff navigation things into so you can't really remove, wasting SO much screen estate....)

> (Except for those !£$"£$% gigantic title bars which GNOME apps like to stuff navigation things into so you can't really remove, wasting SO much screen estate....)

The point of the gigantic titlebars and widgets in GTK3 is to support touchscreens - you can "grab" the big titlebar on a touchscreen and move the window easily, which you wouldn't be able to do with traditional window decorations. Once you're constrained to a bigger titlebar, having widgets in there as well is just sensible. Windows 10 has chosen the alternative of just making the titlebar thicker without stuffing anything in there, which wastes more screen space! (I still think there should be a traditional, mouse-oriented layout for systems which don't support touch-- but guess what, that's quite hard. The default should be touch-friendly.)

How about a PR? /s

No, but really, saying things like "I hate the technical decisions made by your project, please change it" without really participating in the project is silly. It is like "why not Rust?" all over again.