It is illogical for the content to come out as garbled text in the event of a bug. The more likely bug would have the wrong content being rendered by the view library.

Modern view libraries (React is probably the most well-known, but there are dozens of them) in and of themselves just render out the current state of the content they're given.

The error could be on the backend (wrong data being returned) or frontend (explained below)

As efforts such as GraphQL and others are still not super widely used technologies, this state is often built up and cached from the API return values from multiple endpoints. You might have an API endpoint for a video, you might have one to get user information, you might have one for comments and one for replies. Etc. Ultimately, these are built up together, processed, and cached for the frontend and the view library renders the content the instant it has changed. (this is why you saw the content change about the time you would expect the API return value to come in)

This data from these APIs often come in multiple nested formats, sometimes with references to other data. This can be very complicated and is not always a super simple problem. See here for example.

https://tonyhb.gitbooks.io/redux-without-profanity/content/normalizer.html

It is very easy to see how there might have been an off by one error or something else where an API value was processed wrong and the IDs were mangled and the wrong text was rendered in the box. Or maybe in some loop, some value wasn't being cleared. That would cause the same issue too. A bug could not cause the content to be garbled. At worst you'd see something like an empty box if the content couldn't be found.

I'm not trying to carry water for Google or YouTube. I'd love to clearly catch them in an act of outright censorship and fucking bury them. But I know this field, and it seems almost certain that this is what the user noticed based on my knowledge.

Please note that I'm not saying this definitively. I don't know what happened in this specific case. I just gave a description of how modern web apps typically work.

Your first two paragraphs describe what I said happens, not what you said happens.

No, I gave a further description of what I've been saying all along. It's not my fault if you didn't understand it.

Why. It already updated client side.

The backend, not the many frontends that consume the backend's content, is the ultimate arbiter of application state. Because the state of some type of data changed and the request is happening anyway, that's viewed as a good time to update the state in some types of applications because a request is happening anyway.

There are many ways to handle the timing of updating web content. You can poll periodically. You can piggyback off of some other requests (what I described and what you seem to view as incomprehensible). You can use web sockets and other techniques for real-time updating. You can just wait for a page refresh.

What's backing the assumption that something changed between when you hit "submit" and when the server processed that request?

2 simple points.

1. In a popular application, some types of state can indeed change in a few seconds until the server responds.
2. But, we're not necessarily talking about that brief time window, but about the time window between arriving at a page and fetching the list of comments, watching a video, writing a comment, and submitting. The comments might be loaded when you arrive at that URL, but might not be refreshed until you submit a new comment. Again, it depends on application design. Doing it this way might or might not make sense for some Apps, for some API requests.

APIs return different types of data depending on App design. Some APIs might want to keep things very simple and basically just return a 201 response code for some types of POST requests. Some APIs might want to make things more elaborate and also return the current state of some type of data. There's a bunch of valid ways to do it.

Furthermore, why would refreshing the document be bundled in with post requests?

Answered above.

That removes the ability do to things like make a bunch of post requests, and then poll once to update the page instead of updating the page after each of fifty post requests.

It doesn't remove the ability to make a bunch of POST requests. There's nothing stopping you from making as you want. Your argument might be closer to valid if you said something like "It might be inefficient and hit the backend too hard to fetch all of the data and send that back to user on every post request." However, that is not the case in many applications.

1. Caching is a thing.
2. Certain API actions, such as a user posting a comment, are not typically going to happen in a rapid fire series. One way to design an application is you might update the application state when a user makes a comment, but might not do the same thing when more common POST requests like upvotes/downvotes are done. Again, there's a 100 ways to design an App and API based on the specific problem domain. Not all API requests in an App have to return state. Some might just need to return a success message. This is a valid way of designing an API.
3. Many APIs have rate limiting and other functionality to protect them on top of that.

This is still extremely stupid. A comment has text, a username, and an avatar. All of those things are contained in a single data structure some people like to call an "object". Is the code pulling the text in a completely different way than it's getting the username and avatar? Is it not fetching a comment from an array and then just pulling member variables for the comment.text, comment.username, and comment.avatar ? Are they just running getComment(lol_idk_whichever).text ?

You kind of make a point here, but every programmer has created some bugs. Maybe the bug was in the frontend, maybe in the backend. Maybe the view library they use fucked up somewhere. It's easy to say "this shouldn't happen" when bugs are common in any software.

Your appeal to authority busted. We can write this off as a big clumsy error by a programmer at one of the biggest tech companies in the world, not caught by anyone in the release process including their QA team, and yet YOU are some infallible authority on what's happening in code you can't even see? Because you can make guesses based on how you think "most apps work something like this"?

I didn't make any absolute claim about YouTube in this instance. I described how a typical modern Application works and what the likely issue was. I can see this based on my experience as well as observing the timing of the video. The UI updated optimistically, but the comment changed in about the time that it would take for it to hit the backend and receive the response. Just seeing that alone is a huge clue about what happened.

Okay pal that guarantee and a dollar will buy you fifty cents.

It's clear you have some type of technology knowledge, but I don't think you have quite as much experience in how modern web apps generally work.

Do you have a different logical explanation for what's observed in the video? I've made my case. What's your explanation?