Today we'll be talking about what's new and what's next with JavaScript in GNOME. Evan will be

This slide deck is also meant to be a resource that you can consult later. The slides are already available on Philip's web space so if you want to click on the links NOW, you can already go there and follow along with the presentation. By the way, I'll use these little circled 46 and 47 icons to show things that you can expect to see in GNOME 46 and 47. And when you see a hat emoji, that's me tipping my hat to the person who contributed it.

There is a library of demos and examples, similar to GTK demo but more aligned with the HIG and less "benchmarks" / test cases with examples ready to use, copy paste and play with I will talk more about it tomorrow in the GNOME JavaScript Tooling talk also, there will be a workbench workshop on Saturday

What's new for GNOME 46 and the upcoming GNOME 47? This part of the talk is primarily aimed at people who write code for the GNOME platform in the JavaScript programming language, whether that is GNOME Shell, apps, shell extensions, or even command line scripts. GNOME has its own JavaScript engine for all these purposes, GJS, which is an extended version of the JavaScript engine from the Firefox browser. In past years I talked a lot in the "what's new and what's next" sections about the various ways to modernize your code, but nowadays we are running a pretty modern JavaScript in GNOME already, with no modernization "backlog". The new language features are still pretty exciting, but there's nothing earthshaking like ES6 classes. Additionally, we have a lot more visibility of these improvements these days, with better documentation, a more active community of GJS developers, and initiatives like This Week in GNOME, so a yearly GUADEC talk is no longer the only channel where people find out about these things. Nonetheless, I've gotten feedback that people still find these talks useful, so that's a good reason to keep doing them in addition to all those other things I mentioned.

We have a human-friendly formatter for JS values. Also traditionally called a "pretty printer". It was added by Nasah Kuma in an internship a couple of years ago. It's used in several places in GJS: in console.log, in the interactive interpreter, and in the debugger. It's a great place to get started if you're interested in contributing to GJS. We have a bunch of issues open to improve the pretty printer and it's quite easy to write tests, as well. Sriyansh and Gary have both made some of these improvements in the past year and I hope to see more people following their lead!

Transition to Philip

I almost always have a section on what JavaScript language features are new, when we upgrade the version of the underlying JavaScript engine to one from a newer Firefox. This year we're planning to upgrade to Firefox 128 in GNOME 47.

- Split strings into graphemes, words, or sentences according to locale rules

When gobject introspection moved into GLib (which Philip Withnall will give a talk on later) we got separate namespaces for platform-specific APIs. The old ones will still work for the time being, but you'll get a deprecation message. The code snippets on the second line here is a pitfall of GObject-introspection that caused confusion over and over again. All GObjects have constructors that take a property bag, while some of them also have static methods named "new". Getting them confused often led to crashes. We've now changed the constructor so that it only accepts a plain object, not a GObject, and you'll get an exception. I hope no-one was relying on the old behaviour, but if you were and migrating your code is not straightforward, let us know and we'll revert that change in favour of a longer deprecation period. Many crashes were caused by trying to use C-only APIs such as reference counting and pointer stashing. We just block these now. (I'm not sure why we never did that before!) If you used them, sometimes they would crash, or sometimes they would appear to work. If your code used them and appeared to work, well, now it definitely won't work. Just delete the usage.

This part overlaps with what I do in my day job at Igalia, as a member of the TC39 committee that standardizes the JavaScript language. I'm excited to present some of these!

There are many more proposals in the pipeline, but these are the ones I'm particularly looking forward to or that I think are relevant to GNOME. Excited to see Temporal finally coming to SpiderMonkey as I've been personally working to bring this proposal to JavaScript for the past couple of years! Especially together with Intl which I'll talk about in a bit, I'm excited to use it in GNOME Shell's JS code at some point. Decorators we've been eagerly awaiting for the better part of a decade! - I first wrote a blog post on designing a decorator API for GObject classes in July 2017. If you've written code in Rust or Python, you probably have gotten used to iterators. Iterators exist already in JS but without all the neato methods Using statements are kind of like context managers and with-blocks in Python. They'll be quite useful for explicitly disposing resources, like disconnecting signals and such, which is currently a bit of a hassle in GJS. Relying on it implicitly often runs into problems with callbacks being run during garbage collection. "Using" should help

While we're on the subject of Intl, I want to make a pitch for why you should use it in your app or extension, as well as GNOME Shell. Intl is a global object that does internationalization stuff. Intl is great for formatting all sorts of things in a way that's aware of the user's locale. This is something we have always cared about in GNOME: we are an international desktop environment and it's a huge part of our appeal that we are accessible in as many languages and cultures as we are. Shout-out to our volunteer translators! Intl can't _yet_ replace Gettext, but with the MessageFormat proposal that I mentioned on the previous slide we might be getting there!

You can do sorting, date and time formatting, number formatting. So, why you should use Intl. Imagine you're a translator and you see...

..this. This is actually from from gnome-shell. Not only does the translator have to figure out what the correct short date and time format is for their locale, and how to express it in this cryptic strftime format. They also have to punctuate it correctly, because in their translation UI this "U+2236 RATIO MARK" might look at first glance like a regular colon.

Sorry I'm not going to make some overworked translation volunteers stop what they're doing and decipher the strftime codebook! And even if they did... now imagine you're the developer and you're integrating the new translations...

...and you see this. Quick, is `"%j, %R %p"` a valid strftime string? The other question is how do you know that what the translator puts in there is correct? If you see this in a translation commit, you can read the strftime manual yourself to check it, but you can only guess or ask the translator if that was what they really meant!

If you use Intl, then the code will look like this. It's certainly longer but, at least to me, it looks more readable. And most importantly, it doesn't need to be translated.

Well you might ask, certainly someone has to translate that. Who is it? The answer is that these translations are provided by ICU and Unicode, which are projects with major corporate support behind them. So don't burden our volunteers to repeat stuff that's already paid for by large companies and freely available!

You might say that this gives up our control of how we want dates and times to be displayed. And in some cases that is right.

An example of when you might want to do this is that ICU's translations use a colon character instead of the typographically correct ratio mark. In GNOME we do care about the little details like this. Intl formatters have a formatToParts method that gives you tagged segments of the string and allows you to customize them before pasting them together and presenting the string to your user.

We'd especially like to thank Nasah Kuma for joining in with ideas for this talk, but unfortunately she couldn't be here to present. A big thank you as well to everyone who helped in any way with GJS in GNOME 44 and 45! Here's the license for this slide deck; you may reuse bits as-is, with attribution, and not for commercial use. Now it's time for...

...questions.