5 ms·

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 Ang

by k__ 6y ago

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.

josteink 6y ago
> 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.
- k__ 6y ago
  Doesn't Node.js mainly flow on callbacks? As far as my experience goes, promises require some extra work too.
- tashoecraft 6y ago
  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.
- hckrnwsthrwwy 6y ago
  Use NestJS, you can have RxJS and Angular in your backend
hobby-coder-guy 6y ago
> Sure, it's miles away from Cycle.js What do you mean?
azangru 6y ago
> Sure, it's miles away from Cycle.js Has cycle got any real-world adoption, apart from Andre writing the Manyverse client in it?
- k__ 6y ago
  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.
  - dmitriid 6y ago
    > 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 https://github.com/cyclejs/cyclejs/issues/851 [2] https://staltz.com/software-below-the-poverty-line.html https://staltz.com/software-below-the-poverty-line.html
  - ethbr0 6y ago
    > 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.
    - WorldMaker 6y ago
      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.)
deckard1 6y ago
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.
IggleSniggle 6y ago
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 https://github.com/paldepind/flyd

by k__ 6y ago

josteink 6y ago

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

k__ 6y ago
Doesn't Node.js mainly flow on callbacks? As far as my experience goes, promises require some extra work too.
tashoecraft 6y ago
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.
hckrnwsthrwwy 6y ago
Use NestJS, you can have RxJS and Angular in your backend

hobby-coder-guy 6y ago

> Sure, it's miles away from Cycle.js What do you mean?

azangru 6y ago

> Sure, it's miles away from Cycle.js Has cycle got any real-world adoption, apart from Andre writing the Manyverse client in it?

k__ 6y ago
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.
- dmitriid 6y ago
  > 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 https://github.com/cyclejs/cyclejs/issues/851 [2] https://staltz.com/software-below-the-poverty-line.html https://staltz.com/software-below-the-poverty-line.html
- ethbr0 6y ago
  > 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.
  - WorldMaker 6y ago
    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.)

deckard1 6y ago

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.

IggleSniggle 6y ago

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 https://github.com/paldepind/flyd