Their homepage is... interesting, to say the least. [0]

[0] https://rxjs-dev.firebaseapp.com/

Went to one of the conferences for rxjs.

Some young woman was on stage demanding that all males need to apologize to women in tech. There were other incidents.

Not a community I want to be involved in.

You are describing a typical atmosphere in the frontend and node community in general. You might find this account from several conferences in 2018-2019 amusing [0]. RxJS is in no way an outlier in this regard.

[0] https://docs.google.com/document/d/1g4oh2GGZOsucZfT1YJ5wjDUS...

How so?

First of all, who does center alignment?? Looks tacky and amateurish. This isn't a flyer for your yard sale, it's a professional company's website.

Secondly, it's great that they're involved and passionate on social justice issues, however I wouldn't lead with that as the landing page gives no idea what the company actually does, offers, or makes.

Thirdly, when you click over to their team, it should identify their role instead of just letting you click to their socials.

^ just my quick first impressions!

>>> is what happens when a Jenga tower makes love with a Rube Goldberg machine.

And the Award for Metaphor of the week goes to ...

Oh crude. Had one jQuery Developer be replaced with two 5 man teams so we could Use RXJS. Took a year for the first feature to be released. Not product, just a new page on the app.

Developers first introduced to RxJS hate the fact they have to think about the plumbing rather than the water... that is until they have to inner join 3 asynchronous sources of data and broadcast it out to their entire application.

Is this really a problem? Async/await makes async simple, and using a store like zustand gives you hooks and [g/s]etters out of the box.

Nothing wrong with Async/Await and zustand, the thing is that it doesn't maintain complexity as more sources are added, let me try to give you an example of the problem that Async/await solves versus what RxJS solves.

Say I'm installing a toilet, I need to go out and buy one from the hardware store, remove the old toilet, install the new one, and finally test that it works. It's a linear process that could easily be constructed via a series of async/awaits, and I wouldn't use RxJS to model the behavior.

Now, say I'm building a bathroom. You have a shower head, a sink, a toilet, light fixtures, power outlets, tiling, a door, and a window. You have a bunch of contractors. Now you're dealing with N number of sources, N number of tasks that can possibly done in parallel, and N number of possible things you could do in that bathroom depending on how much the bathroom is finished (for instance, if just the plumbing, floor and sink are complete, I can wash my hands)

This was always a hard problem, and not one that is especially appreciated, but I can tell you from experience that attempting to just use promises or async/await is not a scalable pattern.

Isn't the idea that if you edit something I'm looking at it would be nice if my view could automatically update? (FWIW, I would totally accept that I don't need that on a bug tracker and I probably am actually happier without it, but I can at least see the premise being interesting... being able to see point changes or user votes or comments as they happen; I do appreciate the extent to which GitHub's issue tracker automatically updates).

As a heavy Jira user, I absolutely want my screen to update when someone else updates a ticket. That doesn't actually happen, though.

Might be missing something, but how is this related? Is the assumption that this is what RxJS gives you? Because I mean...that's a websocket. And how you model the event, and handle it...is up to you. Don't need any library to help you unless you want one.