The Elm architecture is amazing!

Gleam looks great. Reading the FAQ, especially why the don't implement type classes, I am a bit worried though that it leans to much into trying to be simple.

Minimalism can work in dynamic languages because they impose basically no restrictions on your types and you can have crazy complex ones for free but in a purely static languages a lack of more advanced type system features can make writing library code very annoying and make the language feel very boilerplaty. The advanced type system features that languages like Haskell or OCaml provide are not purely for academic wankery, some of them are extremely useful. Even Golang had to add generics.

I hope they don't fall in the same trap as Elm did where it got so obsessed with simplicity that super knee-caped the language. I mean the Gleam devs seem already be way more pragmatic. At least it seems to have a decent FFI which provides an important escape hatch.

One thing I always dislike about Elm and most of its offshoots is the lack of good composability of widgets. In most other architectures, most widgets are registered with their parent component in one single location, and are otherwise fully self-contained.

In Elm-likes you usually need to explicitly need to connect all child components in the model _and_ view _and_ update in a way that ultimately connects all leaf components to the root component. I know that there many Elm proponents that see that as a positive (as that makes execution more transparent). However in practice that usually ends up with either overly shared Message types where logic isn't contained to the widget it belongs to, or a boatload of boilerplate just to do .map operations between a child-Message-type and it's wrapping parent-Message-type.

I think this boilerplate can be solved by some degree with good framework support (and some try), but most Elm-likes don't and it makes scaling projects in them a pain.

Yes, that is the major problem I have with TEA. The best thing about Flutter's design is that it employs a "reverse iceberg" where many of Flutter's own widgets are composed with other widgets, leaving few architectural details "under the ocean".

That experience is lacking in TEA, although better in immutable languages like Gleam where it is easier to keep functions pure. Even in Iced, I'm going to side with those Elm proponents here and prefer Elm's function composition approach any day over guarding React or Flutter state from becoming spaghetti.

Tyrian is the Scala.js framework that follows TEA. https://tyrian.indigoengine.io/

What is wrong with the dioxis approach?

I wouldn't say it's outright wrong, I just much prefer the ergonomics of an orderly, TEA-like state management. Many of the projects I make lend themselves well to that approach.