עוד סיפור זוועה על RxJS. אחד המנטיינרים של RxJS יצר פריימוורק שנקרא CycleJS שכולו מבוסס Multicast Observables. ראיתי את העתיד והוא לא היה משהו

looks cool! @cyclejs vibes

There are some talks about CycleJS lately, and I must point to its 2 major flaws: 1. "You don't need to think about async with streams", only that with UI, you must. In user interaction, it's the most meaningful thing to the user. [1/2]

CycleJS was the most amazing innovation in frontend since React, but sadly, it never took off… - rxjs-based: app (DOM, HTTP, state) is a stream, with no explicit state management - a single main function maps input streams (e.g. user events) to output streams (e.g. UI, effects) - side effects are declarative, managed via "drivers" that integrate with the reactive loop

These are not just performance issues. It's confusing and there are all kinds of unexpected consequences from firing redundant events for everything. I knew way back in 2017 that RxJS alone was a stupid idea. CycleJS ran into the same issues. Everyone does. It's so obvious.

Yes, this was a common gotcha. The stream pipeline is usually written in a way that doesn't start by specifying the initial value, so developers often saw nothing show up. But it doesn't take long to learn to always provide an initial value

same as you, i've looked at code but haven't built anything with it i wasn't a big fan of the use of string selectors for stuff like http requests and dom events. also i think we don't need to push side effects out of the components into drivers anymore

I've looked over code written in CycleJS but haven't used it extensively. @devagrawal09 how much have you used it? The concern I had was prop-drilling & premature code use vs lazy shared state. I also don't personally think components need to be pure (async isn't pure anyway), just that there should be one single declaration for everything.

Cc @mfpears

Would love to connect with people that are / were using @cyclejs extensively. Trying to understand what works and what doesn't -on the high architectural level. Who would be a good person to talk to?

I’d be really interested in coming up with some code examples for each level Find a complex use case that can demonstrate the benefits gained at each level and write code going from vanilla imperative js to cyclejs style pure reactivity

i've been thinking of ways to get to level 6, but i don't want to rely on string selectors for dom events, i want as much as possible to happen through direct references. one of my complaints about cyclejs is strings to reference dom and http events

i'll elaborate: all credit goes to @andrestaltz for building cyclejs and for giving so many awesome talks evangelizing this way of building apps, both of which were seminal to my work on solid-events

Okay prize money aside, building this has been a very rewarding experience. I joined the team that build the Strello demo a while ago, spent a decent amount of time trying to understand Ryan's vision of fine grained optimistic updates, and finding a way to implement it. At the same time, I have been looking at other kinds of Reactivity, notably Cyclejs and it's architecture of events flowing down the graph along with data, and finding a way to implement it. At some point it clicked for me that these two explorations converge nicely. What's missing from optimistic UI implementations is not more mutable reactivity, but a way to explicitly model those mutations reactively rather implicitly using timestamps. What better way to explicitly model a mutation than an event?

なんかうまくいってれば大半の人は良くて、一部のそれ以上を求める人向けのfp-tsだのcyclejsと考えると、まあ確かにそうかぁという気持ちになりました

i'd love to see a sample app built with react, solid/angular, and cyclejs, and compare side by side

Web development will move to reactivity one amazing tool at a time. More #Angular devs should give #React a try. Angular is headed in a MUCH better direction than React is, imo, but that is partly because they are taking inspiration from other frameworks. The vast majority of garbage code in web apps is large components whose parts are tied together with imperative code. React gets the 2 most important things more right than any other framework: ## 1. Frictionless Component Creation Sections of code can be split into child components almost as easily as thinking about it: ## 2. Minimal, Declarative Derived State Synchronously derived state can be expressed as if JavaScript were a reactive language. ## Optimizing for Hello World These are amazing examples, but sharing state, scaling with complexity, and maintaining performance along the way are all painful in React. But React developers are aware of these pains because they see clear examples of how nice code can be. The contrast between painless simple code and painful complex code is very high. The simple code engrains a mindset for small, composable pieces of code, and for declarative derived state, which prepares them for the next level of reactivity. This is part of why React Query grew so quickly. It allowed React devs to code simple async state in the same style they had been coding simple sync state. It was easy for them to see the benefits. ## Trading for Scalable Reactivity But once the reactive mindset firmly sets in, devs are willing to trade off a tiny amount of syntactic sugar for MUCH greater flexibility, scalability and performance. Most of #SolidJS' biggest fans are React developers: Not quite as nice, is it? But developers who understand reactivity love it. This is how I see reactivity spreading up the layers of web applications. Rather than a completely novel, 100% reactive framework like CycleJS, I see developers adopting a single, simple, extremely convenient tool for each incremental layer of complexity. Developers fall in love with the "Hello World"-like demos, the reactive mindset seeps deeper into their brains, and then they get ambushed when the tool explodes in their faces at the next level of complexity. Then, someone creates the next great tool. This process is probably for the better. RxJS is more general than TanStack Query, but it is mediocre for HTTP requests, which is where the vast majority of asynchronous data comes from. Seems like more focus should have been given to it, doesn't it? And maybe it's currently more important overall to figure out this SSR stuff everyone seems to be struggling with. ## StateAdapt As for me, I like living somewhere in the middle. I do love promoting simple tools that nudge developers towards reactivity, like Angular Query. That's more appealing to me than the pure idealism of something like CycleJS, which, however good it is, is a hard sell for most developers who have to use a major framework. But I've found that StateAdapt is right in the sweet spot: reactive enough to be exciting (about 90%), and yet easy to adopt within existing frameworks.

In CycleJS: drivers wrap an imperative API so it feels more declarative on the client code side. However, the API itself stays imperative, behind the giant if-else “command dispatcher”. We can push the imperative complexity out of the core, but it lives in extra layers then.

StateAdapt and CycleJS are the only ways I know of to fulfill the original intentions of OOP in FE development. Modern OOP doctrines tend to be unthinking parroting of bad interpretations, probably passed down in CS classes. The imperative mindset is pervasive, but won't be.

考え方としてはcyclejsがかなり理想(もうメンテされてなさそうだけど)