[austin-cheney]

* State management is one of the most simple problems to solve in any application.

* WebSockets are superior to all revisions of HTTP except that HTTP is sessionless. Typically when developers argue against WebSockets it’s because they cannot program.

* Your software isn’t fast. Not ever, unless you have numbers for comparison.

* Things like jquery, React, Spring, Rails, and so forth do not exist to create superior software. They exist to help businesses hire unqualified developers.

* If you want to be a 10x developer just don’t repeat the mistakes other people commonly repeat. Programming mastery is not required and follows from your 10x solutions.

* I find it dreadfully hypocritical that people complain about AI in the interview process and simultaneously dismiss the idea of requiring licensing for professional software practice.

[solardev]

> WebSockets are superior to all revisions of HTTP except that HTTP is sessionless. Typically when developers argue against WebSockets it’s because they cannot program.

What did you mean by this? Were you suggesting that interactive web apps should maintain a persistent and stateful connection to the server and use that to send interaction events and receive the outputs back, like a video game would, rather than using stateless HTTP calls and cookies and such? Why is that superior?

And sorry if I misunderstood!

[austin-cheney]

> Were you suggesting that interactive web apps should maintain a persistent and stateful connection to the server and use that to send interaction events and receive the outputs back, like a video game would

That is how I design all my web facing applications now. The idea is that with WebSockets all messaging is fire and forget and that is independently true from both sides of the wire. That means everything is event oriented on each side separately and nothing waits on round trips, polling, or other complexity. In my largest application when I converted everything from HTTP to WebSocket messaging I gained an instant 8x performance boost and dramatically lower the architectural complexity of the application.

[solardev]

That's fascinating. You should do a writeup about it!

I had thought (perhaps incorrectly? it's not something I've spent a lot of time pondering) that a stateful connection like this is fragile in the real world compared to HTTP because it requires some sort of manual reconnection to the server on network changes (like if you're on a phone in a train or in a car), and that it would require both the server and app itself to be aware of what is dynamic realtime data, what is cacheable, what is stale, etc. Like kinda related to your other statement about state... doesn't this mean you're sharing and syncing state across both the server and the client?

Competitive video games operating over UDP are the closest everyday analogy I can think of, where the server handles most state (and is the ultimate source of truth) but the client optimistically approximates some stuff (like player movement and aiming), which usually works fine but can lead to rubber-banding issues and such if some packets are missed. But most gaming happens between one server and just a small handful of clients (maybe 100 or 200 at most?).

In a web app, would the same sort of setup lead to UI jank, like optimistic updates often flicking and back and forth, etc.? I suppose that's not inherent to either HTTP or websockets, though, just depends on how it's coded and how resilient it is to network glitches.

And how would this scale... you can't easily CDN a websockets app, right, or use serverless to handle writes? You'd have to have a persistent stateful backend of some sort?

One of the things I like about the usual way we do HTTP is that it can batch a bunch of updates into a single call and send that as one single atomic request that succeeds or fails in its entirety (vs an ongoing stream), and it doesn't really matter if that request was one second or one minute after the previous one as long as the server still knows the session it was a part of. Like on both the client and the server, the state could be "eventually" consistent as opposed to requiring a stable, real-time sync between the two?

Not disagreeing with you per se (hope it didn't sound that way), just thinking out loud and wondering how the details play out in a setup like this. I'm definitely intrigued!

[austin-cheney]

It is the same level of fragility compared to HTTP because most HTTP connections now are stateless keep-alive connections. The solution to this fragility is to open a new connection after the prior connection breaks. You will know when the WebSocket connection breaks in both the browser and Node because there is an event exactly for that. That new connection request can occur via timed intervals or as needed at next message, depending upon concerns of directionality and urgency.

Transmission is not a function of state. Your application gains greater durability when those two qualities become fully independent of each other.

Transmission jank is a concern for web servers that come down and then back up with restoration of many concurrent connections. The solution to that is stagger connection establishment in batches and intervals. This is not a normal operating concern though, because how often does your web server crash on you in production if you have 10,000 or more active connections.

As for CDNs leave static asset requests to HTTP. For performance these files should be consolidated to the fewest number of requests balanced against initial rendering concerns in the browser. This should also typically be limited to initial page request.

[dandelion9]

WebSockets are often blocked by corporate firewalls/proxies, I don't think it's as simple as saying WebSocket > HTTP

[austin-cheney]

To solve for that you can serve WebSockets on the same port as HTTP. Most web server application's don't know how to configure that, but I know it can be done because I doing it right now in my own applications.