A React Renderer for Gnome JavaScript | Hacker News Reader

A React Renderer for Gnome JavaScript

github.com

141 pointsbcye77 comments

Awesome! I've long felt that if most devs (especially web devs and/or javascript people) knew about Gnome's excellent javascript support (gjs) they would be much more likely to switch OSes and build some really neat apps. I've been surprised at the lack of interest/enthusiasm. My theory is that it's mostly an awareness problem with a handful of papercuts/sprinkling of technology insufficiency (such as "I'm a React person so I'd like to use React to build a UI), but I'd love to hear from people if that's not the case.

Really cool project! Looking forward to seeing what people do with it :-)

I played around with gjs in 2013, a long time ago. It’s cool in theory but in practice super frustrating to work with. There was no access to normal JS/npm ecosystem at the time; although now the bundler situation probably means you can import some stuff that will work. The debugging / error handling situation was abysmal with a mistake using the native APIs possible to crash the desktop environment and possibly kill all your GUI processes.

If it’s improved a ton maybe it’s interesting; but “you can build or customize gnome with JS” is not really exciting to me because “using gnome” is not something I want to do. I would much rather learn Apple’s toolkit and Swift than invest any amount of time in Gnome.

I also played with gjs in 2013 and found it super frustrating. It's come a very long way since then. At that point it really felt like a giant hack, and did have all the downsides you mention. I'm really glad they didn't abandon it though!

Yeah i too played with it recently. It's actually not too bad. I was able to use vscode with ts-for-gir * to get the js language server working. The documentation seems like it's pretty good though it's a little hard to know where to start. Ultimately, I decided to go with electron since it just made more sense for what I wanted. Which I had a feeling would be the case but it's still really cool that you make gnome apps with JavaScript.

* https://github.com/gjsify/ts-for-gir

> if most devs (especially web devs and/or javascript people) knew about Gnome's excellent javascript support [...]

Blame the Gnome community. They revolted when key players announced a strategy/campaign to put resources behind getting the word out and doubling down on the developer experience to promote JS as the recommended alternative to app development in C for Gnome. They acquiesced, backpedaled a bit, and then within a year we got Electron and all the poor development practices associated with NPM gained the main foothold in the JS space, which was already destined to spill out of the browser, anyway.

We could have inculcated a generation of developers who looked to Firefox and Gnome for how to do app development in JS. Instead we got stuff like `npm install is-odd` and Babel and Webpack.

Babel and Webpack got popular because people wanted to try JSX, but build tools were not common in for web developers at the time. Pete Hunt gave a talk I found somewhere online about Webpack, and then I gave a talk about it at the first React Conf.

No amount of "Linux lets you write apps in JavaScript" was going to keep transpilers/bundlers from being a thing. Even after browsers started shipping HTTP Push, people found it's still more network efficient (at least for transient users) to bundle. Plus, there are privacy/security concerns with relying on public CDNs for libraries, which would be the next-best alternative.

You're talking about browser-based Web apps. I'm talking about Electron desktop apps and NPM-based programs.

And I'm not calling out "bundlers". You said that. I mentioned Babel and Webpack in the context of software that is crummy.

Previously: <https://news.ycombinator.com/item?id=41899671>

> You're having a terrible experience because you're interacting with terrible software. It doesn't matter that it's written in JS (or quasi-JS). Rewrite these implementations all in other languages, and the terrible experience will remain.

GNOME adoption of JavaScript is one of the reasons why I eventually started using XFCE.

Can you elaborate a bit more? Like Did you notice a decrease in quality?

The JavaScript extensions, besides requiring a rewrite from the old C model, for a long time were the root cause of performance issues given how much GNOME has outsourced into extensions from what used to be core features in the GNOME 1.x and 2.x days.

Here is an old example,

https://feaneron.com/2018/04/20/the-infamous-gnome-shell-mem...

Fair. I do think it's unfortunate how "bare bones" Gnome core has gotten.

It's also a gigantic pain in the ass how major releases often break good extensions. It does seem that is getting better, but for a while there I actively tried to stay on release n-1 because otherwise my extensions would all be broken.

I think it's important to note that GNOME extensions aren't a "real" thing as they have no API. They are runtime modifications injected directly into the GNOME environment. This means if their instantiation, cleanup, or operation are not well defined or are buggy, they can break the entire shell. It's not a plugin or add-on system using a dedicated/sandboxed API set to integrate while isolating them from the core platform.

https://gjs.guide/extensions/overview/architecture.html

Gnome feels frame-droppy and janky and things that should be instant take a while. Plus the nutty levels of system resource use. I assume that’s all the JavaScript (it certainly wasn’t like that before) since that’s often what happens to platforms that start using or are based on JavaScript, but maybe it’s not.

Is it a 6 years old take or what? Because it certainly is very smooth on even low-end machines nowadays.

I'm typing this on Fedora 41 (Gnome 47, the latest drop, totally stock no extensions) on a nearly 10 year old 8GB/i5 Thinkpad X1 Carbon and it works just fine. If anything it feels like Gnome has gotten faster with the last few releases.

GJS is why I went back to Windows. The interpreter would leak memory.

Why would someone make a GNOME only app? A developer that is not a fanboy will be more pragmatic and use something that is mature and is more cross platform. So proably a web dev would use elecktron.

This looks quite nice/simple imho, and avoids Electron:

    // App.tsx
    import Gtk from "gi://Gtk?version=3.0";
    import * as React from "react";
    import { Box, Label, Renderer, Window } from "react-gjs-renderer";
    
    Gtk.init(null);
    
    const App = () => {
      return (
        <Window quitOnClose minWidth={200} minHeight={200}>
          <Box>
            <Label>Hello World</Label>
          </Box>
        </Window>
      );
    };
    
    const renderer = new Renderer({
      appId: "com.example.app",
    });
    
    renderer.start(<App />);

Agreed. I don't think I'll drop gtk-rs any time soon, but this is certainly much faster for prototyping. I hope this encourages more folks to develop native Gnome applications.

Somewhat kinda sorta related. I have been working in React for the past 7ish years or so. I decided to try Svelte/Kit for my last project that I have been working on for a year and a half. I liked it, but didn’t think much of it.

That was until I joined a new company a few months ago that was building a NextJS app. It was amazing how overly complicated all the app code seemed to do relatively simple things. Comparing readability to my Svelte code was like me trying to read hieroglyphics.

React was amazing for complex web apps coming from JQuery. But there are other more modern and much simpler and ergonomic frameworks that have built on and learned from the past decade of React development.

Seems like the industry has a bit of Stockholm syndrome thanks to the amazing ecosystem React has…which no other front end framework comes close to IMO.

On the other hand, while I really enjoyed using Svelte for a side project, I ended up rewriting it back in React. I’ve got years of experience with React and found the Svelte story just wasn’t as refined.

Particularly, I was missing support in Biome and Storybook integration was essentially not there a year ago. I’m not sure what it’s like today! But that’s the joy of bleeding edge tech vs. a tool that’s been a market leader for a decade

A more apples to apples comparison is NextJS and SvelteKit - you'll see they have similar levels of complexity when solving the same type of problems.

(I like Svelte too, but NextJS is pretty convenient for what it does.)

SvelteKit is what I used and I think they are both pretty reasonable in how they approach server vs. client side rendering, REST API's, etc... But strictly in dealing with client-side interactions and state, Svelte seems to just get out of my way, while React has so many foot-guns I have to conciously to avoid.

IMO Next.js is overly complex for what it does.

Look at something like Remix gets the job done with much the same features.

Though I’d keep an eye on what Tanstack is doing in this space more than any project. They seem to understand the proper trade off between developer ergonomics and app complexity

I agree that it does feel overly complex, and generally speaking I loathe complexity, but Next.js does do a lot for you in exchange for that complexity. If you don't want/need the fancy client-side/SSR/SSG abilities to really optimize your app, then some of the hoops feel unnecessary, but if you really want that sweet edge, it's fantastic.

That said, I rarely choose Next.js nowadays because even though it enables some real incredible performance/optimization, Phoenix (Elixir) is still great and uses a much simpler (IMHO) model. That could just be because I'm used to that model though from many, many years of Rails and MVC patterns in GUIs before that.

Next is trying to be everything out of box in part to directly fight (for their own benefit) the whole "no two React projects look alike" issue, so of course it's complicated.

I don’t think it’s React that’s responsible for complicated code. I’ve never seen a large GUI app written in any language or toolkit that isn’t super complicated. I’ve dealt with much worse horrors with “vanilla JS” (aka, a home grown framework that does everything a bit worse in every way) than with React or Svelte.

I too have personal project code that is sunshine and roses compared to my Business React day job, but that could also be because my personal project app serves 2 users, is developed by 2 people over a year, and my Business React application serves 100 million users, is developed by ~300 people over 8 years.

not sure - I've yet to see any React code that handles large or incomplete state cleanly (think very long lists not loaded into memory)

One advantage of vanilla JavaScript is its long-term stability. A developer can often revisit code written years ago, make a quick tweak to add a feature, and move on. It will probably feel as familiar and straightforward as it did back then, with new APIs and syntax improvements adoptable in small steps. By contrast, a project built on the framework of the moment might not age as gracefully; the build process can feel outdated or cumbersome as standards evolve. Of course, if you’re able to keep everything up-to-date, it’s less of an issue, but that’s not always feasible. And while vanilla JS may not be ideal for a project scaled to 100 million users, it’s a practical choice for many situations.

Have you seen vanilla js lately?

It's moved on massively as a language, picked up many, many new paradigms.

Going back to code more than a few years old and your newer devs are going to be asking "what's all this var nonsense"?!

Not just that, but the tooling has also evolved and changed.

Good luck trying to get an old project with old versions of Yarn and Gulp working well, where trying to update either breaks the build but using anything other than var confuses the tooling. Provided that you have a build step of any sort (e.g. minifying the assets) and people picked whatever was popular at the time of the project being made.

> By contrast, a project built on the framework of the moment might not age as gracefully; the build process can feel outdated or cumbersome as standards evolve

For frameworks in general perhaps, React in particular has been fantastically stable since very shortly after it was first released, which is over 10 years ago now.

> By contrast, a project built on the framework of the moment might not age as gracefully; the build process can feel outdated or cumbersome as standards evolve

Why can this not be true for 'vanilla js'?

If you're not using a framework, you're almost definitely half-cobbling together you're own ad-hoc framework. Best case scenario, surely that's just as likely to atrophy the same as React/whatever.

Hooks are complicated to reason about and Sevelte has advantage of a compiler. It can decide whatever syntax and then transform it into JS so there's that which allows Svelte components to be in three distinct parts - logic, markup and styles.

As someone who works mainly with Angular but dipped toes professionally in both React and Vue what bothered me the most in the former was the fact that no two React projects are the same, as you're expected to have a collection of libraries for all the things React doesn't provide out of the box.

Angular is terrible in more ways than one, but I've never had to think or worse - argue with anyone what routing/form validation/http request/unit testing library to use or what selection of those is used in a project I'm about to join.

Every time I have to use React, I'm astounded at how convoluted web app development still is in 2024. Am I out of touch or is it really that bad?

You're right, I have to deal with that world instead of .NET and Java, because of many enterprises products now only offering React based SDKs.

If you don't want the fancy stuff, just use react-redux and build an SPA.

It gets complicated past that, but that's because trying to mix streamed server generated HTML and client rendered HTML (and often one and then the other in the same piece of UX) is hard to do.

Everyone in JS-land seems to have an opinion about how tooling should work, and because the platform (well, Node at least) provides no opinions of its own, everyone goes ahead and implements it. So you end up with a thousand-and-one competing bundlers, linters, formatters, test runners, etc, with all the associated churn and cost in learning it all and getting a new project up and running.

Compare that to something like Go which includes all of that stuff out of the box—by and large everyone has just said "yep that seems to work" and stuck with the defaults.

I think the second problem is the browser still fundamentally wants to be a displayer of documents. Yes there has been continued additions of new APIs over the years that have made the SPA pattern much easier to work with, the fact of the matter is you can still save yourself about an order of magnitude of complexity if you can get away with your app being an "old school" multi-page affair.

Yet I wouldn't call gui ecosystem in go a success like js'es is.

Is that a fair critique given that GUI applications aren't really Go's target market?

It just demonstrates that there is a lot more natural complexity in writing UI than CRUD endpoints or small services.

Sure, the browser environment (DOM etc) introduce plenty of problems, but it's going to be more complex than slapping together CRUD endpoints regardless.

It doesn't. The original comparison to Go here was in terms of opinionated defaults with respect to tooling. Go became a popular language for distributed systems, backend web, CLI tools, etc, in part because of the batteries-included tooling. Starting or getting acquainted with a project in Go is pretty straightforward because of this. The opposite is true of JS projects, in part because of the lack of standardized tooling. To point at Go's lack of usage for GUI applications in the context of is a non sequitur.

To phrase the comparison a different way: Would the JS ecosystem be better if there was one set of tools everyone agreed on, similar to Go? (The answer is yes.)

Well, if it doesn't handle a notoriously hard area basically at all, then frankly it's a pretty bad data point to bring up.

Again, the comparison made was about tooling around Go/JS. What Go, the language, is or isn't typically used for is utterly irrelevant to that comparison.

Complexity handled by tooling is absolutely relevant.

Such as... :)

This feels like less of a problem in recent years, with Vite having won the bundler space in the same way that VHS/Blu-ray won home video.

There might be future evolution of course, but it feels like Vite is the default for new/retrofitted projects these days.

Well, Go bundles its own runtime with the executable. JS has to work on probably millions of different combinations of versioned runtimes.

Have you been using plain React, or have you been using a layer on top? I have found that React itself (complemented with React Router and a state management library such as redux, mobx, or similar), but many of the layers built on top of React to make it "simpler" including Next.js and Create React App add a lot of complexity.

It used to be that the build system for React added quite a of complexity (when it was webpack), but with modern alternatives like esbuild and vite that's no longer the case either.

As a (mostly) Typescript / Svelte dev, React is like a shitstorm of bad abstractions, and looking at it makes me irrationally upset. I refuse to flush any brain cycles down that drain.

UI development is hard in general, you just hear more devs complaining about web because it is the first UI platform they try.

Android, iOS, QT, JWT, SWT it is all hell. If anything most modern web environments are way better than most others that came before it.

If a platform is "simpler" than the web it also usually means it is much less powerful.

Any codebase that is worked on by a lot of people tends to become over-complicated unless there is very good technical leadership (and even then).

When you are solo-dev in a project and run into some underlying problem[1] of your codebase you fix the problem. When you have a team the less-powerful[2] tend to work around it because fixing the underlying problem is not just a technical problem, but an organizational problem[3].

The same applies as a codebase gets older and bigger. The best I can explain is through a formula:

real cost fixing underlying problem = size of team * size of codebase affected by problem * nominal cost of fixing problem

Which makes this (in math terms) cubic (^3) while people scale linearly (*n).

Which is why when people compare technologies it is very important to also think about the "Pit of Success":

https://blog.codinghorror.com/falling-into-the-pit-of-succes...

React and Svelte are very similar, but React it so much more powerful[4] people often misuses those powers causing them to become foot-gun.

[1]: Abstractions, APIs, code patterns, libraries used, etc

[2]: People new to the project, people less experienced, people who don't hold the big title (staff engineer, etc)

[3]: It requires talking and explaining things to other people, often very busy people. The bigger the company the more teams need to be kept in sync when big things change, there might also be some inter-department drama or arbitrary deadlines from different teams and so on.

[4]: A lot of the power of React is derived from ecosystem libraries. Where stuff you can do is technically possible with React alternatives, but not very practical.

I think what was more interesting to me was GnomeJS itself! I had no idea this was a thing, and it appears that they have built a few official things in Gnome using it (weather app, sound recorder app).

Very interesting!

Edit: looks like most/all (?) of gnome's shell is JavaScript too! https://gitlab.gnome.org/GNOME/gnome-shell/-/tree/main/js/ui... seems like NPM is nowhere to be seen too - brilliant.

Yeah, JavaScript has been at the core of Gnome now for years. It's brilliant IMHO because it enables the huge ecosystem of web devs to build native apps. The only thing is it's very poorly known/advertised for some reason.

It works quite well too and is very easy to get started. I've hacked together some gjs snippets a few times and it was so, so much easier for a drive-by hack than in the past trying to deal with a complex build system.

You can also use html5 as a display output for gtk applications.

https://docs.gtk.org/gtk4/broadway.html

There are pros and cons to using JS. GJS has only collected the negative features of JS. If there is some guarantee for JS applications that it will work in a few years, then each new GNOME release breaks half of the extensions. Enabling and disabling an extension freezes the system for 8-10 seconds.

And it would be fine if GNOME extensions were too functional... But in fact, the functionality of GNOME extensions lags behind conky or XFCE in capabilities by at least 10 years.

Are there any other desktop environments that support JS?

There is AtomOS: https://github.com/ruslang02/atomos

Windows did, but I think it's deprecated now?

https://learn.microsoft.com/en-us/archive/msdn-magazine/2013...

From https://github.com/react-gjs/renderer#elements-of-gtk3 :

> List of all GTK3 Widgets provided as JSX Components by this renderer:

A few years back I wished there were such things when I tried building for Gnome.

Why is it gtk3? No Gtk4?

This has all of the keywords for me to be interested

Likewise, but with an added layer of dread and sadness. I do not welcome the web- and JavaScript-ification of non-web software.

Plenty of GTK3 software is backed by Python, so switching to GJS should actually improve responsiveness. GTK can certainly be used without declarative GUI and stylesheets, but most programs seem to use both to design the GUI already.

I think React + GJS is a good fit. I don't think it's a good idea to replicate this to other GUI frameworks (Qt, Win32, etc.), but GJS already has most of the components necessary built right into it. Perhaps there are more light-weight alternatives, but this specific combination is a win-win in my opinion.

Is there anything like this for macOS/iOS?

GTK supports MacOS: https://www.gtk.org/docs/installations/macos, there is GJS in Homebrew nad MacPorts.

Do you know by chance how well the support is? I understand components should look native on macOS, but I couldn't find a lot of info about Gnome on Mac

Always hated GNOME 3 for their decision to implement a JavaScript engine into the base UI. Time goes by, now it's time to implement React.

GNOME, the desktop environment that doesn't let you change gamma on Wayland without using ugly hacks which are not officially supported.

GNOME, the DE where the "system monitor" app doesn't display network traffic per process, but instead of adding the support for that, we have another app called "Resources" which doesn't let you see anything you couldn't in the system monitor.

Whoever prioritizes tasks there seems insane to me..

This has been the case for well over a decade.

I remember in the Gnome 2 to 3 transition, they removed the ability to change screensaver options... I'm not sure that ever came back.

I use Gnome daily at work, but I'd switch to KDE if I had a free day. (At home I'm on macOS + headless Linux.)

Who uses gnome? Why would you use Gnome over other linux distros? I'm not asking as a diss I genuinely don't know much about the different preferences ppl have for open source OS.

GNOME isn't a distro, it's a Desktop Environment. It comes as the default in Fedora and Ubuntu, among others.

ohhh

You probably live a monovendor world for your workstation. Linux world is multivendor from the ground up. Just a simple example in your language: app panel launcher can be provided by a software with a different origin of windows manager (as in move, resize, tile windows on your desktop). Yeah, kind of like android but this concept comes from thirty years ago.

I've been using Gnome for over 20 years...

Other than the constant battle to set the preferences back every time I do a distro upgrade can't really complain.

Reply on news.ycombinator.com