So I tried it out a little. It's a really nice api, buuuuuuut I am really disappointed in the resource consumption. A simple form with a few fields and a submit button was consuming 238mb of ram on my macbook m1 air. Then when I used raco exe the resulting executable size was 65mb! So for maybe large scale app it would be fine, but that feels really heavy for something small.

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.

FYI, Racket has a `get-handle` method to get a native handle from a `window<%>`: https://docs.racket-lang.org/gui/window___.html#%28meth._%28...

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.

Racket/gui is far from having every feature under the sun like JavaFX or QT, but what it lacks in breadth it makes up in flexibility and customizability. It's seriously one of the very best cross-platform, easy to set up solutions available.