@sergiim5601
Great content as always! Looking forward to more videos!
@davidmares6053
thank you, i now understand better the pieces of Rsjx working together)
@ryzott
Thanks Rainer, always very informative! I think there is a lot of functionality missing from RxJs, as I see this library is usually used when you need to do some complex logic stuff, especially asynchronous.
@dhavalv
@Rainer really great demonstration of what native observables can do. Thanks a lot for this video. I remember you posted about this in one of your NgNews. For me personally, I feel the lack of operators in native implementation (debouncing for ex) and having multicasting turned ON by default will be something of a concern. I feel it will be more suitable for applications not using RxJs by default and still need some eventing behaviour. I think native fits well in those use cases. And as you said it will interesting to see how much does RxJs adopts this native observable and will it provide some kind of interop
@hansschenker
Native Observable is based on EventTarget and can only handle EventTarget based events: Element, and its children, as well as Document and Window, are the most common event targets, but other objects can be event targets, too. For example IDBRequest, AudioNode, and AudioContext are also event targets.
@FilippoGualandi
This is a great video, thank you for the comprehensive comparison and clear presentation. I've been using RxJS in Angular since Angular V2, so I've seen both the "chainable" and "pipe" versions of it, and I don't really have a preference, from the syntax point of view. Unless you have complex scenarios, I'd say that most developers would be fine with switching to the Native Observables, since (as a rule of thumb) using browser-native APIs is usually better than using third-party APIs. However, losing the possibility to add your functions to the "pipe" will possibly be a deal breaker for some advanced scenarios, or will result in less readable code. Just curious, do you know why the design of the Native Observable APIs did not consider the "pipe" syntax?
@IcaroFelix2023
Basically now, in js write observables will become quite similar to the way we do it in c# with those methods instead of "pipe"
@alex_chugaev
They should’ve just copy and paste RxJS as is. It would make much more sense. Pipe operator in RxJS has a lot of sense actually. It allows creation and use of custom operators; functional composition in streams has better type support. Some use cases are easily implemented with functions, but impossible/difficult to implement with classes.
@antonkozak2756
Thank you, great content! How do you think RxJs will develop from now on?
@codeSurvivor
Nice, thanks Rainer! So I guess that to create new operators we would have to extend the observable class, isn't is?
@sachin.tandon
When you used lastValueFrom around the observable, why did it not return '123', why did it return '1234'? - Great video by the way!
@ahmedalsaeed5920
i think RxJs is more flexible than the native one, but nice to see it in browsers and we don't ship rxjs on our bundles
@rolandjost3823
Thanks Rainer
@Abelfubu