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.
// 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 />);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.
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
(I like Svelte too, but NextJS is pretty convenient 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
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.
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.
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"?!
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.
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.
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.
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.
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.
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.
Sure, the browser environment (DOM etc) introduce plenty of problems, but it's going to be more complex than slapping together CRUD endpoints regardless.
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.)
There might be future evolution of course, but it feels like Vite is the default for new/retrofitted projects these days.
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.
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.
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.
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.
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.
Other than the constant battle to set the preferences back every time I do a distro upgrade can't really complain.
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..
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.)
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.
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.
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.
Here is an old example,
https://feaneron.com/2018/04/20/the-infamous-gnome-shell-mem...
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.
> List of all GTK3 Widgets provided as JSX Components by this renderer:
https://learn.microsoft.com/en-us/archive/msdn-magazine/2013...