Maybe.
I remember the good old days. I was hired to work on this signaling protocol called H.323. It used an interesting notation called ASN.1 with a binary encoding, capable of using a bit of data for a boolean of information. Life was good.
Then came SIP. With its “simple” text notation, it conquered the market. Everyone could just use and debug it by looking at the network. It made things so much easier for developers. So they told me. What they forgot to tell us then was how hard it is to parse text properly – especially for mere machines.
Anyway, it is now 2015. We live in a textual internet world. We use HTTP to describe our web pages. CSS to express its design and we code using JavaScript and JSON. All of these protocols are textual in nature. Our expectation is that this text that humans write (and read to debug), will be read and processed by machines.
This verbosity of text that we use over the internet is slowing us down twice:
- Text takes more space than binary information, so we end up sending more data over the network
- Computers need to work harder to parse text than they do binary
So we’ve struggled through the years to fix these issues. We minify the text, rendering it unreadable to humans. We use compression on the network, rendering it unreadable to humans over the network. We cache data. We use JIT (Just In Time) compilation on JavaScript to speed it up. We essentially lost most of the benefits of text along the way, but remained with the performance issues still.
This last year, several initiatives have been put in place that are about to change all that. To move us from a textual web into a binary one. Users won’t feel the difference. Most web developers most feel it either. But things are about to change for the better.
Here are the two initiatives that are making all the difference here.
HTTP/2
HTTP/2 is the latest and greatest in internet transport protocols. It is an official standard (RFC 7540) for almost 2 full months now.
Its main objective is to speed up the web and to remove a lot of the hacks we had to use to build web pages and run interactive websites (BOSH, Comet and CSS sprites come to mind here).
Oh – and it is binary. From the RFC:
Finally, HTTP/2 also enables more efficient processing of messages through use of binary message framing.
While the content of our web pages will remain textual and verbose (HTML), the transport protocol used to send them, with its multitude of headers, is becoming binary.
To make things “worse”, HTTP/2 is about to encrypt everything by default, simply because the browsers who implemented it so far (Chrome and Firefox) decided not to support non-encrypted connections with HTTP/2. So the verbosity and the ability to watch messages on the network and debug things has gone down the drain.
WebAssembly
I’ve recently covered WebAssembly, comparing the decisions around it to those of WebRTC.
WebAssembly is a binary format meant to replace the use of JavaScript in the browser.
Developers will write their frontend code in JavaScript or whatever other language they fancy, and will have to compile it to WebAssembly. The browser will then execute WebAssembly without the need to parse too much text as it needs to do today. The end result? A faster web, with more languages available to developers.
This is going to take a few years to materialize and many more years to become dominant and maybe replace JavaScript, but it is the intent here that matters.
Why is it important?
We need to wean ourselves from textual protocols and shift to binary ones.
Yes. Machines are becoming faster. Processing power more available. Bandwidth abundant. And we still have clogged networks and overloaded CPUs.
The Internet of Things won’t make things any easier on us – we need smaller devices to start and communicate. We need low power with great performance. We cannot afford to ruin it all by architectures and designs based on text protocols.
The binary web is coming. Better be prepared for it.
Very interesting article!
It’s actually very amusing that people are only talking about this now when I had brought up these concerns about the inefficiency of HTML and HTTP as far back as circa 1997, and suggested to some colleagues about going binary. Nobody seemed to think it was an issue, however, given the increasing popularity of HTML combined with the dot-com boom. And even more ironic, 20 years go the concern of text-vs-binary was an even greater concern given the bandwidth limitations (many households still only had 56k modems and workplaces were primarily limited to ISDN, unless they were fortunate to be near a university with access to T1 lines like here at the U of I). I guess 20 years late is still better than nothing when it comes to technological progress 😀