[hliyan]

This is how I used to do it over TCP, 20 years ago: each request message has a unique request ID which the server echoes and the client uses to match against a pending request. There is a periodic timer that checks if requests have been pending for longer than a timeout period and fails them with an error bubbled up to the application layer. We even had an incrementing sequence number in each message so that the message stream can resume after a reconnect. This was all done in C++e, and didn't require a large amount of code to implement. I was 25 years old at the time.

What the author and similar web developers consider complex, awkward or difficult gives me pause. The best case scenario is that we've democratized programming to a point where it is no longer limited to people with highly algorithmic/stateful brains. Which would be a good thing. The worst case scenario is that the software engineering discipline has lost something in terms of rigor.

[Tabular-Iceberg]

Every web browser already has a built in system for matching requests and responses and checking if requests have been pending too long. There is no need to reinvent the wheel.

The real problem with the software engineering discipline is that we are too easily distracted from solving the actual business problem by pointless architecture astronautics. At best because of boredom associated with most business problems being uninteresting, at worst to maliciously increase billable hours.

[motorest]

> The real problem with the software engineering discipline is that we are too easily distracted from solving the actual business problem by pointless architecture astronautics.

There are two pervasive themes in software engineering:

- those who do not understand the problem domain complaining that systems are too complex.

- those who understand the problem domain arguing that the system needs to be refactored to shed crude unmaintainable hacks and further support requirements it doesn't support elegantly.

Your comment is in step 1.

[Tabular-Iceberg]

Yes, but we’re just talking about making websites here. Rolling your own HTTP is overkill, you’re not Google.

[motorest]

> Yes, but we’re just talking about making websites here.

And Twitter is just a message board.

Those who do not understand the problem domain complain that systems are too complex.

[willtemperley]

There is a huge difference between guaranteeing algorithmic security of an endpoint, e.g. getting authentication correct, and anticipating every security issue that often has nothing to do with developer code. The former is possible, the latter is not. I understand the author here not wishing to deal with the websocket upgrade process - I would be surprised if there aren’t zero-days lurking there somewhere.

[prox]

I am beginning to see this increasingly. Apps that make the most basic of mistakes. Some new framework trying to fix something that was already fixed by the previous 3 frameworks. UX designs making no sense or giving errors that used to be solved. From small outfits (that’s fair) to multi billion dollar companies (you should know better) , I feel that rigor is definitely lacking.

[crabmusket]

A framework was recently posted here where the author was comparing how great their Rust-to-WASM client side state management could handle tens of thousands of records which would cause the JS version of their code to stack overflow...

...and yes, the stack overflow in the JS version was trivially fixable and then the JS version worked pretty well.