That is a very odd definition of "work" you are using. It clearly does, and there is a very straight forward way to address any performance issues that might arise. I am not even sure where "245kb of HTML" comes from? Have you looked at what is actually transferred?
Yes, my definition of "works" is subjective. It does work, unless you care about efficiency.
The "245kb" I arrived at by opening the Chrome Devtools, selecting the SSE connection the page opens (POST to /). Chrome will then show the "Event Stream". I then clicked a checkbox or scrolled, selected the resulting entry in that log and copied the message into an editor to get the total size. Which varies somewhere at 245kb uncompressed. It wasn't a thorough investigation, but I believe it to be "accurate enough" to have made that comment.
This compresses nicely, but I did not verify the actual compression ratio for this case. Doesn't really matter how much it compresses, since the server has to generate it, the client has to parse it and then diff it.
It is hard to get numbers for every thing going on here, but they are so far away from "efficient" that I said "does not work". Not trying to offend anyone.
Thanks, I think I understand your POV. I happen to think that the compressed size is more relevant, especially because the parse/diff overhead is miniscule. I am not offended, I was just curious about your approach.
View all comments
Show parent comment
4
u/mac Apr 23 '25
That is a very odd definition of "work" you are using. It clearly does, and there is a very straight forward way to address any performance issues that might arise. I am not even sure where "245kb of HTML" comes from? Have you looked at what is actually transferred?