By now it is probably no longer news to many: GNOME Shell moved from GJS’ own custom imports system to standard JavaScript modules (ESM).
Extensions that target older GNOME versions will not work in GNOME 45. Likewise, extensions that are adapted to work with GNOME 45 will not work in older versions.
You can still support more than one GNOME version, but you will have to upload different versions to extensions.gnome.org for pre- and post-45 support.
Please file bugs with your favorite extensions or have a friendly conversation with your extension writers so that we can help minimize the impact of this change. Ideally, you could help with the port and provide a pull or merge request to help maintainers.
It will be annoying for a minute but this change is good: it will help developers ship extensions faster and with fewer bugs by using standard JavaScript modules and IDE support. As mentioned in the blog: modules were standardized in 2015! At what point does it become acceptable to drop non-standard features?
it will help developers
Until they break it.
ship extensions faster
Which they need to adress the regular breakages.
and with fewer bugs by using standard JavaScript modules and IDE support
If I wanted to suffer web technologies, I’d develop content targeting web browsers, not a DE. JavaScript does a lot of things, being conducive to bug free code is not one of them.
I really admire the pain tolerance and endurance of devs developing and maintaining extensions for gnome. At what point does it become acceptable for them to drop that garbage DE? Rhetoric question: always has been.
You know Plasma makes use of JS too right?
You know that that is only an option and not a forced replacement for the “proper” API, right? Nobody is stopping you/me from writing plasmoid logic in C++.
I am a daily Gnome user. There are many things which I actually dislike about Gnome, but I have solved them all through extensions. Fine, I’m not bothered because it can be customized.
But every time they introduce something like this, it takes me a while to get a functional desktop back. It takes time for those extensions’ developers to respond to these things. They have to research the change, implement it, test it, go through extra work to stay backward compatible, etc. These people aren’t being paid for this, so it takes some time.
I’m just frustrated about this. I know someday I will run updates and suddenly find all my extensions broken.
The ideas behind the GNOME Shell desktop metaphor have stayed consistent through the 3.x cycle, at least from ~3.10. The “problem” with GNOME 3.x is that it implements core ideas in the workflow that the user needs to grasp. Either you use it as they thought you should or you are better off with some other DE.
Sure, you may need some extension to feel more comfortable. I do use a couple, but if you need extensions to make it functional you really should consider switching to another DE/WM.
I really, really hope Cosmic turns out to be a good DE, because Gnome does a lot of cool stuff that I really like, but the actual experience of using it is miserable for me. It always feels like it’s fighting against everything I want to do.
I’m glad Gnome exists, but we need an option that does some of the cool and unique things they do while also being less opinionated.
One of the reasons I prefer KDE or MATE. Too many extensions needed to make it usable. I also don’t like the fact that they’re installed through their website instead of your local package manager.
I am all for hating in GNOME for constantly breaking things. In this case though, are they not moving away from their non-standard system to the JavaScript standard? That seems like something to be supported and, in the long run, it will likely lead to less breakage.
Or am I misunderstanding?
Yes but it would have been nicer to have a transition period in which both methods are supported for a little while so that you don’t literally break every extension in existence up to this release
I find it naive to think GNOME would suddenly start caring about compatibility as moving to a standard doesn’t guarantee such.
I have a question: wtf is javascript doing in a modern desktop?
Um, you’re like more than a decade too late to ask this question. Javascript is pretty much everywhere now, whether you like it or not.
For the record, I dislike it as well - not the language itself mind you, but the fact that they’re using it to make bloated desktop apps and desktop UX. Long gone are the days when devs cared about performance, sometimes going as far as writing code in ASM to get the most out of paltry hardware.
Nowadays, even a $25 computer like the Raspberry Pi has enough computing resources to run bloated JS apps, so no one really cares any more, except for old fogies like us who grew up using entire operating systems that fit on a single floppy disk.
It’s probably the best scripting language, especially for developers of C-style languages. Python has weird syntax and is slow, Lua is really fast but also has weird syntax. JavaScript looks pretty much like C syntax wise. It’s also possible to use a wide range of existing JavaScript projects to make extension development less burdensome
The JS bindings to GTK4 (GJS) are complete, AFAIK; & allow for facilities like
Gtk.Expressionwhich the Python bindings still don’t have — & they’ve made rapid progress in a short time. The online documentation that’s available is also getting really good.Though I’m not sure why extensions have to be in JS, since JS is acting as a ‘glue language’ to the GObject bindings anyway. Isn’t an extension just a GTK application that talks to specific DBus interfaces?
I suspect that the issue boils down to not-so-well-fleshed-out (to put it politely) dbus interfaces on GTK apps. Probably GJS has an easier time setting/sending messages & signals over DBus, so that’s why extensions are in JS.
Many languages have well functioning bindings to GObject, Gdk, etc.; some are more complete than others (lua’s (lgi) are trailing behind – but still, you can do things like subscribe to a dbus_proxy in an embedded lua that lives inside vim or neovim, and send-receive messages with that) & some even come with good documentation, tutorials, etc.
