Cell.js Long Term Plan and Design Decisions about cell

[NxtChg]

This is so idiotic, I don't even know where to begin!

You've created a tiny library, which core feature is adding some code to DOM elements to match JS variables.

And you're gonna sacrifice real, practical usability for the sake of some delusional grandiose plans of world domination?!! With what?!! Your 500 lines of code?!!

What kind of mega-value will you add to all those things (AI networks, ffs?! Really?), which don't even have any DOM elements?

What is your grand idea? "Using JSON to describe The Structure of The Universe"?..

Jesus... This is so delusional, you should go and do an MRI scan to see if you have some sort of a tumor that ate your brain...

Somebody, for the love of god, clone those 500 lines and do it right!

[leeoniya]

while i disagree with @NxtChg's demeanor, i do generally agree with his feedback.

Generalization, categorization and structural uniformity has been a goal of all engineers ever. "Everything is a file" [1] (Unix), "Everything is an object" (OOP), "Everything is a function/immutable" (FP), "Everything is a tree", etc..

While many classes of problems can be represented via these structures, it's not always the case. A graph is not a tree, only i/o stuff (sockets, files, endpoints) can logically be grouped into "files", a value is not a function, hardware is not immutable. Trees will have very sub-optimal performance in many use-cases that can technically look like trees if you squint hard enough.

An overly general declarative solution for all problems will be a pretty bad case of shitty "wtf" usability, shitty performance, or both due to the underlying truth that the abstractions mask. You will not be able to predict the needs of all domains into the future. At some point, the abstractions will simply cease to make sense, or become so deep as to be incomprehensibly translatable for the target audience.

Declarative solutions typically only work well when restricted to a given domain. You need imperative building blocks to really be generic. I think a good demo of this is e.g. S (FP) [2] and the derived surplus (UI) [3].

It's amazing how awesome a domain-specific API can be and how unusable an overly-generic one can be.

https://en.wikipedia.org/wiki/Unix_philosophy#Do_One_Thing_and_Do_It_Well

[1] https://en.wikipedia.org/wiki/Everything_is_a_file
[2] https://github.com/adamhaile/S
[3] https://github.com/adamhaile/surplus

[gliechtenstein]

What is your grand idea? "Using JSON to describe The Structure of The Universe"?..

Yes! Totally spot on! Bravo :) 🎉 🎉 Check out my other project https://github.com/Jasonette/JASONETTE-iOS

Just to be clear, Cell and Jasonette are completely separate projects, but will probably prove to have synergistic effect going forward, because they share similar design principles :)

[devsnek]

@gliechtenstein will do (p.s. can you look at #36 😄)

[jaimegomez]

@gliechtenstein For what is worth, I deeply enjoyed this post, it's the kind of thing I spend most of my time thinking about and trying to materialize in different ways in all my projects. So thanks for sharing your thoughts, even though I fully realize how for practical people this is all nonsense 😆

[gliechtenstein]

@idkjs great to hear! Contributing to the library is helpful, and also just sharing examples is also super helpful, so please feel free to keep sharing anything you build with Cell. And feel free to contribute wherever and whenever it makes sense! Any type of contribution is welcome :)

[devsnek]

I really like the idea of separating the html elements from cell. I might look into this...

[NxtChg]

microservices, artificial neural networks, decentralized applications, blockchain...

What the?.. Architecture Astronaut much?

[piranna]

Good post, it should be put in the project docs like GENESIS.md or so.

Now I understand the point on the declarative way and the $cell atribute and I understood it, but I still disagree with the global context polution and the automagical way of registering the apps. I like the idea of the emergent behaviour, but It can also be done by calling each script to the factory function from their script themselves, so there should not be any problem here. I'm not saying about removing the declarative way, but instead allow an implicit way to register them instead of only an implicit one.

[devsnek]

you can explicitly render an object by calling document.body.$build(cell object)

Subnote: you can render children into anything on the page by calling <that element>.$build(cell object)

[idkjs]

For what its worth, I'm a totally rookie programmer, and all the stuff out there is so hard for me to grok sometimes. I quite literally have a page in one my notebooks that sketches out this exact same thing, except I used the most ubiquitous elements from the periodic table of elements and a conceptual understanding of how they build biology. I was probably watching to much Neil Tyson-Degrasse and Cosmos, but nonetheless, it occurred to me that patterns repeat and that the universal pattern of construction of organisms from the elements in the periodic table of elements hit me hard. I'm really glad you did this and would love to be of help to you if that is possible.

[gliechtenstein]

@leeoniya thanks for sharing your thoughts. I was hesitant to write this post because I have no intention of dropping everything and just start working on this "generalization" problem right now, and didn't want to mislead people. The top priority is improving Cell as a web app framework. But I took some time to write this post to address the suggestions made over at #23

To be clear I don't think there's any problem with cell's usability as is, at least in the sense brought up in the linked issue.

And at the end of the day it's a bad idea to just overhaul the entire API of a library that's already out there just because of a subjective opinion.

I do agree with all of what you say, and I have no plan of making this library worse just for some philosophical ideal, so I totally welcome your feedback if you have specific thoughts and ideas on the current implementation. I would love to discuss.

If there are parts of the code today you think are causing problems because it's too declarative, please point out and we can discuss and figure out a solution. Thanks.

[gliechtenstein]

@devsnek if you do get around to making any progress please share! 👍

[piranna]

you can explicitly render an object by calling document.body.$build(cell object)

I know I can render any object using that, but my concern is about it would need the document.body object exists first, that for scripts at <head> I'm not sure if it's the fact, and would need to wait to window.Load as explained at #12. I think the solution proposed there to add a Cell() function would be good, internally checking the DOMContentLoaded event and injecting the nodes when it's ready.

[devsnek]

we could go along with the new node api and just attach that exports object to window named Cell but global pollution is annoying

[gliechtenstein]

@jaimegomez @piranna thanks for the feedback guys, I'll try to incorporate parts of this post to the repo as a file somehow.

As for the explicit instantiation topic, let me think about it a bit more today and get back to you, maybe there's a clever way to do this while making as little compromise as possible.

In the meantime if anyone comes up with a good idea on this, please feel free to share.

[astritzinger]

Thanks for the brilliant ideas of Cell that seem to be implemented just the right way. Many of your thoughts have been in my mind too, but ... I small complain I want to state, is the redefinition of the semantics of this. Consider the use another special variabe like $self, $context, $branch, etc.

[minecrawler]

I like the idea of cell (and I rarely like a library or framework!) and I might give it a try in one of my projects (Cordova App), pinch it a little to fit my idea of what it should do and then come back here to complain :D

However, as nice and little as it is at the moment, please do not try to go for your "grand schemes" just like that. I rather have a small, focused library than a monster, which can do many things, but is good at nothing, because of compromises. Also, I think this should stay a JS library, and I can promise you that calculation-intensive stuff, like AI, will not move to JS anytime soon.

Rather than mutating cell to something strange, use the idea and principles behind it to build similar libraries for your other use-cases. Then you can pick the best language and analogies and the whole experience will be superior in the end.

---

Well, as for why I think this library might be great: I have the chance to keep refs to my nodes, which makes separation and usage awesome! Don't destroy that :)

// nodeA.js
window.myApp.nodes.nodeA = { $cell: true, $type: 'input', /* ... */ };

// nodeB.js
window.myApp.nodes.nodeB = { $cell: true, $type: 'button', /* ... */ };

// fooLogic.js
window.myApp.nodes.nodeB.onClick = function() {
  sendToServer(window.myApp.nodes.nodeA.$text);
};

<!DOCTYPE HTML>
<!-- WHATWG minimal notation applies -->
<script>
window.myApp = {
  nodes: {},
};
</script>
<script src="nodeA.js"></script>
<script src="nodeB.js"></script>
<script src="fooLogic.js"></script>
<script>
const ele = window.myApp.nodes;
</script>

* untested, will come back with results.