The points mentioned against websockets are mostly fud, I've used websockets in production for a very heavy global data streaming application, and I would respond the following to the "upsides" of not using websockets:

> Observability Remains Unchanged

Actually it doesn't, many standard interesting metrics will break because long-polling is not a standard request either.

> Authentication Simplicity

Sure, auth is different than with http, but not more difficult. You can easily pass a token.

> Infrastructure Compatibility

I'm sure you can find firewalls out there where websockets are blocked, however for my use case I have never seen this reported. I think this is outdated, for sure you don't need "special proxy configurations or complex infrastructure setups".

> Operational Simplicity

Restarts will drop any persistent connection, state can be both or neither in WS or in LP, it doesn't matter what you use.

> Client implementation

It mentions "no special WebSocket libraries needed" and also "It works with any HTTP client". Guess what, websockets will work with any websocket client! Who knew!

Finally, in the conclusion:

> For us, staying close to the metal with a simple HTTP long polling implementation was the right choice

Calling simple HTTP long polling "close to the metal" in comparison to websockets is weird. I wouldn't be surprised if websockets scale much better and give much more control depending on the type of data, but that's besides the point. If you want to use long polling because you prefer it, go ahead. Its a great way to stick to request/response style semantics that web devs are familiar with. Its not necessary to regurgitate a bunch of random hearsay arguments that may influence people in the wrong way.

Try to actually leave the reader with some notion of when to use long polling vs when to use websockets, not a post-hoc justification of your decision based on generalized arguments that do not apply.