Show HN: Cell.js – A Self-constructing web app framework
This is a thought-provoking new framework, thank you!  It&#x27;s novel and easy to understand.<p>Having worked on sophisticated React apps, I&#x27;ve come to understand the benefits and shortcomings of its architecture.<p>One insight is that properly encapsulating UI components and their behaviors leads directly and naturally to nested state machines.  React is cleanest if you have one state machine, or N independent global state machines, that drive your app.  Once you start trying to compose state machines to make a sophisticated UI, you end up in setState&#x2F;callback hell, and then you try the Redux&#x2F;Elm model, in which states are composed to make bigger states.  I think it&#x27;s fruitful to experiment with ways of composing state machines in which you don&#x27;t just glue the states together, but you let the machines interact.  Of course you still want to keep your program easy to reason about and avoid spaghetti, but I&#x27;m sure there are interesting patterns lurking there.<p>Another issue is components in React aren&#x27;t supposed to address each other.  You can easily call methods on your children using refs, though this is discouraged and interacts badly with the update cycle and higher-order components.  Components not talking directly to each other is a great feature right up until it&#x27;s not, such as when you have to deal with focus and selection changes.  You&#x27;re forced to contemplate taking what you thought of as pure UI state -- local to a component and tied to that component&#x27;s lifecycle -- and moving it outside of React into a store whose structure parallels the component tree (which in turn parallels the DOM), just so that you can traverse it in a reasonable fashion and update it synchronously while DOM updates remain asynchronous.  In Cell.js, these three trees become one.