A modern programming language that makes developers happier.

kotlinlang

But really Compose gets some things right that React doesn't IMO
• state variables are single objects, not those annoying (value, setValue) tuples that have to be passed around everywhere, and where setValue doesn't actually change the immutable value variable until recomposition
• kotlin-css is already integrated. If I try to use a CSS library with react, like emotion or JSS, things *really* blow up

&gt; state variables are single objects, not those annoying (value, setValue) tuples that have to be passed around everywhere, and where setValue doesn't actually change the immutable value variable until recomposition
Keep in mind Compose works the same way when you use the decomposition style of state declaration, which is often useful when hoisting state:
```val (value, setValue) = remember { mutableStateOf(default) }```

Ah yeah I just found that out. Still though at least it's optional

<@U0NT624JZ> Yes, the `val (value,setValue) by . . .` syntax exists, but that is just syntax to mimic react applications. Under the hood, it is not implemented that way at all. Which going back to the point, one of the things Compose got right

<@ULERY2F70> I wouldn't say it exists just to mimic react -- there is real value to that syntax (I personally prefer it over assigning it to `var` which doesn't feel idiomatic to me). In fact at one point Leland Richardson was considering making it the *only* way to access state: <https://twitter.com/intelligibabble/status/1476612660716208132>.

Furthermore, regardless of the under the hood implementation, because the decomposed `value` is a `val` it is immutable — `setValue` doesn't change it until recomposition, which was the OP's original complaint:
&gt; setValue doesn't actually change the immutable value variable until recomposition

Well beyond the point about mutability (which really depends on programming style and/or use-case), the other thing I'm not so happy with the tuple style is that they are decoupled upon destructure
Which means you have to pass them separately into other places
it's similar to the array-of-structs / struct-of-arrays problem

but anyway for my own use-case the CSS thing seems to be a bigger issue