> But can you make parent-child communication with these mini TEA components like in React or Vue? It seems to me that we can't.

I think parent-child communication isn't necessarily the right way to tackle problems.

Otherwise, I'll link to the oft-linked "Child-Parent Communication in Elm: OutMsg vs Translator vs NoMap Patterns" [1].

[1] https://medium.com/@_rchaves_/child-parent-communication-in-...

> Yes you can, whether should, is a different question. You can have a ton of mini TEA components.

But can you make parent-child communication with these mini TEA components like in React or Vue? It seems to me that we can't.

1. Interestingly enough, Richard Feldman's elm-spa example is composed of a lot of different TEA components.

2. I think the boilerplate is good in making things explicit.

I don't think RF is against TEA components. But you just don't need to TEA all the things [1] - and to do so introduces a lot of work, and moreover reduces the deep thinking you should be doing about what data structures you need and building the view around it.

But in react is is natural to say "oh I need a spinner, let's make a functional react component for that". And you can always keep some local state in React and avoid the message passing relay-race you'd have in Elm with the same approach. So Elm benefits from a different approach.

[1] https://youtu.be/RN2_NchjrJQ?t=2136

> 2. I think the boilerplate is good in making things explicit.

I think Boilerplate is the lack of a more succinct way of expressing your intent. So, boilerplate is never good in making things explicit, it's just the (current) shortest way possible to accurately expose your intent.

For example, in TypeScript, if I delve into making datastructures `algebra-ish`, I always have the boilerplate of defining a `tag` field in my objects, and lengthy switch-constructs to match on the tag field. It's not good in making things explicit, it's actually just the only way (at the moment).