Re: Documentation - language default

I want to add my 2 cents:

For the last couple of years I had two experiences on JS vs. Python platform support/DX in the context of GNOME.

On one hand, I coached someone to write a GNOME based app to write something similar to Postman[0] to debug/design REST APIs.

From the API reference documentation POV, I'd say the experience is similar in both, and are more or less equally useful, and the fact that both of them are not integrated in GNOME is a problem, I know this is being addressed.

What is a bit more annoying is how soon you find limitations on the JS side of things and how poorly documented debugging strategies are, the lack of interactive console with tab completion is also a downside compared to ipython+pygobject, but most importantly, is that it is obvious that a lot of JS APIs and use cases get very little exposure compared to Python. There are a lot more Pythonic overrides and I often find APIs that simply don't work on JS. The developer I was coaching soon realized that he was a lot more comfortable learning the GObject APIs and using Glade/GtkBuilder using Python. Something I often find developers scratching their heads about is the fact that we return all output variables in an array and this doesn't seem either properly documented, nor very discoverable from the JS console: many strings return the string size which in python is totally transparent, and you get things like print(some_object.get_string()) as "some_string10" or "10some_string" or -1 instead of 10 if the string is null terminated and things like that. It is very hard to understand what's going on up until you realize how the binding behaves towards output variables.

OTOH in Fleet Commander we wrote the configuration changes logger in _javascript_ and we're seeing ourselves in the need of using SQLite to log Firefox bookmark changes, GOM seemed like a good approach but the it simply doesn't work because the command queue is threaded and you can't execute lambdas in another thread so it segfaults, this looks like a difficult bug so the only way out for us is to migrate everything to Python.

In my experience _javascript_ in GNOME still is a dead by a 1000 papercuts experience, and it requires quite an investment in the bindings plumbing to while you write your apps to try to improve the platform support as you go.

Please don't read this as a rant, it is not, I wish both languages had great support as both target developer bases we want to lure, just wanted to share my personal experience.


2018-04-05 15:36 GMT+02:00 Michael Hall <mhall119 gmail com>:
On 04/04/2018 05:35 PM, Emmanuele Bassi wrote:
You can have the best documentation in the world — but if you don't have people working on the tooling and the actual integration between the language and the platform, then you don't have anything that other people can use.

Indeed, and the intention behind Sri's email was to get input from the wider GNOME dev community about the state of the tooling so we can build documentation around the language and platform capable of giving the best app developer experience.

To give a little context, we didn't approach this with a goal of promoting _javascript_. We started by asking which one language would be the easiest for an app developer to use to build a new application for GNOME desktops. This covered both the difficult of the language itself, the developer community around it, the GNOME specific tooling that would be used, and the documentation already available. We decided that, from what we knew, _javascript_ was probably the best option across all of these considerations, but we weren't sure, so Sri brought it up on this list to get wider input.

So, to reiterate, the goal is not to promote _javascript_ on GNOME. The goal is to pick one language to use in promoting application development on GNOME.

Michael Hall
mhall119 gmail com

desktop-devel-list mailing list
desktop-devel-list gnome org

Alberto Ruiz

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]