Cycle components decouple abstraction from implementation

gistfile1.md

Cycle custom elements decouple the component's abstraction from its implementation.

When you use a React component like

<div>
  <NewHotness />
</div>

You are pulling in that specific NewHotness component. You actually had to explicity import the NewHotness component before using it.

But if you use a Cycle component like

h('div', [
  h('x-new-hotness')
])

You are not including or importing a specific implementation of the new hotness component in this context, because you can separately specify the implementation for 'x-new-hotness' later (think of a Map from tagnames to implementations). So you can easily swap the implementation of 'new hotness' later on using

Cycle.registerCustomElement('x-new-hotness', MyImplementationDataFlowNode);

Or if you include a web component that is named x-new-hotness, then just remove that registerCustomElement call and the end result with use the web component <x-new-hotness> that you imported in the HTML.

Conclusion: you can code with components just with their abstractions, allowing true semantic HTML everywhere, and replaceable implementations however you wish. Not true for React.

Wouldn't you just change whatever is in require() in the React case? So if I wanted a web component I would just change the module.exports in that file to be a web component?

@natew that means the component changed only in that module where it was require()d.
If I use NewHotness in both modules A and B and I want to change its implementation, I need to change both require() in A and in B.

In essence, it's the bridge pattern: https://en.wikipedia.org/wiki/Bridge_pattern

Could you show a more complete example?

If I change the module.exports in NewHotness, then A and B both get the new version. I can see how with React it's expected to be one way, but I guess you could wrap React around some web-component, so yes, you would change both.