@romainguy I agree with other folks' suggestions to have a blog post explaining (to some degree) what

@Compose

does behind the scenes, if you have time. From the dev site:

A Compose application is made up of composable functions

Is this in a Functional Programming kind of way, alá the type

IO<T>

from FP. Or am I way off base and is it something else entirely?

i have a few blog post ideas and some already in draft form that i’d like to pull the trigger on in the next few days. My goal is to do deeper dives into architecture, design decisions, and what’s happening under the hood.

Cool! Looking forward to learn more about the internals of Compose! 💪

@Leland Richardson [G] please cover in your blogpost why compose does not use the way of reactive frameworks like elm or clojurescipt/reagent providing some data structure describing the ui and then reconciling it before the actual render? This would make some things easier, e.g. it is easy to implement a hot reload via a ui test that starts a server and sends user a serialized ui specification to render. It also can enable the possibility for serverside rendering or other user-side extentions, because it is a structure that can be serialized and introspected

Hot reload may require much more than this. What if your UI change requires a new data model for instance? Or you changed the logic on an onClick handler? Sending a description of the UI tree isn't enough.

@themishkun i am not sure i agree with your conclusion. There isn’t anything we are doing that would prevent the things that you’re talking about, as far as i’m aware.