First off, if anyone got offended by my previous email I deeply apologies, it wasn't my intention, and I feel like I owe you an explanation.
I like GJS, I really do, but I feel like everyone else in the JS panorama took a different direction when it comes to native UI development ( NativeScript, Ion, ReactNative, even Adobe Air ) which is what I meant when I've said it has no traction. It's hard to find online articles, posts, or "advocates" about GJS and the documentation is unfortunately not the best (if you remember, it took me a week only to manage to build it while links online point at Giovanni's page which is ... how many years ago?)
About being not JS friendly in the JS world, the entirety of the ECMAScript specification, version 3rd to version 2015 and current draft, has **not a single `python_case` property or method**
Not in _javascript_ and also not in the entirety of the DOM API.
Accordingly, only if you come from C, Ruby or Python (or PHP?) you can say you are comfortable writing `python_case` things in JS, because nothing else in native JS, but it's pretty rare even in all libraries or FWs APIs, is written as such.
GJS seems to come after PyGTK so I get why it was easier to have it like that, but be honest, if you love Python you also love its consistency. It would be "huge drama" if anyone in Python-land would go out with an API that uses `camelCase` where everything else uses underscores, isn't it?
So, having a `python_case` API in a language that is *consistently* specified as `camelCase` for methods and properties, and `PascalCase` for constructors, with `CONSTANT_CASE` info that thanks gosh is almost a universal agreement, doesn't fell, neither look, right.
I could stick a big *IMO* at the end but if anyone likes consistency in programming, writing `python_case` in a `pascalCase` PL is objectively a bad choice, I'm sorry but I also believe we can agree on this.
I write JS for living and it's been 16 years now, to me writing `_` between words *is* a big deal (some sort of "yak" moment and a "this is old" feeling) but it's not the end of the world as long as there is an option to write it more JS friendly (or call it closer to specs-like/native syntax).
The way GJS exposes constructors and their prototype though, blocks me to preemptively add `camelCase` overloads so I'm forced to wrap pretty much everything with Proxies, which is ugly and slow, but that's all I could think of in order to be able to give "copy-paste" ability from few online examples, and also give me/users the freedom to write `pascalCase` as it feels natural when it comes to JS projects.
That being said, none of this stops me to appreciate GJS which is indeed the awesome playground, a solid base to build on top `jsgtk` which would be easier to read and write for node.js develoers, and it is compatible with every `npm` module that doesn't use `gyp` but use modules and API I've managed to bring in so far.
The `jsgtk` idea is not to replace GJS, is to glorify it and bring it to more developers without asking them to learn a 4th module loader (CommonJS, AMD, ES6 ... imports.searchPath and imports.stuff in GJS), without asking them to look for documentation (node.js documentation is pretty awesome and always updated and easy to find, including examples) but it needs tons of work because most modules in `jsgtk` are incomplete, not working at all, some is missing, and specially the `http` and `https` part would be "fun" to implement, together with the `net` core module.
Although, like I've said before, that project is stuck. Now, **that** would have been somehow a replacement for GJS but Jasper St. Pierre was the only one on the C++ side and I couldn't help much in there since I don't feel like a C++ expert, so I was helping with the rest and the JS side, but that wasn't obviously enough.
I'm happy I can rely on the robust, battle-tested, and good-for-my-needs GJS, so thanks again for any further improvement or, if you've time, help with `jsgtk`
Best Regards
