Despite the "extreme inefficiency", HTTP/HTML have managed to work successfully for a very long period of time (and even worked decently well on very slow hardware in the '90s).
There is actually a binary format that much of the web content is compiled into: gzip. It's remarkably effective.
I will grant that following Postel's Law means that browsers have more work to do to ensure that all kinds of "busted" stuff on the web continues to work, but I'd guess that, at this stage, that work is pretty small compared to everything else browsers are trying to do.
>here is actually a binary format that much of the web content is compiled into: gzip. It's remarkably effective.
I'm sure you realize this but gzip is a content encoding. If there was a binary html format, it could still (and should be) gzipped (or better yet 7-zipped).
I did some playing around this this and gzipped binary encoded HTML ended up around 1/4th the size a gzipped minified HTML.
Gzip doesn't give you the other advantages of the hypothetical binary format, primarily: An extremely standardized and quickly parseable format.
what "binary encoded html" did you use? I would be interested in seeing this as my initial thought would be that the both would gzip to almost exactly the same size?
So which is which? Is html the csv or the DB dump? What is this metaphor even supposed to mean? It's not as though a csv file is sufficient to serialize a database.
Actually, it would be more informative to point us at a "binary encoding", any binary encoding, that compresses smaller than the equivalent html text.
There is actually a binary format that much of the web content is compiled into: gzip. It's remarkably effective.
I will grant that following Postel's Law means that browsers have more work to do to ensure that all kinds of "busted" stuff on the web continues to work, but I'd guess that, at this stage, that work is pretty small compared to everything else browsers are trying to do.