Q: Should I use ES6 or Lang classes when developing Gnome Shell and Extensions? I'm deving a simple gnome shell extension and in the HACKING.md of gnome shell repo, it says that we should use new Lang.Class() language framework to initializing a class.
But, when I check the official gnome-shell extensions repo examples, every extension uses the es6 class syntax other than new Lang.Class().
So, my question is: Should i use es6 class syntax for shell extensions and use the new Lang.Class() framework for contributing to gnome-shell itself? Also, where can i get the more information about what architecture the gnome-shell is and the complete api i could use? i search google and all info seems broken or outdated, which is very disappointed for naive guys like me.
Thank you.

A: https://gitlab.gnome.org/GNOME/gnome-shell/issues/530#note_308621
Below is the answer from gnome-shell developer:

So, my question is: Should i use es6 class syntax for shell extensions and use the new Lang.Class() framework for contributing to gnome-shell itself?

For now: yes.
Support for ES6 classes in gjs is still relatively new, which is why you still find a lot of uses of the Lang.Class framework that was used before. And in the case of gnome-shell, there's an additional complication in the form of extensions:
const Lang = imports.lang;

const Foo = new Lang.Class({
    Name: 'Foo'
});

// this works
class Bar extends Foo {}

class Baz {}

// this doesn't
var Quz = new Lang.Class({
    Name: 'Quz',
    Extends: Baz
});

The plan is certainly to port gnome-shell to use ES6 classes, but it will break all extensions that still use Lang.Class to inherit from a class defined in gnome-shell. So this isn't something we should sneak in gradually, but rather an explicit switch with enough leeway for extension developers to adapt their code if necessary (I hope to pick up a local branch early in the 3.32 cycle, so knock on wood).
So TL;DR:
New applications or extensions should definitively use ES 6 classes, and I would recommend to developers of existing ones that they seriously consider porting.
On more general terms: Using an issue tracker as a support forum is highly ineffective, because any answers tend to fade into obscurity when an issue is closed, so probably nobody except the original "reporter" benefits from them. That makes for quite a poor use of developer time (that is not spent on fixing actual issues).
