Re: Documentation - language default

[Giovanni Campagna <giocampagna92 gmail com>]

On Wed, Apr 4, 2018 at 11:39 AM, Sriram Ramkrishna <sri ramkrishna me> wrote:

Some of you may be aware that we have started a documentation effort in order to give application developers a proper set of documentation for them to write applications.

We need to optimize for one language rather than promoting all the languages.  In the past, we have promoted _javascript_ above all else.  We haven't seen as much movement in  _javascript_ allegedly because the toolchain has not been as robust as the other languages.

Since this conversation could easily get derailed, what I would like to focus on is using _javascript_ as the default computer language for developing 3rd party apps on the GNOME platform.  We would like to validate what the current state of _javascript_ is for writing applications and whether we now have good support in flatpak, debugging toolchains (eg gjs and builder) and other factors we might have not considered but should be identified.

Not going to start any war, but I want to say that for both Python and _javascript_, the tooling support in GNOME Builder is pretty good (compared to IDEs for dynamic languages, and/or to the experience of using those languages for web)

Both languages support 1 click creation of new applications: Builder provides high quality templates such that you can fill a form, and get to a state where you can press start to run your app, or even get a downloadable flatpak bundle.

(That's light years better than what it was when I started with GNOME, and it's a testament of the great work Christian and others have put into it).

Both languages have as-you-type feedback for syntax errors (through gnome-code-assistance).

Both languages have optional linting for semantic errors (with some caveats - you need to install eslint for _javascript_, which means installing the whole nodejs stack, and I cannot get pylint to work on my machine).

Python has autocompletion through Jedi (although it chokes on GI types, for understandable reasons). GJS's autocompletion relies on "word in the documents", which I found to be pretty OK anyway.

_javascript_ has symbol search: you can jump to a class, anywhere in the project tree, with Ctrl+. and the name.

Python relies on Ctags, which tends to be slower. The Gjs symbol index is a little resource heavy anyway (I have it disabled for this reason).

I'll let other people speak for the documentation, but I'll point out that _javascript_'s overrides (JS-specific alterations on top of the generic GObject Introspection API) are minimal and limited to DBus and subclassing of GObject, while Python has a lot more to support a more "pythonic" interface. More overrides means more need for a language specific documentation, rather than mentally translating the C API.
Both have declarative support for Gtk Templates, which are used in Builder's app templates.

Unfortunately, neither JS nor Python have documentation card support (showing devhelp snippets when you hover over a function call, supported for C/C++); it's kind of hard to do for JS/Python because they are dynamically typed. Other IDEs usually rely on type inference or type annotations for this feature (Eclipse and PyCharm have it for Python).

Neither language has support for "Jump to definition" in Builder. Refactorings are also not supported (they are supported for Rust and Go, maybe C/C++?).

They are minor features though.

Finally, I believe a gjs debugger is in the works, but not merged yet.

No idea about a Python debugger.

Overall, I'd argue the language support for _javascript_ is pretty good in Builder (besides documentation), and JS is certainly good to recommend from a tooling point-of-view.

Cheers,

Giovanni

 

Any input in this regard would be well appreciated to drive good documentation to write applications for the GNOME platform.

Thanks,

sri

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list gnome org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list