3 ms·

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 elemen

by teyc 9y ago

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

gliechtenstein 9y ago
Thanks! Zero framework is just one of the distinct traits that makes Cell special. Here's why I started working on Cell: Aside from Cell, I am working on a project called Jasonette http://jasonette.com/ http://jasonette.com/ which lets you build build cross platform iOS/Android native mobile apps by writing just a JSON markup. I have recently started working on a web version of Jasonette, so that a single JSON markup can run exactly the same on iOS, Android, and the Web. I tried implementing it with most of the existing popular JS frameworks but found that they don't fit the bill. They are too complex to fit Jasonette's philosophy of placing simplicity and ease of use as top priority. Also Jasonette is great for decentralized apps, but the centralized nature of all existing frameworks and approaches wasn't compatible with what I was trying to achieve. Cell doesn't just make things easier, but is designed fundamentally different from traditional MVC frameworks. I think this image does a good job of explaining: https://s3-us-west-2.amazonaws.com/fm.ethan.jason/domtree.jpg https://s3-us-west-2.amazonaws.com/fm.ethan.jason/domtree.jp... Instead of creating a centralized control mechanism, Cell lets you inject M-V-C (or anything else you want to) directly into each HTML element, thereby decentralizing the control. I think this will enable a lot of creative things and design patterns going forward (which I'll demonstrate first with Jasonette-Web). As for using querySelectors, I totally get it, because that was my initial feeling as well. Initially I also felt like accessing elements directly was a step backwards (because we've become accustomed to the "new" approach where we keep a separate data structure that binds with the DOM, and directly accessing the DOM feels like what we used to do with jQuery) But Cell's approach brings its own benefits. First, as I mentioned the control logic can be decentralized. Second, all the complexities of model-view binding goes away because the very concept of binding existed because they were separate. In case of Cell, the element can "contain" its own model/view/controller, and because it contains them there's no need for binding, which is one reason why Cell can stay simple. Another factor is this architecture effectively turns each element into an app execution container of its own, so these components can be extremely modular and portable. You mentioned when the app becomes larger we'll need some architectural pieces to coordinate data, and you are right, except that the same logic applies here too. The "architecture" is the DOM tree itself. So the root element can contain the root model, and the descendants can access it as well as keep their own version of the model, so forth. I tried my best to explain all these concepts on the homepage but I do realize it's a long read, so I hope this explanation makes enough sense. TLDR: it requires a bit of stepping back and reframing what we've been accustomed to but I'm confident this new approach brings a lot of benefits that weren't easy to implement before.
- mnishihan 9y ago
  How does it scale? Anti pattern is sometimes useful & obvious, but going with anti patterns for everything is a stupid decision IMO. Frameworks are for greater good. If you don't need it, don't use any of them. But when "No framework" is listed as a key Mantra for yet another js library, I simply find it as dumb & full of madness. :-/
  - gliechtenstein 9y ago
    What I meant by "No framework" was that there is no "Framework API" to implement. Cell itself is a framework, so I agree that frameworks are for greater good. As for your question on how it scales, I don't see a reason why it shouldn't scale. In fact I think this approach is more scalable than any existing centralized approaches to building web apps because you can create complexity out of simplicity. p.s. The "No framework" part is just one of the benefits that arise as a side effect of Cell's decentralized architecture. I did my best to explain why I built this on the homepage. I know it's long but I hope you take a look at it once more, it's worth a read even if you don't use the framework because Cell does bring something new to the table. Hope this makes sense!

by teyc 9y ago

gliechtenstein 9y ago

Thanks! Zero framework is just one of the distinct traits that makes Cell special. Here's why I started working on Cell: Aside from Cell, I am working on a project called Jasonette http://jasonette.com/ http://jasonette.com/ which lets you build build cross platform iOS/Android native mobile apps by writing just a JSON markup. I have recently started working on a web version of Jasonette, so that a single JSON markup can run exactly the same on iOS, Android, and the Web. I tried implementing it with most of the existing popular JS frameworks but found that they don't fit the bill. They are too complex to fit Jasonette's philosophy of placing simplicity and ease of use as top priority. Also Jasonette is great for decentralized apps, but the centralized nature of all existing frameworks and approaches wasn't compatible with what I was trying to achieve. Cell doesn't just make things easier, but is designed fundamentally different from traditional MVC frameworks. I think this image does a good job of explaining: https://s3-us-west-2.amazonaws.com/fm.ethan.jason/domtree.jpg https://s3-us-west-2.amazonaws.com/fm.ethan.jason/domtree.jp... Instead of creating a centralized control mechanism, Cell lets you inject M-V-C (or anything else you want to) directly into each HTML element, thereby decentralizing the control. I think this will enable a lot of creative things and design patterns going forward (which I'll demonstrate first with Jasonette-Web). As for using querySelectors, I totally get it, because that was my initial feeling as well. Initially I also felt like accessing elements directly was a step backwards (because we've become accustomed to the "new" approach where we keep a separate data structure that binds with the DOM, and directly accessing the DOM feels like what we used to do with jQuery) But Cell's approach brings its own benefits. First, as I mentioned the control logic can be decentralized. Second, all the complexities of model-view binding goes away because the very concept of binding existed because they were separate. In case of Cell, the element can "contain" its own model/view/controller, and because it contains them there's no need for binding, which is one reason why Cell can stay simple. Another factor is this architecture effectively turns each element into an app execution container of its own, so these components can be extremely modular and portable. You mentioned when the app becomes larger we'll need some architectural pieces to coordinate data, and you are right, except that the same logic applies here too. The "architecture" is the DOM tree itself. So the root element can contain the root model, and the descendants can access it as well as keep their own version of the model, so forth. I tried my best to explain all these concepts on the homepage but I do realize it's a long read, so I hope this explanation makes enough sense. TLDR: it requires a bit of stepping back and reframing what we've been accustomed to but I'm confident this new approach brings a lot of benefits that weren't easy to implement before.

mnishihan 9y ago
How does it scale? Anti pattern is sometimes useful & obvious, but going with anti patterns for everything is a stupid decision IMO. Frameworks are for greater good. If you don't need it, don't use any of them. But when "No framework" is listed as a key Mantra for yet another js library, I simply find it as dumb & full of madness. :-/
- gliechtenstein 9y ago
  What I meant by "No framework" was that there is no "Framework API" to implement. Cell itself is a framework, so I agree that frameworks are for greater good. As for your question on how it scales, I don't see a reason why it shouldn't scale. In fact I think this approach is more scalable than any existing centralized approaches to building web apps because you can create complexity out of simplicity. p.s. The "No framework" part is just one of the benefits that arise as a side effect of Cell's decentralized architecture. I did my best to explain why I built this on the homepage. I know it's long but I hope you take a look at it once more, it's worth a read even if you don't use the framework because Cell does bring something new to the table. Hope this makes sense!