Why would this matter at all? Using one GObject library doesn't then mean you can only use GObject libraries...

If you're using GI to access GObject libraries like Gtk+, you can still use any library your language supports for anything you want to do.

Give me a list of everything that a developer likes to do, and I'll try to answer this.

Ok, let me put it this way:

What do you estimate is bigger? The amount of plain C libraries or the amount of GObject based libraries? Where would you put the amount of available perl/python/ruby modules?

(The amount of C libraries not in GObject is my answer to your question ;) )

Your question confuses me. What exactly do you believe GObject does?

Out of my head and with no experience in it i'd think it's a library/framework to give plain C libraries more object oriented features, a type system and overall the base for most or all Gnome libraries. Probably comparable to Qt in that it probably has its own String implementation or container implementations. Much like Qt but procedural. Is that far off?

It does that, but that's not the important point. The fun part comes with the GIR files, that abstractly describe the classes, functions, members, constants and what have you in XML. Which means your language bindings are inflated from that description. That minimizes the effort to build and manage bindings for libraries developed on top of GObject.

Well, i don't question that flexibility, i have high regards of Gnome and run it for years now. I am not developer of Gnome, so i actually couldn't care less, apart from concerns of how the development of gnome turns out in a few years. Will JS in Gnome take off? Will there be more or less new developers?

What i question is the quality of documentation and the amount of 3rd party libraries (partly based on what i have seen from vala and in comparison to the whole C/C++ ecosystem and the amount and quality of 3rd party libraries for python, which i surely know more of then of GJS and GObject). No doubt it will be a massive amount of work to sort of replicate the efforts already put into the existing projects. Does the Gnome development have those resources? It will have to rely on other developers to join and work on that, for sure. It's sort of a chicken/egg problem. Why would i choose to write my Gnome app in Javascript when i have many well tested and well documented alternatives?

In the end, most interesting would be the point of view and experience of a vala contributor or even a Mono developer.

I don't doubt that glib, gobject and everything starting with G is nice ;)

But, again, how does it compare to the superset that is the C eco system or to a "direct competitor" that is python/ruby/perl/mono/whatever, _especially_ when it comes to desktop apps. Just take a look at how much is written for the Linux desktop in perl/python/mono/ruby and how good it actually works.

What is wrong with C/C++/python/ruby/mono/perl that it REALLY REALLY REALLY is beneficial to go down another road?

P.S.: Yes, i get that it is still (and will always be) possible to write apps in those languages. It's most important what the primary and recommended way is, though.

I can't really comment on that, I'm in the Perl 5 category myself :) My first assumption is they're trying to get some of the JavaScript crowd to do Gnome application development by connecting the communities. In this case, by actively working on the bindings.

The issue with Gnome has never been there libraries. They are lays consistently top notch. A lot of their UI is quite awesome as well. There issue is that there is a lack of consultation with their users when they make changes.

Basically, the developers meet at GUADEC, whatever, think of an idea that directly affects users, then implement it without any communication or consultation.