Are you happy with JavaScript programming language used by Gnome project?

This post was flagged by the community and is temporarily hidden.

1 Like

I’m happy with GJS, and generally with JavaScript.

GJS is one of the newer language bindings for GNOME, so there is ancillary functionality that could do with improvement, like integrating DBus and GTask/async, GVariant, other type mappings, and so on. That being said, GJS is progressing at an acceptable rate and has already proven quite robust.

ECMAScript (JavaScript) itself is merely a collection of data types, control structures and some methods for manipulating them. If you think you can do anything useful with JavaScript in the absence of a framework like node.js or GNOME, you’re probably confused about what JavaScript is.

ECMAScript6 was a pretty big game changer for JavaScript, and the only glaring omissions in my opinion is 64-bit integers and mutable bytearrays. The former will be addressed shortly with BigInt and even then, it’s pretty rare you actually encounter an integer that can’t be safely squashed into 2^53-1.

One benefit of JavaScript having essentially no standard library, is that we get to use the native GLib event loop and there’s little or no conflict with GLib, Gio, Gtk or any other module that makes up GNOME’s “standard library”. This is in contrast with Python for example, which has an amazing standard library including the asyncio event loop, much of which duplicates or conflicts with what the GNOME API provides.

A benefit of working with GJS in general, is that we’re improving the possibility of embedding the SpiderMonkey JavaScript engine for everyone in the community. GJS, then, is not only a viable language binding for applications, it’s becoming a viable option for applications to allow themselves to be extended with plugins and extensions, like we do with GNOME Shell.

The most common mistake I see people make when writing extensions or applications in GJS, is when they approach the situation thinking “I’m writing JavaScript with some GObjects”, when they should be thinking “I’m writing the GNOME API in JavaScript syntax”. Most of the mistakes I see with dangling objects and signals, mainloop GSources and asynchronous patterns is cause by developers treating the GNOME API as a tool you can reach for, instead of the environment you’re already inside.

The most common mistake I see people making when deciding whether or not use GJS, is thinking they are somehow trapped in JavaScript. Remember that JavaScript by itself can’t do anything like read/write files, handle user input/output, draw to the screen or anything else required to actually be useful. If you were writing in C, the first thing you’d do is organize your project so that common functions and classes were collected into an internal library. If you’re writing in GJS, you would simple follow that step by making it a shared library and automatically generating GObject-Introspection bindings. This is precisely how we can use GLib/Gio, Gtk, Clutter and everything else in GJS.

Given a broader overview of what GJS is, how it works, and how it can be used, I don’t see how someone could think there’s a reason for it to disappear anytime soon.


I like it, but mainly because typescript is also possible. Although Javascript is much maligned and everyone raves about python, I think I slightly prefer JS to python, and definitely prefer TS. The advantage of type-safety isn’t just more reliable code, it makes semantic auto-completion much better, and even with type annotations and PyCharm, python seems to be some way behind Typescript Server (as used by VS Code and YouCompleteMe).

Of course you need type definitions for Typescript, and luckily there are available thanks to ts-for-gjs. I’ve been submitting some PRs for it, and currently my fork has some much bigger changes to provide a proper inheritance tree (previous versions just copied all parent/ancestor members into a derived class), but this hasn’t been tested thoroughly.

1 Like

I have no issue with using JS at all. I think its a usefully flexible language that has a wide userbase, low barrier to entry and a future. I can’t think of any language that I would prefer to see support for at the moment.