Hacker News Reader

Comment by k__ | Hacker News Reader

While I personally prefer React 90% of the time, I would say with its deep RxJS integration Angular has its merits. Sure, it's miles away from Cycle.js, but Angular has a much bigger eco-system.

If I would create a (realtime) data intensive app, I would probably use Angular for it.

View on HN

Maybe every example I've seen of RxJS is doing it wrong, but I've not seen a usage of RxJS that wasn't:

a) Over-engineered and an entirely unnecessary level of abstraction and flow control for a web app

and

b) A total spaghetti mess of event handling code all over the place and no way to tell what the flow of events is and always having to hunt down difficult to debug issues as a result.

RxJS may be neat, but it's definitely architecture astronaut territory.

I'm sold on the "reactive stream" pattern, and I evangelized RxJS until I discovered cleaner libraries that accomplish much the same thing. Flyd[0] is my current library preference for JS. RxJS just has so many more abstractions than you need to do the job, and it doesn't make it very easy to incorporate whatever your own functional paradigm might be even though you would expect it to excel at this...It forces RxJS conformity, instead of being "just a function" that can itself be easily composed.

(I also think async generator functions are a great tool for reactivity that are underused)

Anyway, there's a huge amount of extra language that you need to develop around RxJS...at first I didn't mind because I thought I was getting multi-language benefits: "Oh! Reactive Extensions are available in a variety of different languages! Sweet!" But the specific patterns and terms learned in one implementation tend to be vastly different than in others. Sure, you're still working with the same patterns at a high level, but don't expect any of the same methods to be present or even the same basic syntax, even if the languages are similar.

[0] - https://github.com/paldepind/flyd

> Sure, it's miles away from Cycle.js

Has cycle got any real-world adoption, apart from Andre writing the Manyverse client in it?

At least 24 companies are sponsoring the development, don't know how high the dark figures are.

But as I wrote in the comment before, while Cycle.js is in my eye the cleaner UI framework implementation with observables (compared to Angular) it has a very small eco-system.

> At least 24 companies are sponsoring the development

Is there development though? It looks like since 2018 there have been only minor updates, and major projects like [1] are still just a dream.

On the other hand, "sponsoring the development" could be a strong word. Giving a few bucks every once in a while isn't really sponsorship [2]

[1] https://github.com/cyclejs/cyclejs/issues/851

[2] https://staltz.com/software-below-the-poverty-line.html

> very small eco-system

With comprehensive frameworks, I always think of this as the Smalltalk problem.

In real world use, aggregate framework dev-hours typically trump superior architecture. Sadly.

I used Cycle for a couple years, but the size of the React ecosystem made it much easier to just use React. There were prototypes of embedding React components in Cycle Apps, but more traction was made in embedding Cycle components in React apps, but by this point it rarely seems worth the effort to mix the component types together. (And with hooks eliminating whole sorts of reactivity issues with class components, I don't really miss Cycle much in React work. Though I miss Cycle a great deal when working in Angular, yikes.)

> I would say with its deep RxJS integration Angular has its merits

That’s funny, because for the exact same reason I’ve taken a strong dislike on it.

The rest of NodeJS flows on promises and constantly have to switch between that, and having to use different APIs, and no longer be able to write simple awaitable async code...

It drove me mad. Angular without RxJS would be so much better.

Strongly disagree. Rxjs is such a better async pattern than anything else in the javascript ecosystem. The front end shouldn't care what node is doing, especially since not everyone's front end uses node. What I don't like about async await is it changes the pattern you are seeing, intermingling synchronous and asynchronous code based on the correct placement of a keyword, then using try catch blocks to catch errors are just so ugly. Passing my data through a stream of pure functions that transform the data into what I need just feels pleasant to work with, but I do agree it takes awhile to be proficient in it.

Use NestJS, you can have RxJS and Angular in your backend

Doesn't Node.js mainly flow on callbacks?

As far as my experience goes, promises require some extra work too.

Reply on news.ycombinator.com