[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.