I don't have data on this, but it feels like solving the wrong problem. Is text parsing overhead a significant drain on modern systems?
The size difference over a wire between gzipped/deflated text and protocol buffers is also usually dwarfed by almost any other asset being loaded on the page (images, fonts, videos etc).
The benefits of human readability and simplicity probably outweigh those size differences, I think.
I do agree there's a lot of room for improvement in the html/css/js combination, though. They were designed for far less dynamic interfaces than those we're trying to build today.
The CSS model in particular is very conceptually complicated for a layout system. I say that having used it for 13 years.
You're right: replacing HTML with protocol buffers wouldn't do much to make the web smoother. HTML is immediately parsed into a tree stored in memory, and the initial parsing overhead is negligible compared to asset load times (on this site, for example, Chrome reports parsing took ~0.4ms, whereas loading the tiny upvote arrow took a whopping 45ms). Once loaded, pages wouldn't be any more smooth than they are today if they used a binary encoding: regardless of whether you ship trees as binaries or text, after the initial parse the in-memory data structures used by the browser will be essentially the same. GZIP is fairly efficient at encoding HTML tags, and protocol buffers (and any other binary format) would have to encode all of the non-tag text on the page anyway. The gains from binary formats there are minimal.
Controlling browser prefetching and load ordering would do much more than rewriting to use a binary format, as would alternative layout options, as would better image formats, as would more performant VMs (e.g. better asm.js support), as would... A near-endless number of things. Text vs. binary for the initial document tree doesn't make an appreciable difference.
the performance and memory bottleneck in the web is not, as it is commonly believed, javascript, or html.
It's the increasingly complicated DOM, and CSS3 layout model.
Web Apps go slow, and this gets blamed on javascript because that's the language you happen to be writing in. (or wronging in). But the slowness you get usually comes from the constant triggering and retriggering of giant byzantine relayout and compositing algorithms from what you might think is reasonably written code.
it's THAT problem that facebook's react library is aimed at... fixing? no, reducing. Write reasonable JS, and let the library optimise DOM interactions.
Every new feature of HTML5 and CSS adds some weight to those enormous piles of sand the browser has to shift around.
Binary formats would not fix that. Bytecodes wouldn't fix that. Different languages wouldn't fix that. Javascript is fine. it's the DOM and CSS that need to be fixed.
Is it as fast on low end to medium-priced smartphones ? HN is much less complex than other website you can visit, it's a very minimal design.
Even if you compress it, how really is it to parse a big html page ? How many CPU cycle do you need depending on the size of the page ? Couldn't you optimize a webpage by removing unnecessary tags by compiling or pre parsing it ?
I'm talking about parsing performance though, not the size of one page.
Comments
I don't have data on this, but it feels like solving the wrong problem. Is text parsing overhead a significant drain on modern systems?
The size difference over a wire between gzipped/deflated text and protocol buffers is also usually dwarfed by almost any other asset being loaded on the page (images, fonts, videos etc).
The benefits of human readability and simplicity probably outweigh those size differences, I think.
I do agree there's a lot of room for improvement in the html/css/js combination, though. They were designed for far less dynamic interfaces than those we're trying to build today.
The CSS model in particular is very conceptually complicated for a layout system. I say that having used it for 13 years.
You're right: replacing HTML with protocol buffers wouldn't do much to make the web smoother. HTML is immediately parsed into a tree stored in memory, and the initial parsing overhead is negligible compared to asset load times (on this site, for example, Chrome reports parsing took ~0.4ms, whereas loading the tiny upvote arrow took a whopping 45ms). Once loaded, pages wouldn't be any more smooth than they are today if they used a binary encoding: regardless of whether you ship trees as binaries or text, after the initial parse the in-memory data structures used by the browser will be essentially the same. GZIP is fairly efficient at encoding HTML tags, and protocol buffers (and any other binary format) would have to encode all of the non-tag text on the page anyway. The gains from binary formats there are minimal.
Controlling browser prefetching and load ordering would do much more than rewriting to use a binary format, as would alternative layout options, as would better image formats, as would more performant VMs (e.g. better asm.js support), as would... A near-endless number of things. Text vs. binary for the initial document tree doesn't make an appreciable difference.
the performance and memory bottleneck in the web is not, as it is commonly believed, javascript, or html.
It's the increasingly complicated DOM, and CSS3 layout model.
Web Apps go slow, and this gets blamed on javascript because that's the language you happen to be writing in. (or wronging in). But the slowness you get usually comes from the constant triggering and retriggering of giant byzantine relayout and compositing algorithms from what you might think is reasonably written code.
it's THAT problem that facebook's react library is aimed at... fixing? no, reducing. Write reasonable JS, and let the library optimise DOM interactions.
Every new feature of HTML5 and CSS adds some weight to those enormous piles of sand the browser has to shift around.
Binary formats would not fix that. Bytecodes wouldn't fix that. Different languages wouldn't fix that. Javascript is fine. it's the DOM and CSS that need to be fixed.
Is it as fast on low end to medium-priced smartphones ? HN is much less complex than other website you can visit, it's a very minimal design.
Even if you compress it, how really is it to parse a big html page ? How many CPU cycle do you need depending on the size of the page ? Couldn't you optimize a webpage by removing unnecessary tags by compiling or pre parsing it ?
I'm talking about parsing performance though, not the size of one page.