Cell – A self-driving web app framework | Hacker News Reader

Cell – A self-driving web app framework

celljs.org

NO. DO NOT ALLOW THIS. GUYS, YOU CANNOT ALLOW THIS. What if I want to browse a site without Javascript? Will I just see an empty page? Why is page structure (for which a language already exists) being moved to a language designed to assist the language providing the page structure? What is the benefit of this aside from writing everything in a programming language as code which your users have to run, esentially making them run arbitrary code on their own computers? This is stupid. Use HTML. HTML exists for a reason. It is not pretty, I know, but at least it's used for its intended purpose. I don't want to visit $website and have to enable Javascript. Content can exist with just HTML and CSS. Enough of this hipster "Javascript is cool and awesome and amazing" crap.

EDIT: To add to this, I need to enable Javascript on celljs.org, then wait 3 SECONDS for the page to load because they use their own "not a framework" to build the page instead of just using HTML.

You're totally right, if a page is merely serving static content with hyperlinks between the pages. For many types of pages, however, that's not the goal, and using JavaScript makes sense. Think of an interactive data visualization, where nearly the entirety of the content depends on dynamic user input controlling aspects like filtering and highlighting.

There are many cases where developers use JavaScript when plain CSS and HTML would do, but there are also many pages that simply do not fit that simple model. And between those two extremes is a large space of application with a mixture of static content and interactivity. Don't focus on a single usecase and ignore the rest.

As someone building a business off of VR in the browser, I think we should always have a fallback. The systems we use for building the web--whatever they may be--should do more to encourage accessibility, rather than leave it as an "exercise for the reader", aka "afterthought". Users of these systems have a legal responsibility to make their site accessible. As framework developers, I think that we must share that responsibility, at some level.

A totally valid use case for this would be to embed a few dynamic widgets in an otherwise-static HTML page. I've been trying that pattern a bit today. It works well, and seems to be a natural fit for this kind of framework. If anything a framework that makes simple plain-HTML apps easier should be welcome news to you.

But yeah, a homepage should probably be a real HTML page with embedded widgets, even if building the whole DOM is a cool use case.

I really wish people focused more on progressive enhancement(?) since 95% of webpages would work just fine with HTML and CSS, and of those 95% only need Javascript for interacting with things.

At least let me see what the site is about, even if only a landing page, so I can see the value of enabling Javascript.

> Easy to learn: There is NO API to learn.

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:

    onkeyup: function(e){
      if(e.keyCode === 13){
        document.querySelector("#list")._add(this.value);
        this.value = "";
      }
    }

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

Here's how I understood it...

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.

I don’t know why they call it “stateless” either. It clearly isn’t. Are they confused about what the word means?

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

Depends on what you are writing.

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.

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.

That alone changes everything about JS.

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

Actually, typescript was built by a quite famous static typing advocate.

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.

compare to something like https://github.com/yoshuawuyts/choo which is actually tiny and simple

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

Honest question: what's stopping you from writing HTML and JavaScript in a simple text editor today?

It's easy to write a basic web app in one .html file with whatever JS you need inside <script> tags.

You can even do React with JSX this way (but please still build for production systems): https://gist.github.com/guscost/27736c5f0913184695492ac40fd3...

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.

But then you need php on the server, don't you?

This is literally a self-contained file...

So, this looks like it lets you write HTML using JSON instead of XML. You write out the DOM layout, specify attributes for the nodes as needed, and you can add JavaScript when necessary.

Aside from the JSON and a bit of syntactic sugar, it seems really similar to writing plain HTML - which itself was designed to be a high-level markup language for quickly specifying page layouts.

What am I missing? What's the benefit over HTML? I mean, if you want a non-framework why not just, you know, not use a framework?

Saying "no API to learn" is a bit disingenuous. The object format with its $ keys _is the API_, be it simpler or not than the average framework.

I agree. "There are only 3 rules to remember" -> "here are 6 keywords to remember" caught me as well

Interesting concept nonetheless

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:

    $text: "Buy now!!".

you have this:

    $components: ["Buy now!!"],

and instead of this:

    $components: [
      {$type: "span", $text: "Buy "},
      {$type: "em", $text: "now!!},
    ],

you have this:

    $components: [
      "Buy ",
      {$type: "em", $text: "now!!},
    ],

You'll see how to do this at the end of this section https://github.com/intercellular/tutorial#a-creating-a-simpl...

Hope this helps!

This is interesting and at the very least novel. Kudos for that.

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.

Very interesting.

I like how this seems to let application logic live as close to the UI as makes sense. That is, there's no barrier, intermediary or anything else that might drive them apart.

Of course, applications have a higher-level structure that isn't just an artifact of the framework, and I'm curious how this system would work out in real life once you start grouping/composing cells and having them communicate to implement that structure. Each cell has a pretty uniform "surface" -- that is, the properties it has and what they mean, so it should be possible to "snap" them together easily and in any configuration. I wonder if it's too flexible, in a sense, meaning you would need to be careful to use higher-level patterns to organize your cells so that your app doesn't become a messy blob of cells.

These are just thoughts after a static reading of it. I'd like to play with it and see if I can get a better feel for it.

One thing I don't like is expressing HTML in JavaScript objects. Seems like we ought to express HTML in HTML! I wonder if "cellHtml" might be a better approach to this than cellJs -- that is, where a cell is expressed in HTML (would still have init and update JavaScript functions, though) I don't know if that's workable, though.

Every day, I lament that HTML and JS don't have an S-Expression syntax.

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.

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.

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.

Again, thanks for the comment!

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.

If you are interested in following this idea even further, try Reagent in Clojurescript out. It works in the same way - it's all data.

An example:

    (let [greeting [:div {:style {:background "green"}} "hello"]]
      [:section#hi-there greeting])

Just a little bit of data!

This is interesting, but one of the key points of using a framework is handling browser inconsistencies. If I write an event handler on an element, I want it to work everywhere, without having to write it in vendor specific ways. Does cell achieve this?

Looks like what I imagine the very first draft of React to have been.

Not trying to be dismissive here, but is there any more to this than declaring the DOM and on* handlers in JSON?

Thanks for asking!

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.

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.

Thank you so much! So glad to finally run into a positive comment haha. You totally nailed it!!! You made my day :)

I'm genuinely curious, what do you see as the benefit over just writing plain HTML with inline JS?

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.

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 interesting, I love writing this kind of frameworks myself to get a better understanding of the ones I use in production.

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

I hope these are enough (They're on the homepage as well if you want a more readable version):

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

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!

I like the attitude, but how do we go about organizing a large web app around this?

Previous discussion: https://news.ycombinator.com/item?id=14527124

Why would I want this over plain HTML and JavaScript? This should be crystal clear from reading the website for a minute but this is the second time reading it, since I believe there was already a topic last week on this library, and I still don't get the value of this.

Real world examples should include at the least a TodMVC implementation so users can compare this to other choices.

I find this harder to understand and it looks like more to write than just HTML. I feel like I don't understand the use case here

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.

That’s a hint, by the way. :-)

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!

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.

If you prefer, you could set up more compatible event handlers with jQuery or whatever in the `$init` function instead of using attributes.

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

Well, it is pretty good that it is component-first, but for global store I guess you'd have to use body?

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.

Sorry about that!

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!

Cool! It's just a guess but if you are by chance counting on a promise to load content, WP needs a polyfill.

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?

I'd like to hear the author compare and contrast this with React/Hyperscript.

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.

>It's intentionally built with es5

FYI your website fails to load in IE11 because the `fetch` function (polyfill?) uses `Promise`

sorry about that, yeah i meant to add fetch polyfill but forgot to.

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!

Also, the choice to tightly couple the "real" DOM with the program state is really interesting.

What problem does this solve?

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.

I'm not sure anyone would find this simpler or more readable than React at all.

https://facebook.github.io/react/docs/hello-world.html

Surely you mean React, not React Native?

Reminds me of Ext JS.

Reply on news.ycombinator.com