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 `
- flight `=def=` read_flight (booking_details_screen)
- booking_request `=def=` makeBookingRequest(flight) sampled by book_button_click
- booking_response `The `=def=` relations are equations which are always true. the `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-...