Yes, there are LCS deduplication logic, synchronized DOM update, initializers, reactive updates, storing and mutating states, etc. They're all in there. They're just structured differently because it has a different architecture than existing frameworks.
The whole point of Cell is not trying to match feature by feature of existing frameworks like React/Angular/Ember/etc. And I am aware Cell doesn't look like most existing web app frameworks that follow best practices, because that's the point.
I did my best to explain the rationale behind all the design decisions on the homepage, could you take a look at those and let me know if you have questions? Thank you.
1. Freedom from NPM induced dependency hell for simple apps.
2. Dynamic DOM.
3. Learning - for newbies give them cell and React Native; see which gets to a working page first.
4. Readability of both the code and the JSON model/blueprint.
5. Simplicity - you only have to know JSON and HTML.
These above just from my few first minutes looking through how i can use this at work.
Might just be the single most useful and usable 'framework' ive seen all year. This is awesome. So many possibilities to construct DOM on the fly from programs for a web UI. And the liberation from dependency hell of npm is so refreshing.
Thank you - this lies in the realm of proper 'Contribution' rather than the usual 'regurgitation' one gets form vast bulk of other coding tools. You have rethought the fundamental approach of how and why one wants to use HTML together with apps.
One main concern that I have that isn't addressed by the site - performance. How many cells can you have before it starts to show? Any benchmarks to speak of?
From what I understood, attributes are passed down via prototypal inheritance. How do you prevent children attributes from clashing with their ancestors' context?
I have nightmares of a long chain of components, each with a `name` attribute, and not knowing which `name` is which at any level.
If the answer is to somehow namespace the attributes on a collaborative basis (for example with a naming convention), it won't work.
Just like how events bubble up on the DOM tree, each node tries to resolve from its own context, and if that doesn't work, resolves upwards until it reaches an element that does have that attribute. So technically, the attributes are not passed down, but searched for. Here's more info on this https://github.com/intercellular/tutorial/blob/master/README.... Hope this helps!
Btw this is a very new framework so everything is a start. So if you have better ideas about dealing with certain problems please feel free to send pull requests or start a thread on github. Thank you!
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.
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.
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.
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.
> Easy to maintain: "Development workflow" doesn't exist. No NPM, No Webpack, No Babel, just vanilla Javascript and 100% based on web standards.
Are these tools really the main source maintenance pain for web developers?
In my experience the code I write is the biggest maintenance burden. I'll suffer through complex tooling if it helps me avoid maintenance anti-patterns (like storing state on DOM elements...)
Hi, author here. Most of the work cell does internally is to let users interact with the dom as though they are touching them directly, but at the same time actually insulates them from doing so by using a pseudo proxy object. please feel free to take a look at the source. The "Nucleus" is the part that handles all this. Hope this answers your question!
The problem with the mutations isn't the direct DOM access; it's that mutation is an unscalable approach to representing UI. A lot more needs to be "kept track of".
The DOM elements aren't stateless, but they will behave like they are if you update every attribute that can change in the `$update` function.
Really all you're doing is mutating the DOM objects themselves, but one of them is this magic `$update` function that runs every time one of that element's attributes changes I think. The framework just provides a proxy object for accessing the attributes, and every cell is extensible with custom data and functions. For some fun try overwriting `this.$update` in `$update`.
Another thing I totally missed at first is the fact that you can embed a <script> containing a variable with the `$cell` property anywhere in the page and the cell will show up in that part of the DOM, and you can do this as much as you want.
Actually, there's a better method for embedding in an element: Just put the <script> wherever you want, but include an `id` in the configuration object that matches a <div> in your page.
> Are these tools really the main source maintenance pain for web developers?
I consider TypeScript (or Elm) support a best practice for "JavaScript" development, so something that brags about not having a development workflow is a non-starter. It's not only not a pain for me, it's a significant missing feature.
If it's something that has to be maintained for more than a month, use Typescript or Flow. Just do it. Everything else is a PITA.
If it's just something you want to whip up quickly and won't be maintained, jumping through all the hoops of npm, building and bundling is just annoying.
OK, first of all this is awesome. Great idea and I'll definitely try it out for a prototype soon.
Second, this is a pretty normal ES5 framework though. It's just declarative, or based on convention, or whatever you want to call that style. And it's component-based. And definitely not JSON because it has functions.
Thank you! You are right about everything. It's intentionally built with es5, it was pretty challenging to do so. Initially I used es6 proxy to handle all the state synchronization and message dispatch without touching the DOM but since my main goal was to build something that works on ALL browsers today, without any transpiling, I instead used Object.defineProperty. It was tricky but got it to work!
Also yes it is component based but it's a different type of component than other frameworks. Since cell has no classes to inherit (to get rid of dependency) you can write the entire app with stateless functions only. This scales better than class based approaches since functions don't have overhead and you can "componentize" anything.
Hope this makes sense! I did my best to explain these on the homepage but if some of them are not clear enough please let me know, I'll correct them!
Ah yeah I think, I read a bit more and the idea of using pure functions to generate the mostly-JSON spec is actually really neat. But how can you handle many events and complex custom side-effects without adding bigger and bigger functions to the mix? And then DOM elements will need a way to communicate with the other elements and share data. I suppose you could always add a message bus architecture like Redux or whatever, but [oh yeah I forgot I made this flux module thing for ES5! https://github.com/guscost/simple-flux/blob/master/sf.js]
Yes, cell itself has a decentralized architecture but that doesn't mean you need to do everything in a decentralized manner.
Just like you can build spaceships, police station, cars, and all kinds of complex things using lego blocks, you can build complex architecture using the simple building block that is cell.
I myself have been experimenting with different approaches of structuring apps using cell, and there are really a lot of different ways since we become free from having to inherit classes and instantiate objects from them. I don't want to be constraining about how one uses cell so I don't talk much about what a "best practice" is (yet)
But maybe sooner or later people can share some nice approaches for structuring "traditional apps" using cell
> Just like you can build spaceships, police station, cars, and all kinds of complex things using lego blocks, you can build complex architecture using the simple building block that is cell
Except you cannot have a hierarchy of cells without the top level cell having responsibility of the whole world below in its own scope: that doesn't scale well and limits complexity to maybe a couple of levels.
I think a message bus plus a bunch of autonomous mini-DOM element trees could be pretty cool. It might lead you to flatten the DOM too much for big apps though, not sure.
EDIT: Whoops, it's pretty trivial to nest components and describe a tree of HTML.
Simple and useful. What a shame there’s no easy way to integrate Cell into pre-existing code.
Well ... actually ... there IS a way, but this feature is only mentioned one-third of the way into the tutorial – a tutorial that begins with the words “you don't even need to read this tutorial”. So, to someone evaluating Cell, it might as well not exist.
Sorry about the confusion! Yes the effortless integration is actually one of the selling points of cell, I will definitely take your advice and make sure this is more visible, thank you!
What is the inspiration for this? Alan Kay has often talked about everything-is-a-computer (i.e. individual objects are fully-functioning computers), which was an idea he took from his background in microbiology.
Thanks for making this, I'm interested to check it out.
I love technology that mimmicks nature. Never thought I'd see it in a web non-framework. Cells in this are analogous to biological cells which contain DNA that knows how to build other cells.
Thank you. i built it because I believed things can be much simpler.
The inspiration was from real life cells. It's amazing how small autonomous cells bind and interact with one another to form a complex organism.
Cells have genotypes which manifest themselves into phenotypes. And a nucleus that self-controls the cell cycle.
I thought by creating a completely autonomous structure that mimics how cells work it will be possible to create complexity from simplicity.
i hear a lot of people saying this will never scale because it doesn't look like react or angular, but I think the point is not about what's missing, but what you can do with these by combining these self aware elements. I believe this approach is much more scalable because it builds on top of simplicity.
Is there an easy way to do represent something like this in Cell:
<p>I will say this <em>emphatically</em></p>
As far as I can tell, Cell doesn’t permit this. If you have multiple child nodes ($components), none of them can be text nodes, so you have to work around it like this:
<p><span>I will say this </span><em>emphatically</em></p>
Why not do away with the $text keyword entirely, and treat any strings in the $components list as text nodes? So instead of this:
Yes everynight someone is ISSUE hacking and really dont give a Care. Lieing is an ISSUE in Paris Texas instruments to an errors agurment with me about mine cash include an Lawsuit dragging mine phone will not let it go tell i give giving me an update on the same day i just updated it resticking mine stroge after i fix it. Report from Charles Lewis Nichols. ROYALIST PROFITABLE PRESIDENTCHARLESLEWISNICHOLS86@HMAIL.COM THEFT HAVE DID THID BEFORE I EVEN ACCEPT THEM LOUD OUT SINCE 2010.
Tried the hello world demo. When I delete the text it won't remove the first typed character from the label.
I thought one of the advantages of React/Angular/Vue frameworks is their support for event modifiers, cross-browser support for the events via synthetic events. Or is there a support for these ideas that I am missing.
I don't know. This looks like it's mixing View (or Template) and Controller. How well does that work for nested "cells" with data changing on the parent and child? And does this make it difficult to separate logic and design concerns?
I think the first reaction when people see Cell is to compare with existing frameworks and existing best practices.
And when you come from that direction, Cell is a terrible framework that doesn't follow any best practices and does things in a weird way. But the thing is, Cell is fundamentally different from other approaches. That's why a lot of "best practices" don't apply and don't make sense for Cell.
If you go back in history, people hated angular because it went against the general wisdom of "separate view from logic", and react was shunned because it had some weird way of doing things. But I think they solve problems in unique ways that make peoples lives easier in different ways, and that's what matters at the end of the day.
And I am confident that Cell can make people's lives significantly easier in another different way. So I suggest you actually play around with the examples at https://play.celljs.org
Words don't mean anything really because the problem we're trying to solve is come up with a dead simple easy way to build web apps, which is not really easy to grasp when just thinking about theories. Hope this helps!
This sounds awesome but i use windows phone and your website is just a blank page for me! IE on Windows phone has quirky JS support. Just fyi. I will check this from another device.
This looks great, and something I'm going to try using. It looks like it'll work well for small "embeddable" widgets as part of a normal article or blog post.
For some reason this made me think of clojurescript, and I think it might make a nice library for use in cljs as well.
This is really very fascinating and I'm looking forward to testing it out.
Question for the author: I'm a firm believer that, the more a tool is really good at some things, the more that tool is not good for other things. (A really good drill is also really not good at being a hammer.)
It looks like Cell is really new and interesting and does some things really well; what things does it not do really well, or would you recommend to not use it for (as compared to other frameworks?)
Thanks! I'll be honest, cell is only a couple of days old, and I myself can't say what The best practices are.
And this is by design because the goal was to create complexity out of simplicity.
I believe this bottom up approach can be much more scalable in the long run than some frameworks that dictate every single detail you need to implement, because all organisms are basically built that way (cells make up body) and they seem to be working fine.
Personally the more I use this the more I find creative ways of using it, which is the beauty.
But I also do realize sometimes it's good to have some sort of "best practice" structure and I think people will figure it out eventually.
TLDR: I think you should be able to build all kinds of sophisticated apps with it because I believe emergence is the best way to construct something. if that's not the case, that doesn't mean the framework is a failure but just needs some tuning, which I believe is totally possible just because the library is so minimal. So please feel free to play with it and share if you run into trouble, we can evolve cell just like cells evolve in the real world.
This looks like the framework I've been waiting for. Remember when you could create web pages in a simple text editor without 10+ tools, command lines, config files and languages? That's before you get into transpiling and everything else I hate about the world today.
Maybe I'm sitting here saying something that sounds like "get off my lawn" to everyone else in the thread, but this thing is amazing.
I know exactly where you are coming from, so let me save you the hassle
npm install -g create-react-app
create-react-app my-app
cd my-app/
npm start
type unknown.variable in various files and see how they handle it - there should be a (compile time) stack trace that points you exactly to the right file and line.
react is literally the opposite of what the parent described. It's a huge convoluted ecosystem that requires many new tools to use effectively and almost everything in the stack is complex to learn.
> react is literally the opposite of what the parent described. It's a huge convoluted ecosystem (...)
React is not an ecosystem. React is a library with an extremely simple API. Everyone acts like one must use a flux implementation, a complicated router and everything when you use React. It can't be farther from the truth. Out of the box, React also provides, more or less, whatever cell provides.
An entire DSL to describe the DOM is not a simple API. React is nice, but its API is at best easy as opposed to hard, not simple as opposed to complex.
I agree this is great, but the fun part is that the dynamic language advocates first claims dynamic languages is the shit, then they build the tools to mimic staticly typed languages ;)
(True; staticly typed isnt the same as not declared, but still, i think you get my point.)
In my experience, this kind of minimalism is great on paper, but in practice if you throw out at least some of that complexity, you also have to rewrite so many things yourself. Sometimes that's a good thing but some features are too complex to get right every time and it's worth reusing a good quality version of them, which unfortunately sometimes requires using a bunch of questionably designed build/dev tools.
You can still do that. Just last week I hacked together a quite useable web page using simple HTML and a few <?php-snippets to make it useable :) Don't need JS for everything.
I like the minimalist approach. I could probably use this to spike a few prototypes quickly, but I see one caveat: the lack of 2-way binding...
While I understand that 2-way binding might complicate everything, it is the one feature I need the most when setting up a quick-and-dirty prototype. IMHO this might be the deal-breaker...
88 comments
[ 4.5 ms ] story [ 22.8 ms ] threadYes, there are LCS deduplication logic, synchronized DOM update, initializers, reactive updates, storing and mutating states, etc. They're all in there. They're just structured differently because it has a different architecture than existing frameworks.
The whole point of Cell is not trying to match feature by feature of existing frameworks like React/Angular/Ember/etc. And I am aware Cell doesn't look like most existing web app frameworks that follow best practices, because that's the point.
I did my best to explain the rationale behind all the design decisions on the homepage, could you take a look at those and let me know if you have questions? Thank you.
These above just from my few first minutes looking through how i can use this at work.
https://facebook.github.io/react/docs/hello-world.html
Btw this is a very new framework so everything is a start. So if you have better ideas about dealing with certain problems please feel free to send pull requests or start a thread on github. Thank you!
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.
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.
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.
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.
True, but how useful is it?
> Easy to reuse: Everything is powered by stateless functions instead of classes and objects, making it extremely modular.
Maybe it's all stateless functions under the hood, but the "hello world" code snippet includes code that mutates the DOM:
> Easy to maintain: "Development workflow" doesn't exist. No NPM, No Webpack, No Babel, just vanilla Javascript and 100% based on web standards.Are these tools really the main source maintenance pain for web developers?
In my experience the code I write is the biggest maintenance burden. I'll suffer through complex tooling if it helps me avoid maintenance anti-patterns (like storing state on DOM elements...)
The DOM elements aren't stateless, but they will behave like they are if you update every attribute that can change in the `$update` function.
Really all you're doing is mutating the DOM objects themselves, but one of them is this magic `$update` function that runs every time one of that element's attributes changes I think. The framework just provides a proxy object for accessing the attributes, and every cell is extensible with custom data and functions. For some fun try overwriting `this.$update` in `$update`.
Another thing I totally missed at first is the fact that you can embed a <script> containing a variable with the `$cell` property anywhere in the page and the cell will show up in that part of the DOM, and you can do this as much as you want.
I consider TypeScript (or Elm) support a best practice for "JavaScript" development, so something that brags about not having a development workflow is a non-starter. It's not only not a pain for me, it's a significant missing feature.
If it's something that has to be maintained for more than a month, use Typescript or Flow. Just do it. Everything else is a PITA.
If it's just something you want to whip up quickly and won't be maintained, jumping through all the hoops of npm, building and bundling is just annoying.
Second, this is a pretty normal ES5 framework though. It's just declarative, or based on convention, or whatever you want to call that style. And it's component-based. And definitely not JSON because it has functions.
Also yes it is component based but it's a different type of component than other frameworks. Since cell has no classes to inherit (to get rid of dependency) you can write the entire app with stateless functions only. This scales better than class based approaches since functions don't have overhead and you can "componentize" anything.
Hope this makes sense! I did my best to explain these on the homepage but if some of them are not clear enough please let me know, I'll correct them!
Just like you can build spaceships, police station, cars, and all kinds of complex things using lego blocks, you can build complex architecture using the simple building block that is cell.
I myself have been experimenting with different approaches of structuring apps using cell, and there are really a lot of different ways since we become free from having to inherit classes and instantiate objects from them. I don't want to be constraining about how one uses cell so I don't talk much about what a "best practice" is (yet)
But maybe sooner or later people can share some nice approaches for structuring "traditional apps" using cell
Except you cannot have a hierarchy of cells without the top level cell having responsibility of the whole world below in its own scope: that doesn't scale well and limits complexity to maybe a couple of levels.
EDIT: Whoops, it's pretty trivial to nest components and describe a tree of HTML.
FYI your website fails to load in IE11 because the `fetch` function (polyfill?) uses `Promise`
But rest assured, the library itself is 100% es5.
btw could you share the link that's not working on IE11? I will fix it right away. Would appreciate it!
Well ... actually ... there IS a way, but this feature is only mentioned one-third of the way into the tutorial – a tutorial that begins with the words “you don't even need to read this tutorial”. So, to someone evaluating Cell, it might as well not exist.
That’s a hint, by the way. :-)
Interesting concept nonetheless
Thanks for making this, I'm interested to check it out.
The inspiration was from real life cells. It's amazing how small autonomous cells bind and interact with one another to form a complex organism.
Cells have genotypes which manifest themselves into phenotypes. And a nucleus that self-controls the cell cycle.
I thought by creating a completely autonomous structure that mimics how cells work it will be possible to create complexity from simplicity.
i hear a lot of people saying this will never scale because it doesn't look like react or angular, but I think the point is not about what's missing, but what you can do with these by combining these self aware elements. I believe this approach is much more scalable because it builds on top of simplicity.
Again, thanks for the comment!
Hope this helps!
I thought one of the advantages of React/Angular/Vue frameworks is their support for event modifiers, cross-browser support for the events via synthetic events. Or is there a support for these ideas that I am missing.
But I fail to see which problem this tries to solve or which novel solution it illustrates. It looks a lot like React without JSX (which is not bad).
How it has a different architecture: https://github.com/intercellular/cell#so-how-does-it-work-ex...
What these architectural decisions mean and how they make a difference https://github.com/intercellular/cell#how-does-this-make-a-d...
And when you come from that direction, Cell is a terrible framework that doesn't follow any best practices and does things in a weird way. But the thing is, Cell is fundamentally different from other approaches. That's why a lot of "best practices" don't apply and don't make sense for Cell.
If you go back in history, people hated angular because it went against the general wisdom of "separate view from logic", and react was shunned because it had some weird way of doing things. But I think they solve problems in unique ways that make peoples lives easier in different ways, and that's what matters at the end of the day.
And I am confident that Cell can make people's lives significantly easier in another different way. So I suggest you actually play around with the examples at https://play.celljs.org
Words don't mean anything really because the problem we're trying to solve is come up with a dead simple easy way to build web apps, which is not really easy to grasp when just thinking about theories. Hope this helps!
I'm using some in-house library I built myself to run the webpage but hadn't realized it fails on an IE. Will fix it!
For some reason this made me think of clojurescript, and I think it might make a nice library for use in cljs as well.
Question for the author: I'm a firm believer that, the more a tool is really good at some things, the more that tool is not good for other things. (A really good drill is also really not good at being a hammer.)
It looks like Cell is really new and interesting and does some things really well; what things does it not do really well, or would you recommend to not use it for (as compared to other frameworks?)
And this is by design because the goal was to create complexity out of simplicity.
I believe this bottom up approach can be much more scalable in the long run than some frameworks that dictate every single detail you need to implement, because all organisms are basically built that way (cells make up body) and they seem to be working fine.
Personally the more I use this the more I find creative ways of using it, which is the beauty.
But I also do realize sometimes it's good to have some sort of "best practice" structure and I think people will figure it out eventually.
TLDR: I think you should be able to build all kinds of sophisticated apps with it because I believe emergence is the best way to construct something. if that's not the case, that doesn't mean the framework is a failure but just needs some tuning, which I believe is totally possible just because the library is so minimal. So please feel free to play with it and share if you run into trouble, we can evolve cell just like cells evolve in the real world.
Can you walk an extra mile and implement your version for https://github.com/gothinkster/realworld & https://github.com/tastejs/hacker-news-pwas.
This helps to benchmark how intuitive is the framework for creating complex apps.
Maybe I'm sitting here saying something that sounds like "get off my lawn" to everyone else in the thread, but this thing is amazing.
That alone changes everything about JS.
compare to something like https://github.com/yoshuawuyts/choo which is actually tiny and simple
React is not an ecosystem. React is a library with an extremely simple API. Everyone acts like one must use a flux implementation, a complicated router and everything when you use React. It can't be farther from the truth. Out of the box, React also provides, more or less, whatever cell provides.
(True; staticly typed isnt the same as not declared, but still, i think you get my point.)
This is literally a self-contained file...
It's easy to write a basic web app in one .html file with whatever JS you need inside <script> tags.
While I understand that 2-way binding might complicate everything, it is the one feature I need the most when setting up a quick-and-dirty prototype. IMHO this might be the deal-breaker...