racket-gui-easy VS bgjs

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...

  },

The author does a lovely job of covering a number of the interesting ideas in this space. But reactive programming is such a tough sell. I know from experience.

I maintain a reactive, state management library that overlaps many of the same ideas discussed in this blog post. https://github.com/yahoo/bgjs

There are two things I know to be true:

1. Our library does an amazing job of addressing the difficulties that come with complex, interdependent state in interactive software. We use it extensively and daily. I'm absolutely convinced it would be useful for many people.

2. We have completely failed to convince others to even try it, despite a decent amount of effort.

Giving someone a quick "here's your problem and this is how it solves it" for reactive programming still eludes me. The challenge in selling this style of programming is that it addresses complexity. How do you quickly show someone that? Give them a simple example and they will reasonably wonder why not just do it the easy way they already understand. Give them a complex example and you've lost them.

I've read plenty of reactive blog posts and reactive library documentation sets and they all struggle with communicating the benefits.

State machines are cool but they don't compose well out of the box. Behavior Graph let's you build a composable network of them so they become a practical software architecture. (Disclaimer, I am a coauthor) https://github.com/yahoo/bgjs

HTTP imports in Deno are really nice for making quick little test apps. I threw something together the other day using Comlink, that Yahoo state library, and a couple of other things without having to think about package.json or anything else. I wanted a throttle, so I just imported it from the source. It was all light and fast and Just Worked.