3 ms·

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 mu

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 :-)

pjmlp 2y ago
GNOME adoption of JavaScript is one of the reasons why I eventually started using XFCE.
- freedomben 2y ago
  Can you elaborate a bit more? Like Did you notice a decrease in quality?
  - pjmlp 2y ago
    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-memory-leak/ https://feaneron.com/2018/04/20/the-infamous-gnome-shell-mem...
    - freedomben 2y ago
      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.
    - mroche 2y ago
      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 https://gjs.guide/extensions/overview/architecture.html
  - vundercind 2y ago
    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.
    - kaba0 2y ago
      Is it a 6 years old take or what? Because it certainly is very smooth on even low-end machines nowadays.
    - zitsarethecure 2y ago
      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.
- vips7L 2y ago
  GJS is why I went back to Windows. The interpreter would leak memory.
jitl 2y ago
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.
- freedomben 2y ago
  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!
- bobajeff 2y ago
  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 https://github.com/gjsify/ts-for-gir
cxr 2y ago
> 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.
- bsimpson 2y ago
  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.
  - cxr 2y ago
    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 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.
simion314 2y ago
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.

pjmlp 2y ago

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

freedomben 2y ago
Can you elaborate a bit more? Like Did you notice a decrease in quality?
- pjmlp 2y ago
  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-memory-leak/ https://feaneron.com/2018/04/20/the-infamous-gnome-shell-mem...
  - freedomben 2y ago
    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.
  - mroche 2y ago
    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 https://gjs.guide/extensions/overview/architecture.html
- vundercind 2y ago
  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.
  - kaba0 2y ago
    Is it a 6 years old take or what? Because it certainly is very smooth on even low-end machines nowadays.
  - zitsarethecure 2y ago
    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.
vips7L 2y ago
GJS is why I went back to Windows. The interpreter would leak memory.

jitl 2y ago

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.

freedomben 2y ago
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!
bobajeff 2y ago
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 https://github.com/gjsify/ts-for-gir

cxr 2y ago

> 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.

bsimpson 2y ago
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.
- cxr 2y ago
  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 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.

simion314 2y ago

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.