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.
> 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.
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.
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.
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.
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.
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.
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
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 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.
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.
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.
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.
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
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":
[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.
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.
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.
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).
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.
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.
Readit News
Really cool project! Looking forward to seeing what people do with it :-)
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.
* https://github.com/gjsify/ts-for-gir
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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
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 like Svelte too, but NextJS is pretty convenient for what it does.)
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.
Deleted Comment
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.
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.
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.
https://docs.gtk.org/gtk4/broadway.html
https://learn.microsoft.com/en-us/archive/msdn-magazine/2013...
> List of all GTK3 Widgets provided as JSX Components by this renderer: