{"slug": "rxjs", "name": "RxJS", "category": "dev-libs", "category_name": "Libraries and frameworks", "description": "", "recommenders": 4, "commenters": 7, "warners": 1, "score": 3.156, "rising": -1.31, "first": "2026-02-08", "latest": "2026-08-20", "why": "RxJS is a beast to approach at first but it's a genuinely cool library", "why_is_quote": true, "has_verdict": false, "sentiment": {"recommend": 3, "neutral": 2, "compare": 0, "warn": 2}, "spark": [0, 0, 0, 1, 0, 0, 0, 2, 0, 0, 0, 0], "listed": true, "loved": [], "caveat": "", "short_quote": "RxJS is a beast to approach at first but it's a genuinely cool library", "kind": "", "icon": true, "domain": null, "github_repo": null, "official_url": "https://rxjs.dev", "pricing": "", "aliases": ["RxJS"], "verdict": null, "praise": [{"label": "", "summary": "", "quotes": [{"id": 774397120, "item_id": 48399820, "url": "https://news.ycombinator.com/item?id=48399820", "by": "mablopoule", "date": "2026-06-04", "stance": "recommend", "quote": "RxJS is a beast to approach at first but it's a genuinely cool library", "excerpt": "Agree. RxJS is a beast to approach at first but it's a genuinely cool library, as long as you don't spread observable around when you don't actually need them. I used the same approach for a few years (pushing my http calls behind domain-specific api services that only return promise), and it's way simpler to handle. I still use RxJS, but mostly in the top-level component and/or service who orchestrate between data, ", "context": "", "use_case": "", "switched_from": "", "story": "Angular v22"}, {"id": 774394704, "item_id": 48399669, "url": "https://news.ycombinator.com/item?id=48399669", "by": "jessyco", "date": "2026-06-04", "stance": "recommend", "quote": "its a challenge to learn for those not used to the pattern but its very nice", "excerpt": "I never understood the problem with the rxjs, its a challenge to learn for those not used to the pattern but its very nice. Regardless signals is also fine, we have ways now to interop between rxjs to signal for those looking for it: https://angular.dev/api/core/rxjs-interop/toSignal Personally the http client workflow is fine. Usually lives in a service and exposes the needed values in any form we want.", "context": "", "use_case": "Reactive streams", "switched_from": "", "story": "Angular v22"}, {"id": 753442305, "item_id": 47090144, "url": "https://news.ycombinator.com/item?id=47090144", "by": "WorldMaker", "date": "2026-02-20", "stance": "recommend", "quote": "I also prefer the power of RxJS over signals", "excerpt": "Personally, I'm still using JSX/TSX to template my Web Components. (I'm not using React, I'm using the non-Virtual DOM approach with Butterfloat [1], but there are other small JSX template language options like Preact and snabbdom out there as well and also other non-Virtual DOM approaches.) I like the type safety of TSX as well as the syntax highlighting. (As may be obvious with Butterfloat, I also prefer the power ", "context": "", "use_case": "", "switched_from": "", "story": "Web Components: The Framework-Free Renaissance"}, {"id": 751038544, "item_id": 46939909, "url": "https://news.ycombinator.com/item?id=46939909", "by": "hafley66", "date": "2026-02-08", "stance": "recommend", "quote": "I love rxjs but I cannot recommend it without that same calibur of tooling.", "excerpt": "RxJS vite plugin that operates in much the same way as react devtools and vite plugin, because I love rxjs but I cannot recommend it without that same calibur of tooling. Turns out you can take a lot of ideas from the react vite plugin and do a bunch of similar things. Trying to parse, model the HMR process, and storing the data as flat as possible and doing it from relation design first, has been a pleasant process.", "context": "building an RxJS vite plugin", "use_case": "reactive programming", "switched_from": "", "story": "Ask HN: What Are You Working On? (February 2026)"}]}], "caveats": [{"label": "", "summary": "", "quotes": [{"id": 774308001, "item_id": 48394250, "url": "https://news.ycombinator.com/item?id=48394250", "by": "halflife", "date": "2026-06-03", "stance": "warn", "quote": "rxjs was a bad choice for data management", "excerpt": "I partially agree, there is an overlap between signals and rxjs, however the core business is different- observables are about data manipulation, while signals are about efficient state management. Regarding angular I agree, rxjs was a bad choice for data management, and before signals arrived I abandoned rxjs in favor of mobx in my angular projects. However you could roll your own http client, we used axios, and usi", "context": "", "use_case": "Reactive data management", "switched_from": "", "story": "Angular v22"}]}], "who": [{"by": "hafley66", "context": "building an RxJS vite plugin", "url": "https://news.ycombinator.com/item?id=46939909", "date": "2026-02-08"}], "tags": [], "use_cases": ["event handling", "reactive streams", "reactive data management", "reactive programming"], "compared": [{"slug": "mobx", "name": "MobX", "co": 1, "switched_from": 0, "switched_to": 1}, {"slug": "angular", "name": "Angular", "co": 2, "switched_from": 0, "switched_to": 0}], "makers": [], "threads": [{"url": "https://news.ycombinator.com/item?id=48386463", "title": "Angular v22", "mentions": 3}, {"url": "https://news.ycombinator.com/item?id=49382152", "title": "There's no such thing as a small software team anymore", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=47473718", "title": "The Three Pillars of JavaScript Bloat", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=47085370", "title": "Web Components: The Framework-Free Renaissance", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=47029339", "title": "JavaScript-heavy approaches are not compatible with long-term performance goals", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=46937696", "title": "Ask HN: What Are You Working On? (February 2026)", "mentions": 1}], "sentiment_by_month": {"2025-11": {}, "2025-12": {}, "2026-01": {}, "2026-02": {"recommend": 1, "warn": 1}, "2026-03": {"neutral": 1}, "2026-04": {}, "2026-05": {}, "2026-06": {"warn": 1, "recommend": 2}, "2026-07": {}, "2026-08": {"neutral": 1}, "2026-09": {}, "2026-10": {}}, "quotes": [{"id": 790137217, "item_id": 49383576, "url": "https://news.ycombinator.com/item?id=49383576", "by": "mickael-kerjean", "date": "2026-08-20", "stance": "neutral", "quote": "the only library in there is rxjs", "excerpt": "Same as op, I rewrote away from react my Dropbox alternative (https://github.com/mickael-kerjean/filestash) in vanilla js a couple years back around the idea that components are plain exported functions like this: export default function component(render) { const $dom = xxxx render($dom); } example: https://github.com/mickael-kerjean/filestash/blob/master/public/assets/pages/ctrl_homepage.js the only library in there", "context": "", "use_case": "Event handling", "switched_from": "", "story": "There's no such thing as a small software team anymore"}, {"id": 774397120, "item_id": 48399820, "url": "https://news.ycombinator.com/item?id=48399820", "by": "mablopoule", "date": "2026-06-04", "stance": "recommend", "quote": "RxJS is a beast to approach at first but it's a genuinely cool library", "excerpt": "Agree. RxJS is a beast to approach at first but it's a genuinely cool library, as long as you don't spread observable around when you don't actually need them. I used the same approach for a few years (pushing my http calls behind domain-specific api services that only return promise), and it's way simpler to handle. I still use RxJS, but mostly in the top-level component and/or service who orchestrate between data, ", "context": "", "use_case": "", "switched_from": "", "story": "Angular v22"}, {"id": 774394704, "item_id": 48399669, "url": "https://news.ycombinator.com/item?id=48399669", "by": "jessyco", "date": "2026-06-04", "stance": "recommend", "quote": "its a challenge to learn for those not used to the pattern but its very nice", "excerpt": "I never understood the problem with the rxjs, its a challenge to learn for those not used to the pattern but its very nice. Regardless signals is also fine, we have ways now to interop between rxjs to signal for those looking for it: https://angular.dev/api/core/rxjs-interop/toSignal Personally the http client workflow is fine. Usually lives in a service and exposes the needed values in any form we want.", "context": "", "use_case": "Reactive streams", "switched_from": "", "story": "Angular v22"}, {"id": 774308001, "item_id": 48394250, "url": "https://news.ycombinator.com/item?id=48394250", "by": "halflife", "date": "2026-06-03", "stance": "warn", "quote": "rxjs was a bad choice for data management", "excerpt": "I partially agree, there is an overlap between signals and rxjs, however the core business is different- observables are about data manipulation, while signals are about efficient state management. Regarding angular I agree, rxjs was a bad choice for data management, and before signals arrived I abandoned rxjs in favor of mobx in my angular projects. However you could roll your own http client, we used axios, and usi", "context": "", "use_case": "Reactive data management", "switched_from": "", "story": "Angular v22"}, {"id": 759656258, "item_id": 47478516, "url": "https://news.ycombinator.com/item?id=47478516", "by": "eudamoniac", "date": "2026-03-22", "stance": "neutral", "quote": "Most things in Remeda, ramda, rxjs", "excerpt": "Most things in Remeda, ramda, rxjs, the methods in the Ruby stdlib, etc. would all be great to have. I use at least Remeda in every project when I can.", "context": "", "use_case": "", "switched_from": "", "story": "The Three Pillars of JavaScript Bloat"}, {"id": 753442305, "item_id": 47090144, "url": "https://news.ycombinator.com/item?id=47090144", "by": "WorldMaker", "date": "2026-02-20", "stance": "recommend", "quote": "I also prefer the power of RxJS over signals", "excerpt": "Personally, I'm still using JSX/TSX to template my Web Components. (I'm not using React, I'm using the non-Virtual DOM approach with Butterfloat [1], but there are other small JSX template language options like Preact and snabbdom out there as well and also other non-Virtual DOM approaches.) I like the type safety of TSX as well as the syntax highlighting. (As may be obvious with Butterfloat, I also prefer the power ", "context": "", "use_case": "", "switched_from": "", "story": "Web Components: The Framework-Free Renaissance"}, {"id": 752655168, "item_id": 47040948, "url": "https://news.ycombinator.com/item?id=47040948", "by": "WorldMaker", "date": "2026-02-16", "stance": "warn", "quote": "", "excerpt": "As with most RxJS problems the diamond dependency problem can often be fixed/solved with the right combination of even more advanced operators/combinators. Often the easiest solution is `combineLatest`, but as mention that will over-fire depending on your update patterns. Sometimes a simple `throttle` is all the backpressure fix you need on that to reduce diamond over-firing, especially in combination with a cool sch", "context": "", "use_case": "", "switched_from": "", "story": "JavaScript-heavy approaches are not compatible with long-term performance goals"}, {"id": 751038544, "item_id": 46939909, "url": "https://news.ycombinator.com/item?id=46939909", "by": "hafley66", "date": "2026-02-08", "stance": "recommend", "quote": "I love rxjs but I cannot recommend it without that same calibur of tooling.", "excerpt": "RxJS vite plugin that operates in much the same way as react devtools and vite plugin, because I love rxjs but I cannot recommend it without that same calibur of tooling. Turns out you can take a lot of ideas from the react vite plugin and do a bunch of similar things. Trying to parse, model the HMR process, and storing the data as flat as possible and doing it from relation design first, has been a pleasant process.", "context": "building an RxJS vite plugin", "use_case": "reactive programming", "switched_from": "", "story": "Ask HN: What Are You Working On? (February 2026)"}]}