I do agree with you that it would be nice if more parts of the GNOME shell were written in (or used plugins written in) higher level languages. Such a move to higher level languages would allow hobbyist developers to get involved in the desktop shell itself, without needing to spend time learning C or any other new language- Javascript included. Hobbyist developers and other current “outsiders” can help bring a whole new level of innovation to the desktop interface if we simply lower the entry bar and open up new areas where they can get involved.

To rephrase your last statement, we don’t want to tell developers “Welcome to the GNOME Shell- you need to use Javascript even though there’s a 70% chance that you wont like it.” As you said, it easy to overestimate how attached people are to a given language, and that applies especially to existing developers. They can learn to deal with a variety of applets being written in different languages, but new developers- who may only know one language- can’t deal with being forced to learn a totally new language like Javascript.

“Anything goes” does imply out of process applets and/or shell plugins, and that’s both an advantage and a disadvantage. From my own experience with Universal Applets, I can list a few of the difficulties offhand, but I can also list the solutions.

On the flip side, out of process applets don’t just allow flexibility, but they also give us an easy alternative to running everything in one huge and shaky monolithic process. I know I don’t want my entire desktop shell freezing if one applet goes down, and out of process applets provides the easiest way of avoiding that.

If, as a solution to the above problem, you already intend to sandbox applets and/or run them in some form of a virtual machine then why not also add on support for other high level languages? Depending on the implementation details, a large amount of the necessary code will have already been written.

That said, specifically regarding HTML + CSS + JS applets (which is what “Dashboard-like widgets” implies), I can imagine small and specific parts of the desktop shell being plugged with webpage-like content, but wherever you need full power that’s not the solution. If we want to create clutter like interfaces, clutter is the way to go- not DOM.

I don’t entirely disagree with you. Having many language bindings for the GTK+ stack has been a traditional strength of GNOME over the years. But I think there’s an inherent difference between an application – where most of the code is doing whatever the application does – and coding part of the GNOME core desktop. For the application, you really care about what code you have already, what libraries are available, and so forth. But for part of the GNOME core desktop, having a big language standard library is a disadvantage rather than an advantage. And there really has not been a lot of progress getting things written in non-C into the GNOME core over years, for reasons political and technical.

Specifically for applets and the more general concept of “shell plugins” – there are additional reasons to favor a standardization on a single language. First, an “anything goes” approach implies out-of-process. And out-of-process is inherently harder than in-process. Second, multiple languages really hurts forming a cohesive community where people are sharing code and copying what other people are doing. I think it’s very easy to overestimate how attached people are to a particular language. A programming language is a programming language, and even more so if we can offer something familiar like Javascript as the standard choice and provide skeletons and code to copy. One of the biggest barriers to entry is if we say “first, choose a programming language. Whatever you choose, 70% of the community will dislike your choice.”