electric VS racket-gui-easy

The cleanest way to handle the backend and frontend charade I've seen until now is using https://github.com/hyperfiddle/electric which is a clojure DSL on top of react

Opa was ahead of its time by at least 10 years. Have you seen Electric Clojure [0]?

[0] https://github.com/hyperfiddle/electric

Scala's ZIO/ZLayer is a great implementation of this idea where the monadic types are visible to userland DSL. Electric Clojure (which I lead) is a Clojure implementation of similar ideas (specialized to web development) where the types are concealed, "just write Clojure". In practice with Electric, we are building really complex/dynamic abstractions (think pure functional app-builder and highly concurrent UI) and we haven't even felt a need to implement multimethods yet. https://github.com/hyperfiddle/electric

I'd expect your auth stuff to mostly just work with some minor jiggling of the middlewares. We have a few out of the box approaches to routing, the tutorials app uses hyperfiddle.router which is an experimental composable router (may be a bit hard to use), the easiest starting point would be a simple goog.history integration. Someone posted a retit integration in the slack iirc. And you can of course roll your own.

Built with Electric Clojure and Missionary! https://github.com/hyperfiddle/electric

Looks like you're already in Emacs. I strongly recommend racket-mode as mentioned in another thread.

With regard to prototyping GUI's I'd suggest taking a look at https://github.com/mfelleisen/7GUI. https://github.com/Bogdanp/racket-gui-easy could also be a good place to start.

With regard to Racket more generally, I'm probably not the best person to ask since I had a very high friction start where I just banged my head against the wall until things made sense.

I took a similar approach in my Racket library, gui-easy[1,2]. Though I opted to not defer any computations, any observable (similar to a signal from the post) update propagates to observers immediately, and there's no incrementality -- observables are just boxes whose changes you can subscribe to. Regarding the disposal problem, I used weak references and regarding the where to take observables and where to take concrete values as input question, I decided that any place an observable can go in, a concrete value can as well and it's been a convenient choice so far. For fun, here's an example[3] that builds the todo UI from the post.

[1]: https://docs.racket-lang.org/gui-easy/index.html

For native apps, I would devote coding resources to the Guile-GI project which generates Guile bindings to the cross-platform Gtk C library by way of the Gnome Object Introspection and Reflection library. I would also port the Racket gui-easy library over to Guile-GI so declarative GUIs could be written.

There is also gui-easy a declarative gui framework: https://docs.racket-lang.org/gui-easy/index.html

It’s not the only version either

See https://github.com/Bogdanp/racket-gui-easy/tree/master/examp...

  },