This is interesting feedback. There are obviously subjective parts in it, but that's valuable all the same.

Focusing on the objective parts :

An observable is powerful abstraction, as it allows event streams to be programmable. However, an overreached abstraction can be even worse than a lack of abstraction. Cycle.js gratuitously applies the observable abstraction to its component model.

Some caveats aside, cyclejs allows you :

- to express your app as a series of equations

- separate side-effects from pure dataflow processing

Whether that is gratuitous or overreached is a question of taste, familiarity and other things, I won't discuss with you on that.

What I will say is that under some conditions, the cyclejs approach actually can make your application much easier to understand that standard imperative workflow processing. For instance, I could write for a super simplified reservation system :

- screen `=def=` booking_details_screen + booking_feedback_screen

- booking_feedback_screen `=def=` is_ok(booking_response) ? nothing : display_errors(booking_feedback_screen)

- booking_details_screen `=def=` whatever interface you want

- book_button_click `<-read_dom_effect-` = <provided by the DOM>

- flight `=def=` read_flight (booking_details_screen)

- booking_request `=def=` makeBookingRequest(flight) sampled by book_button_click

- booking_response `<-booking_effect-` booking_request

The `=def=` relations are equations which are always true. the `<-effect-` relations express the causal relation between asking for a request to be performed and the response resulting from that request.

On another note, as you can see from the equations, there is no notions of component. Or if you prefer a component is a variable on the leftside of the equations. So for instance screen is a component with two children components.

That is the underlying theory. In practice:

- code does not get written as a list of equations, but through doing some juggling with streams operators. Nothing of the other world really, but there is certainly a ceremony to it, and tips, tricks, gotchas to be aware of.

- Cycle actually does not have a component model stricto sensu. A component model should at least provide a systematic way to combine components into a hierarchy, i.e. a `combine` function by which `parentComponent` = combine(childrenComponents)`. For instance in React, `reactElement = React.createElement(parentComponent, props, childrenComponents)`.
With `cyclejs` you must explicitly write your `combine` function yourself, everytime. That represent probably a portion of the pain you felt.

But conversely look at the other approach. Let's imagine a `ParentComponent` with two child components. To reason about your application, you need to know about the end-to-end sequence of operations involved in all the framework's API. So for instance: `render = render Parent -then-> call onRender of Parent -then-> render Child1 -then-> fetch data -then-> render Child2 -then-> etc.`. This is obviously possible, that is how React works and your own proposed framework too - by the way you do not offer a component model either, stricto sensu). Nothing of the other world really, but there is certainly a ceremony to it, and tips, tricks, gotchas to be aware of (yes I copy pasted from before).

So in short, your evaluation of how bad the ceremony is, the effort it involves etc. will obviously include factors which are specific to you. So I am not doubting your feedback. My whole point here is to say that your mileage may vary and that there is no a priori superiority of one approach over another (stuff like `realizing the appropriate abstraction` as you mention in your post). There are real pain points both ways and what is appropriate to you might be in part the result of a higher familiarity with one approach over another.

If you want to understand what I mean by component model, or want to see what a component model for cyclejs look like, I created my cyclejs component model to address some of the pain points you probably encountered : cf. https://brucou.github.io/posts/a-componentization-framework-...