Hi list,
Here are the notes from Day 1 of the GJS dev room at GUADEC.
Profiling
---------
Christian has had some profiler patches for a while that he wants to merge so that you can do GJS profiling with Sysprof. The problem is that they (ab)use SIGUSR1 and SIGUSR2 to enable or disable profiling.
Proposal: toggling profiling using DBus. Would fall back to not allowing profiling if DBus was not reachable. gjs-console would export a DBus interface. For gnome-shell and other embedding cases, libgjs would have to provide API for exporting the interface yourself. Concern: We don't want GJS to change its behaviour by init'ing the bus before the application starts.
Porting to mozjs31 etc
----------------------
Yes, we welcome this port, though we need to find time to do it. We want GNOME's JS to be modern, rather than use old Mozilla extensions. Tim Lunn (darkxst) did the ports to mozjs17 and mozjs24, but nobody knows whether he is available at the moment or how much time he has.
Do we port first to mozjs31 or go all the way to mozjs45? In 31 the C API was removed, you can only use the C++ API now. It seems better not to break everything at once. However, it might be possible to skip mozjs38 in favour of mozjs45.
In mozjs45 ES6 classes were introduced. We should figure out how to do GObjects as ES6 classes. Maybe a wrapper function that takes an ES6 class and adds a GType, properties, signals, etc., since we don't have metaclasses. We should also ensure that Lang.Class keeps working.
Missing GObject Features
------------------------
Were hoping to hear from other GJS consumers about whether they were missing any GObject features in their apps. Here are a few that we can think of:
Enums - of course JS does not need enums by itself, but it might be nice to be able to define enum-valued GObject properties.
GValue boxing and unboxing - Philip C forgot which APIs he needed this for. However, if there's a GValue in an API, then it should probably be covered by an override.
Promises? We'll get them in mozjs31. Several Node promise libraries have "promisify" functions that wrap other libraries' callback-based APIs, so we'd like to do something similar for GAsyncResult-based APIs.
Some discussion about GErrors but it seems that support is pretty sufficient in GJS.
Documentation
-------------
The DevDocs site is temporarily out of commission because Philip C ran out of AWS free tier hosting. We need another place to host this. Owen might be able to get it on a VM on GNOME infrastructure.
We also need to make sure the code in modules/overrides/ is documented, currently this is obscure and the only way to find it out is to read the source.
GJS Autocompletion
------------------
For use inside Builder.
Generate JS stubs out of GIR files for this?
Debugger
--------
How is this supported within mozjs?
We would like to work with an existing debugger if possible.
Owen knows of a patch in a Gentoo overlay where someone patched GJS to support a debugger protocol that can be used with a program called "JSRDB". (Link?)
It would be great if we could debug via Chrome Dev Tools, since many people would be familiar with them.
React Native
------------
Niv is interested in this. Ubuntu published React Native for QT and someone else published a React Native proof of concept hack in GJS. (Links?)
Interoperability with Node
--------------------------
Of course this wouldn't work for Node modules with native code, though.
Does Node ever plan to support ES6 modules?
Some debate about whether this should be part of GJS, or a side project. Also differing opinions about how important this is to the platform. In any case, we should follow the ES standard primarily, and have hooks to support Node stuff, rather than mutating GJS into something that looks like Node but is not quite the same.
Developers used to Node have a lot of niceties at their fingertips; e.g. it's good to just be able to do `npm install jshint --save-dev` and your project has linting set up. We don't necessarily need to have the same answer as Node, but our answer should be something else than "we don't have that."
Switching to a different engine
-------------------------------
Consensus seems to be that staying on mozjs is slightly unattractive but not overly objectionable. There has been lots of tricky GObject code written, solving weird cases bit by bit, and another engine would have a lot of catch-up to do; though probably if we were starting GJS now, it would be based on top of Node.
Node seems to be abstracting out JS engine backends? Anyone got a link for this?
Standards for GNOME application development
-------------------------------------------
Currently there's no place in /usr/share to install modules. We should add this.
How do we make it really easy for people to Flatpak their GJS app without having to write a bunch of Autotools? Especially if they come from the wider JS community. We should discuss inside the community what our template for application development should be, and then make sure it is available as a default in Builder. Let's also look at apps like gnome-sound-recorder or Polari, to see what we want and what we don't want.
Do we use package.js?? Should we be getting people to write ES6 modules using Babel??
Outreach
--------
We should make more of an effort to point people to #_javascript_ and
_javascript_-list gnome org. At least everyone in this room should be subscribed :-)
Action Items
------------
- [x] Philip C: Send these notes to _javascript_-list
- [ ] Christian: finish profiling patches with environment variable, plan to merge for 3.22
- [ ] Christian: think about IPC for enabling/disabling profiler
- [ ] Philip C: investigate targeting mozjs31 work for 3.24?
- [ ] Christian: check out adding Tern to Builder
- [ ] Niv: investigate bridging Tern with GObject
- [ ] Niv: experiment with React Native
- [ ] Philip C: move Endless's AsyncTask.js into GJS for 3.22, Owen will review
- [x] Philip C: send setup script for DevDocs server to Owen
- [ ] Owen: check out the JSRDB patch
