Racket GUI Screenshots
alex-hhh.github.io
alex-hhh.github.io
I just started playing around with clojure last week, but I have yet to do any GUI work with it.
I intended to try out Racket at some point, but this GUI library looks so nice I might start soon.
I wonder if anyone has implemented cassowary contraints yet for Racket and combined the two.
Its still smaller and less resource intensive than say electron, but man that executable size is pretty brutal for a native app.
For reference the same form made with Haxe + SWT + GraalVM on an intel mac(graalvm native image is not supported on m1 yet) is about 13mb and uses 100mb of ram. Also A jlinked and packaged swt app would probably have better memory management, and end up with a package size in the ball park of 70mb as well.
Again though the Racket API seems nice, but it doesn't expose the native window handle like SWT does which would prevent you from embedding a third party graphics context like GLFW which is kind of a bummer. I've done that with Nim+Tcl to have ab opengl context with Tcltk controls as well as Haxe + SWT + GLFW to have bgfx with native controls.
There are ways to optimize executable size with various tradeoffs, though they require compiling Racket yourself or using a Racket BC distribution. By default, Racket generates machine code (including natively on M1), which tends to be larger than bytecode. That's only been the default since February 2021, so I'd bet there's still room for improvement in code size for the default configuration.
Win32 is expectedly the most stable because the API hasn't changed for decades, so the effort was spent on stabilizing and fixing bugs over the years.
Gtk2 is also stable and should work fine. It is the most stable of Linux backends at the moment,
Gtk1 was stable until development dropped some years ago, though AFAIK recently someone tried it and fixed any issues. It doesn't really get much love though.
Gtk3 is not feature complete but simple stuff should work, judging from a recent message in the development mailing list there isn't anyone interested in fully working on it - there is development but not any dedicated developer. Makes sense, personally i wouldn't bother to work on something i knew will soon be deprecated.
Gtk4 isn't even a think yet AFAIK.
Qt4 should be around as stable as Gtk2, perhaps a bit less. Requires dragging around the qt4pas shared library though since Free Pascal cant link against C++ libraries directly (Gtk binaries are self-contained and can link against the system Gtk with compatibility going several years).
Qt5 is newer but i think it started as a copy of Qt4 so it should be around the same quality, perhaps better in trunk as it gets most of the Qt development. Like Qt4 you need to drag a shared library around to use it.
Carbon was the most stable on Mac OS side but of course it isn't available in newer Macs. Not that it was ever beyond alpha quality, but at least it worked.
Cocoa should be fine nowadays but i think there isn't any dedicated developer and its quality is hit or miss as it only picked up whatever Mac development was going on only recently when it became impossible to do 32bit programming.
There are some other backends but they are in various stages of not working.
In practice however you can release binaries for all major platforms, you just wont get the shiniest backend versions outside of Win32. In my experience the most stable are Win32 and Gtk2. I think Qt5 should be somewhere next to that so if you make a Mac application and behaves weirdly you can use the Qt5 backend instead of the Cocoa backend (this was a common workaround for 64bit applications when Carbon was still usable but only available for 32bit applications). Of course this means you have to drag not only the qt-to-pascal interface library but also the entirety of Qt. Though that should still be less than Electron and you'd still get to use "native" widgets on other platforms.