from the article:

> Canonical's write-up of the work done to improve GNOME is also interesting for the long list of what didn't work and how wrong some of the developers' initial assumptions were—especially regarding GNOME's use of JavaScript. > It turns out JavaScript had next to no effect on performance. So sorry JavaScript haters, but "assuming that JavaScript is slower than everything else written in C" is evidently a bad assumption

In 2011 gnome 3 was released with a memory leak due to a mismatch between compiled code and Javascript which saw memory allocated during animations that would be freed in no reasonable time frame. Eventually all memory in the system belongs to gnome shell.

As this is really hard to fix they fixed this by constantly running the gc in December 2018. This worked OK but didn't fix the issue for all until 2019.

Does making it broken for 8 years so usability comes 8 years late count as making it slow.

It should be noted that 3.34 has also seen some work on moving stuff from JS to C. Notably animations are now far less dependent on the JS part, with better performance as a result.

> But if you try i3 or OoenBox, they are way faster

But those are just window managers no? You can run them alongside KDE or Gnome.

Gnome 3 doesn't let you configure an alternative wm. KDE does but it's broken by default with minimal wm. For example it wants to start a full screen window that would normally be the desktop interface over everything.

It's questionable how much value is added by running a plasma session over simply running KDE apps and services.

Eventually, you won't really have a choice about whether to run a desktop session once Wayland is here. I don't expect my favorite window mamager to be updated with Wayland support.

Which window manager is that? For i3, the Wayland equivalent (or at least 99% equivalent) is Sway (which I'm using right now over here). For Awesome, there's way-cooler.

WindowMaker

Be aware that QTs QML makes use of a Javascript variant too.