This is a thought-provoking new framework, thank you! It's novel and easy to understand.<p>Having worked on sophisticated React apps, I'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/callback hell, and then you try the Redux/Elm model, in which states are composed to make bigger states. I think it's fruitful to experiment with ways of composing state machines in which you don'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'm sure there are interesting patterns lurking there.<p>Another issue is components in React aren'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's not, such as when you have to deal with focus and selection changes. You're forced to contemplate taking what you thought of as pure UI state -- local to a component and tied to that component'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.
Interesting. Though not really clear why you continuously say "no API!" when you <i>have</i> an API--it's just in the data itself via your "special keywords" i.e. $cell, $update, etc. That's kind of like saying React components have no API since you never actually call e.g. componentDidMount directly.
Interesting, but I get worried every time I see that code refer to specific DOM id. It's probably ok for simple programs where there is only a handful of elements. When the program gets larger, you will still need architectural pieces to coordinate data.<p>You've put a lot of work into this, and there are a lot of examples that are helpful to anyone who wants to evaluate it. I'm curious what is the motivation behind this design - besides zero framework ? - is this in-use in production any where?
After having looked through the tutorials, I am unclear about the following:<p>1) How does one cell send messages to another. I suppose this is left to the application?<p>2) How do you test code written in Cell.js? It appears to me that this is going to be hard to do?<p>3) Is it intended that the entire webapp code be a single JS file? I guess one would need a server side build step to "assemble" multiple Cell.js components into a single one?
This is interesting. I have had a look at the examples. One question that comes to mind, how do you make a reusable component? Say I have:
Part = {
$cell: true,
$type: "h2",
$text: "Part No: ",
}
Part is to be instantiated multiple times in the same page, but I want different $text. How do I pass this data?
JS frameworks and SEO have a rough history. Pre-rendering tends to be the workaround, but Cell's lack of hierarchy might make that more difficult than normal.<p>How would you work around it?