Make a comparison with native browser WebComponents

[Danny-Engelman]

Can you list the differences with (almost) native Browser WebComponents?

Seems to me (at the moment) you created a very lightweight Polymer.

[Caffeinix]

As someone who uses both Cell and Polymer, I might be able to help here. There are some similarities, certainly, but there are also some crucial differences. Those include:

• Cell doesn't use Shadow DOM, so styles, IDs, and other such things are not scoped to a cell as they are scoped to a web component.
• With web components, there are two stages to component loading: first the component's constructor or associated ES6 class must be registered using document.registerElement, and then the component is instantiated when the appropriate tag is parsed in the DOM. With Cell, all of the work happens once on load (except for if $update gets called). This means that dynamically added elements won't be cells by default, whereas dynamically added web components work just fine.
• The web components spec doesn't have any kind of support for data members or dynamic update. Polymer does, but it also adds one-way and two-way bindings, computed properties, templates with conditionals and repeated elements, and lots of other useful but heavyweight stuff. Cell provides $update and a simple diff algorithm to make minimal DOM changes when you regenerate subcomponents, and lets you deal with all the rest using pure JavaScript.

[ghost]

oh, many thanks @Caffeinix, what you say is also my care. and more options? @gliechtenstein

[gliechtenstein]

Thanks for the great explanation @Caffeinix

I think he covered most of the details, so will just go ahead and add a bit of my own comments.

1. I believe web components is the future, it's just not here yet. Which means, I think once web components gains traction all the popular web frameworks nowadays will look like what coffeescript looks like in 2017. (No offense to coffeescript, I used to use it a lot but the point is most of what made coffeescript interesting have been incorporated into ES6)
2. That said, this "it's not here yet" is important IMO. Projects like polymer try to emulate web components as much as possible but as a consequence becomes complicated. Also it's not yet clear what part of the proposed spec will end up being integrated into all browsers. For example one of the features I find really cool--html import--will not be integrated into Firefox (as they say), which I think is a very bad idea. I think they are assuming that ES6 will solve everything but I do see a lot of potentially huge benefits of supporting HTML imports independent from ES6 modules. I hope that approaches like Cell motivate the browser vendors to rethink these decisions so we can do all the cool things without polyfills.
3. Which means, Cell is not trying to compete with web components nor polymer. It's actually supposed to blend in seamlessly into web components. You can't say this about other JS frameworks because they dictate how you should structure your entire app. Also this is different from polymer because polymer's goal is to implement web components itself, whereas Cell's goal is to build something that's 100% dependency free and 100% web standard based that it can be blended into any context with ease, which includes web components.

p.s.

Just a quick comment on this:

With Cell, all of the work happens once on load (except for if $update gets called). This means that dynamically added elements won't be cells by default, whereas dynamically added web components work just fine.

Now Cell started supporting manual instantiation https://github.com/intercellular/cell/issues/125 and I plan to make it even more flexible so Cell can be easily integrated into any context.

[ghost]

thank @Danny-Engelman for your ask my question. thank @Caffeinix and @gliechtenstein for your professional answers. thank all again.