React is holding me hostage

What a nice idea it was to scroll immediately and figure out this is another bullshit reactive programming evangelism blogpost. Bro, we've already had this shit in JS like 20 years ago (Flapjax anyone?). Now go on and write your code like this for at least few weeks and see how great and maintainable and "fine-grained" it becomes.

> a lot of the form libraries out there triggered huge numbers of rerenders and caused perf issues

Something I don’t quite get, doesn’t useRef just solve the re-render issue?

Vue supports JSX, but it is by no means the default. https://vuejs.org/guide/extras/render-function.html

```

The quickest obstacle you’ll run into as someone new to React will be something like this

function MyComponent() {

  const [num, setNumber] = useState(42);

  // infinite loop
  setNumber(n => n + 1);

  return {num}

}

Trying to make state updates at the top level of a component will result in an infinite loop.

```

I've taught React to dozens of people without ever seeing someone try this. A render function is an idempotent function that produces UI for a given state, and it's called every time the state changes. What are you, semantically, trying to do by updating state midway through a render function? This isn't a footgun, this is the author picking up a screwdriver and going "I wonder what happens if I press it against my eyeball"

Good, he should rant!

> What would framework-integrated fine-grained reactivity look like? Probably something like Solid.js

It would look like JavaFX which has had this exact approach since it launched over 10 years ago as well as a large library of observable operators and collections complete with delta events, the ability to define components with a "shadow DOM", with custom CSS properties, using both JSX-like widget-oriented markup and code, and a whole heap of other things the web community has since slowly rediscovered. Here's the high level observable operators API (there is a lower level one that lets you define custom operators):

https://openjfx.io/javadoc/19/javafx.base/javafx/beans/bindi...

And here's the author's Solid.js example in Kotlin with FX:

  class Counter : Label() {
    private val count = SimpleIntegerProperty(0)
    init {
      textProperty().bind(concat("Counter: ", count))
      timer(period = 1000L) { runLater { count.value++ } }
    }
  }

You could also write that in many other languages like Clojure (with cljfx for FP fans), Python, Ruby, JavaScript, and of course Java. It would be less verbose if I used a library that better used Kotlin's features, but the goal here is that you can look up the APIs from the link above (there are a couple of implied static imports).

So not much different, but it demonstrates how the text property of the label is bound to a dynamically computed string which is in turn bound to an observable number. When the timer fires, the count increases and the label is recomputed. Everything is done that way so layout computations, for example, won't run unless the size of the label changes. And that's it - no need for VDOMs or prop drilling or state memoization or any of these other performance hacks.

At some point you'll observe that this seems a lot like "reactive programming" as used on the server side, and then might want to explore a library like ReactFX which connects these two worlds together.

https://github.com/TomasMikula/ReactFX

There are some other nice features in this type of toolkit that the web community seems to be heading towards. I'd be willing to bet a lot that at some point they'll even reinvent inheritance under a new name, because being able to write code that's generic over component trees is really pretty useful. The hooks/functions model totally wrecks that and has led to this explosion of "design systems" (otherwise known as themes that bundle half a widget toolkit), none of which interoperate properly or can be coded against in an abstracted manner.

None of this is to say that FX is perfect or that React/SolidJS etc are the wrong tools to use. You can run FX apps in a browser using a form of server side rendering - check out https://www.jpro.one to see a fully crawlable website that's actually implemented using JavaFX on the server with no frontend/backend split existing at all. But it only works well if you don't have a fast and reliable server connection, plus a server with plenty of RAM and CPU. Alas browsers pull all sorts of mean tricks to keep people locked inside the HTML5 sandbox so JS frameworks aren't going anywhere, but it would be nice if that community spread its wings a bit and looked at prior art from outside their language. GUIs are old and the challenges involved in them aren't new, and from the outside it looks suspiciously like there is no real progress being made here, only wheel spinning.