Making Elm faster and friendlier in 0.16
I find the Elm language quite fun and I think it has potential.<p>However, I&#x27;m absolutely not convinced about &quot;the Elm architecture&quot; for anything but the simplest UIs. Is pure functional reactive programming suitable for ambitious UIs ? I do not think so.<p>React has its own set of flaws but at least I believe it nailed the state problem: Encourage the minimization of local state but still make it easy to have some when necessary. I like functional programming a lot but I think this is a case where good old object oriented encapsulation provides a more pragmatic solution.<p>There are all sorts of transient states that a parent&#x27;s component shouldn&#x27;t have to care about (Whether I currently have focus, a transient list of changes not yet committed that should be thrown away should I navigate away, is the calendar drop-down opened?, etc, etc) Elm makes it hard to have truly rich and reusable components for that reason as all that transient state must leak to the parent components.<p>But that&#x27;s still doable at least, if cumbersome; some other things simply appear impossible, like coding a ReactTransitionGroup equivalent. This React component encapsulates the concept of a changing-over-time list of children and animate in&#x2F;out the children that changed across two redraws. It needs to know about the previous list of children to diff it with the new. It needs to manipulate the actual Virtual nodes passed to it so that it temporarily leaves the exiting nodes till their animation finished, etc. This thing has tons of state and it needs it to do its job; and it&#x27;s fine. How would you do this in Elm without leaking the abstraction at every call site ? (I&#x27;m looking for a pragmatic, easy-to reuse by everybody solution, not some convoluted sliding Signal of component lists ;-)  )<p>I&#x27;m wondering whether performance tweaks should be the focus right now; Elm already had good performances. The issue is adoption, and if it&#x27;s too convoluted to write (non trivial) reusable components, I don&#x27;t see how it can succeed. Right now I would never start a complex project with it in fear of getting stuck with a medium-complexity task because the architecture didn&#x27;t foresee my problem.<p>Maybe the architecture provide some escape hatches I didn&#x27;t see, and I would love to be proven wrong.