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.

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