[HN Gopher] A React Renderer for Gnome JavaScript
___________________________________________________________________
A React Renderer for Gnome JavaScript
Author : bcye
Score : 100 points
Date : 2024-10-31 11:57 UTC (3 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| ingen0s wrote:
| This has all of the keywords for me to be interested
| globnomulous wrote:
| Likewise, but with an added layer of dread and sadness. I do
| not welcome the web- and JavaScript-ification of non-web
| software.
| gedy wrote:
| 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 />);
| techwizrd wrote:
| 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.
| iddan wrote:
| A few years back I wished there were such things when I tried
| building for Gnome.
| carlgreene wrote:
| 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.
| phildenhoff wrote:
| 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
| gedy wrote:
| 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.)
| carlgreene wrote:
| 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.
| no_wizard wrote:
| 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
| freedomben wrote:
| 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.
| crooked-v wrote:
| 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.
| jitl wrote:
| 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.
| torginus wrote:
| 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)
| mikedelfino wrote:
| 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.
| _puk wrote:
| 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"?!
| KronisLV wrote:
| 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.
| Tade0 wrote:
| 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.
| phito wrote:
| 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?
| pjmlp wrote:
| 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.
| crooked-v wrote:
| 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.
| deergomoo wrote:
| 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.
| mirekrusin wrote:
| Yet I wouldn't call gui ecosystem in go a success like
| js'es is.
| mattlondon wrote:
| 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.
| freedomben wrote:
| 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.
| bilater wrote:
| 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.
| oaththrowaway wrote:
| GNOME isn't a distro, it's a Desktop Environment. It comes as
| the default in Fedora and Ubuntu, among others.
| bilater wrote:
| ohhh
| n3storm wrote:
| 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.
| zb3 wrote:
| 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..
| cbarrick wrote:
| 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.)
| freedomben wrote:
| 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 :-)
| jitl wrote:
| 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 wrote:
| 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!
| cxr wrote:
| > 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.
| pjmlp wrote:
| GNOME adoption of JavaScript is one of the reasons why I
| eventually started using XFCE.
| freedomben wrote:
| Can you elaborate a bit more? Like Did you notice a decrease
| in quality?
| pjmlp wrote:
| 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...
| freedomben wrote:
| 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.
| vundercind wrote:
| 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.
| westurner wrote:
| From https://github.com/react-gjs/renderer#elements-of-gtk3 :
|
| > _List of all GTK3 Widgets provided as JSX Components by this
| renderer:_
| zazaulola wrote:
| 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.
| vinnymac wrote:
| Are there any other desktop environments that support JS?
| shepherdjerred wrote:
| Is there anything like this for macOS/iOS?
___________________________________________________________________
(page generated 2024-11-03 23:00 UTC)