6 ms·

I don't care about this the slightest. I would gladly see something that replace the http/html/css/js combination with something more dynamic that involves less

by jokoon 12y ago

I don't care about this the slightest. I would gladly see something that replace the http/html/css/js combination with something more dynamic that involves less text parsing... compiled html with something that resembles protocol buffer would make webapps much smoother. I guess I'm a low level nerd.

wvenable 12y ago
The web as it exists today would have never happened in binary form. Everything that's terrible about HTML/HTTP/js such as tag soup, liberal acceptance of data, and being text-based have all been avenues to evolve the platform to it's current state. Compiling HTML if done correctly and properly would effectively freeze the design permanently.
- jokoon 12y ago
  > Compiling HTML if done correctly and properly would effectively freeze the design permanently. How ? And do you mean that as a good or a bad thing ? As a bad thing, I disagree, it could still be backward compatible. And isn't frozen platform better to work on ? Can't remember the quote about frozen water.
  - wvenable 12y ago
    Backwards compatiblity is not the issue, it's the forwards compatibility that is the issue. The entire evolution of HTML is based on forward compatibility and progressive enhancement. Many modern HTML features exist because old parsers were extremely forgiving or even buggy. Even something as simple as the HTML5 doctype isn't a valid SGML doctype expected by HTML 4 browsers. It is a hack which just happens to produce the correct results on older browsers. Javascript used to have to be placed in HTML comments so that old browsers wouldn't display the source code as content because the earliest browsers had no concept of client side scripting. Obviously a frozen platform is better to work on -- that's why people continually suggest such things for HTML. Make it compiled! Make it binary! The current situation is far from ideal. But if someone had done that with HTML 1.0 it would have been a lot harder to make it version 5.0.
jomohke 12y ago
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.
- reissbaker 12y ago
  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.
  - TheZenPsycho 12y ago
    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.
innguest 12y ago
I agree. I think it's really inertia that keeps us here. People look up to the W3C and the garbage they come up with. I just saw my coworker using Axure for prototyping and I was impressed - it creates working prototypes with clickable buttons that perform functions and calculations. It's basically what making webpages should be. Except it isn't. Why don't they just make that compilable and distribute a viewer to compete with web browsers? Inertia.
- matthewmacleod 12y ago
  Except it isn't. Why don't they just make that compilable and distribute a viewer to compete with web browsers? Inertia. That's been done - with Flash, for example. Azure is suitable for building prototypes. It's not a replacement for the arbitrarily flexible set of visual, semantic and development tools that HTML, CSS and Javascript offers.
shirro 12y ago
We had compiled web apps. First there were Java applets which were a buggy, insecure, ugly PoS. Then we had ActiveX which was even worse. By comparison html/js/css have produced fairly good results. Parsing text is not a bottleneck for todays machines as any low level nerd would know.
- ksk 12y ago
  >By comparison html/js/css have produced fairly good results. Um, based on what? My browser routinely takes up gigabytes of memory just to show me 'one PDF' worth of content. Analytics scripts steal my CPU time/power that I pay for. HTML/CSS's shitty ambiguous spec without a reference implementation means that no two browsers will ever work alike. And if you're on mobile, all that means you're battery life is screwed. And um.. security? http://secunia.com/vulnerability-review/browser_security.html http://secunia.com/vulnerability-review/browser_security.htm...
  - nmjohn 12y ago
    So you are arguing java and activeX are better than web apps? Because that is the comparison you are responding too. The 1/100 of a penny worth of electricity that analytic scripts cost you a year is worse than the security nightmare of java applets and activeX? Come on.
    - TheOtherHobbes 12y ago
      The fact that Java, ActiveX, Flash, and JavaScript became goto (sic) technologies only underlines how much the web has always been the poster child for 'worse is better.' The irony is that the web stack has become so complex you may as well build apps using one of the many mainstream compiled languages for app logic, and work with an improved DSL for styling and markup. (Which is more or less what Go+SASS/etc are becoming anyway.) The inevitable next stage will happen when the W3C discovers functional programming - I'm guessing around 2020 - and we'll have Greenspun our way to the 10th law again.
      - 12y ago
angersock 12y ago
compiled html with something that resembles protocol buffer would make webapps much smoother. no no no no no no no no no You know what a compiled web app looks like? Here: Content-Encoding: gzip And presto! It works! It is human readable, and yet the representation the machine sees is compact! You know what makes webapps slow? It's badly-written Javascript. It's bad router and proxy connections. It's creating forty-odd connections to thirty-odd 3rd party CDN and analytics and ad platforms. It's gigantic images that aren't sized correctly. It's badly-written CSS that misuses transforms and graphics commands. It's not JS implementations being slow. It's not HTML documents being hard to parse. It's not a shortcoming in HTTP. Your comment suggests a lack of familiarity with the problem domain.
matthewmacleod 12y ago
compiled html with something that resembles protocol buffer would make webapps much smoother. I think you're focusing on the wrong part of the problem if you think that HTML parsing is the limitation on web performance - it's not.

by jokoon 12y ago

wvenable 12y ago

The web as it exists today would have never happened in binary form. Everything that's terrible about HTML/HTTP/js such as tag soup, liberal acceptance of data, and being text-based have all been avenues to evolve the platform to it's current state. Compiling HTML if done correctly and properly would effectively freeze the design permanently.

jokoon 12y ago
> Compiling HTML if done correctly and properly would effectively freeze the design permanently. How ? And do you mean that as a good or a bad thing ? As a bad thing, I disagree, it could still be backward compatible. And isn't frozen platform better to work on ? Can't remember the quote about frozen water.
- wvenable 12y ago
  Backwards compatiblity is not the issue, it's the forwards compatibility that is the issue. The entire evolution of HTML is based on forward compatibility and progressive enhancement. Many modern HTML features exist because old parsers were extremely forgiving or even buggy. Even something as simple as the HTML5 doctype isn't a valid SGML doctype expected by HTML 4 browsers. It is a hack which just happens to produce the correct results on older browsers. Javascript used to have to be placed in HTML comments so that old browsers wouldn't display the source code as content because the earliest browsers had no concept of client side scripting. Obviously a frozen platform is better to work on -- that's why people continually suggest such things for HTML. Make it compiled! Make it binary! The current situation is far from ideal. But if someone had done that with HTML 1.0 it would have been a lot harder to make it version 5.0.

jomohke 12y ago

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.

reissbaker 12y ago
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.
- TheZenPsycho 12y ago
  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.

innguest 12y ago

I agree. I think it's really inertia that keeps us here. People look up to the W3C and the garbage they come up with. I just saw my coworker using Axure for prototyping and I was impressed - it creates working prototypes with clickable buttons that perform functions and calculations. It's basically what making webpages should be. Except it isn't. Why don't they just make that compilable and distribute a viewer to compete with web browsers? Inertia.

matthewmacleod 12y ago
Except it isn't. Why don't they just make that compilable and distribute a viewer to compete with web browsers? Inertia. That's been done - with Flash, for example. Azure is suitable for building prototypes. It's not a replacement for the arbitrarily flexible set of visual, semantic and development tools that HTML, CSS and Javascript offers.

shirro 12y ago

We had compiled web apps. First there were Java applets which were a buggy, insecure, ugly PoS. Then we had ActiveX which was even worse. By comparison html/js/css have produced fairly good results. Parsing text is not a bottleneck for todays machines as any low level nerd would know.

ksk 12y ago
>By comparison html/js/css have produced fairly good results. Um, based on what? My browser routinely takes up gigabytes of memory just to show me 'one PDF' worth of content. Analytics scripts steal my CPU time/power that I pay for. HTML/CSS's shitty ambiguous spec without a reference implementation means that no two browsers will ever work alike. And if you're on mobile, all that means you're battery life is screwed. And um.. security? http://secunia.com/vulnerability-review/browser_security.html http://secunia.com/vulnerability-review/browser_security.htm...
- nmjohn 12y ago
  So you are arguing java and activeX are better than web apps? Because that is the comparison you are responding too. The 1/100 of a penny worth of electricity that analytic scripts cost you a year is worse than the security nightmare of java applets and activeX? Come on.
  - TheOtherHobbes 12y ago
    The fact that Java, ActiveX, Flash, and JavaScript became goto (sic) technologies only underlines how much the web has always been the poster child for 'worse is better.' The irony is that the web stack has become so complex you may as well build apps using one of the many mainstream compiled languages for app logic, and work with an improved DSL for styling and markup. (Which is more or less what Go+SASS/etc are becoming anyway.) The inevitable next stage will happen when the W3C discovers functional programming - I'm guessing around 2020 - and we'll have Greenspun our way to the 10th law again.
    - 12y ago

angersock 12y ago

compiled html with something that resembles protocol buffer would make webapps much smoother. no no no no no no no no no You know what a compiled web app looks like? Here: Content-Encoding: gzip And presto! It works! It is human readable, and yet the representation the machine sees is compact! You know what makes webapps slow? It's badly-written Javascript. It's bad router and proxy connections. It's creating forty-odd connections to thirty-odd 3rd party CDN and analytics and ad platforms. It's gigantic images that aren't sized correctly. It's badly-written CSS that misuses transforms and graphics commands. It's not JS implementations being slow. It's not HTML documents being hard to parse. It's not a shortcoming in HTTP. Your comment suggests a lack of familiarity with the problem domain.

matthewmacleod 12y ago

compiled html with something that resembles protocol buffer would make webapps much smoother. I think you're focusing on the wrong part of the problem if you think that HTML parsing is the limitation on web performance - it's not.