[janesconference]

Yep, but if you have a chain of components with a single source of truth, like store -> top level component -> chain of dumb components, then you have to set attributes on the tlc for the dumb components to inherit. This causes a series of problems - it's your responsibility now to ensure those attributes don't mask each other and are synchronised (maybe one of your children components wants a certain value as `name`, another the same value as `title`, another as `header` - you now have to check they always refer to the same value in your scope. What if one of your grand-children also wants `title` with a different meaning?). Now suppose these components are not yours, but are exported from 3rd party libraries you don't own or control: you're officially in a world of pain. It's a bit like scopes in Angular 1.x but with even less control.

A better idea to do deal with this? Properties, like in React. You control what you pass down and every component has a clear interface you can interact with, without polluting the context. Incidentally, React has contextes, which are vaguely similar to your inheritance mechanism, but are used to implement "special" behaviours, like implementing theming across the component chains etc.

[gliechtenstein]

Cell has a fundamentally different architecture than other frameworks, so I don't think it's fair to compare it with how you would use other frameworks.

The whole point of cell is to build the simplest building block you can compose to build complex structures, and a lot of the problems faced by other traditional approaches can be tackled in a different manner using Cell.

From my experience I can build fairly complex apps without having to worry about all the problems you mentioned, they are just structured differently.

If you have time, I really suggest you try playing around with it, If you still don't like it you don't have to use it, but I'm sure it brings some interesting ideas to the table that cannot be experienced by just reading the homepage.

[inimino]

As unpleasant as it may sometimes be, part of the task of marketing a new framework is explaining how it solves problems that people already know how to solve in a different way.

So while telling people to play with it is good, it's even better if you can point to a demo that illustrates and resolves the issue that was brought up.

[janesconference]

You can build fairly complex apps because you own all the components. In real life, you don't always have the luxury: when you have an ecosystem, the core system must be able to support it. Imho you can't easily, and I'd love you to prove me wrong. These are not new problems: older frameworks lived or died trying to solve these issues already.

If cell apps need to be structured differently, how should they be structured? How do you plan to support single source of truth and a large number of third party libraries written with your framework without scope clashes? I appreciate I can avoid using your framework, but that's not the point :I'm trying to express my criticism in order for you use it (or to throw it away, if you like) - I suppose you submitted your software to HN in order to receive honest feedback.