WHATWG standards implementation in GJS
Description
Would you accept MRs for very common small-ish WHATWG features such as:
GJS has begun implementing a very limited subset of WHATWG standards based on:
-
Adoption - do other non-Web JavaScript platforms (e.g. Deno, Node) implement it
In particular when a standard like
console
is implemented by nearly every environment. -
Complexity - does the standard require a large amount of support
We don't want to create a large ongoing maintenance burden if it is not absolutely necessary.
-
Stability - has the standard reached a mature state?
We don't want to target standards which have brittle APIs
-
Utility - does the standard provide significant benefits for our developers
We won't implement WHATWG APIs just for compatibility, there must be a benefit.
-
Duplication - does the standard duplicate an existing GLib, Gio, or GObject API without additional benefits?
Ideally, the WHATWG API shouldn't simply be a wrapper around an existing API though Adoption and Utility are prioritized over this point.
console
is an example where Adoption wins whereas withURL
, Gio'sUri
API wins out.
Suggested Standards
"Rejected" Standards
-
atob/btoa - With !662 (merged),
GLib.base64_encode
will be equivalent tobtoa
when passed a string. -
URL - Gio now offers the
Uri
API.
Un-evaluated Standards
In general, many standards require too many features/globals/work to make sense in gjs
and would be better suited as light polyfills in userland. With ES modules and import maps coming along it should be easy to use/shim/polyfill/whatever. What about under the GNOME umbrella gitlab.gnome.org/GNOME/gjs-contrib
?
Prior Art
- Node.js WHATWG URL
- Node.js console
- Node.js WHATWG Streams
- Node.js timers
- Node.js TextEncoder/TextDecoder
- deno timers, atob, btoa, console, streams, TextEncoder, TextDecoder ...
- Every browser in existence.
- mozjs
console.log