7 ms·

HTML5 is done, but two groups still wrestle over Web's future

82 points by bkardell 12y ago

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.
dreamweapon 12y ago
Oh -- I thought the "done" in the title meant "done with, finished, over." But alas, it was wishful thinking.
- innguest 12y ago
  Same here, I was so hopeful.
  - CmonDev 12y ago
    You have to wait until ~2050 for that.
ardz 12y ago
HTML, JavaScript and CSS are the worst things that happened to mankind right after C++ - the language which most browsers are written in - horrible, rotten, bug ridden things.
_random_ 12y ago
"...anything that slows the improvement of the Web means programmers are more likely to devote their energies to writing apps for smartphones and tablets running on Apple's iOS and Google's Android operating systems instead of HTML5..." And rightly so. Being locked into a store worries me much, much less than being locked into using JS and HTML.
- Igglyboo 12y ago
  Wow, I can't believe he said that.
  - wavefunction 12y ago
    I don't understand the OP's view at all, I have to admit. JS and HTML are about the only things offering freedom on the internet these days.
    - shakethemonkey 12y ago
      Essentially every Android phone or tablet permits side-loading of apps, and installing third-party app directories ("stores"). People may not use such very much, but the freedom is still there.
    - rimantas 12y ago
      Well, when I want internet I launch browser. When I need something else, I launch an app. More likely than not it gets data from some web server via HTTP and in JSON. It may even use bits of HTML for some views. Who cares. I don't get this obsession to defeat native on mobiles. Like don't get at all. Some dark thoughts start to creep in: maybe that's just some lazy webdevs who see mobile as new hotness but cannot be bored to learn native try to pull the only thing they know into that space? If embeded programming will be the new hotness, will we see the same? Why complain about developers developing for Android and iOS, but not metion those developing for Windows or OS X? And throwing half-baked (at best) features so just some capabilities can be checked on the HTML-on-mobile laundry list won't make them more fun to work with. How's that offline web apps thing going?
fidotron 12y ago
I've been doing mobile professionally for well over a decade, and every three months or so something happens in that world which annoys me into thinking that the web is the future again. The times when I've ever actually done anything to look into it - well, mobile's a mess, but the web is a whole other level of horrific. Guess what I spent this afternoon doing. This is why backend server devs seem to actually make it to middle age, whereas front end types go to burning man one time and never come back.
- CmonDev 12y ago
  Life is not worth spending on trying to position DIVs properly or locating a JS typo.
guelo 12y ago
W3C has been proven useless or harmful time and time again. If it hadn't been for WHATWG they'd be at ICANN level of awfulness by now.
matthewmacleod 12y ago
I'm not quite sure why there's such a negative opinion of the front-end web stack around these parts. Yeah, HTML/CSS/JS have lots of warts and hangovers from their respective document-oriented origins. But recent developments have been great, and there are myriad tools to make working with these technologies pretty enjoyable (SASS in particular changes the whole business of styling.) I think that ultimately, building cross-platform, cross-device apps is always going to involve a fair bit of work. The web's still the best tool for doing that, and it's getting better.
- CmonDev 12y ago
  C++ has warts but you don't have to use it or "compile" to it. HTML/CSS/JS have warts but you have no choice but to use them.
- sjogress 12y ago
  The web stack is not just about the web anymore. I'm seeing it being used in all sorts of customer-facing products. For instance TV set-top boxes very often use the web stack for their GUIs. Though, to be honest, they often use SVG for markup instead of HTML.
chadzawistowski 12y ago
I'm confused why WHATWG is concerned about W3C plagiarizing their work on an HTML5 spec, when the alternative is competing specs which drift further apart. Surely interoperability is key here?
- wanderr 12y ago
  I'm very much a distant observer here so I might not even know what I'm talking about, but my understanding is that a large part of the problem is that W3C declares a spec as final and stops updating it, while WHATWG is still working on it. So we do end up with competing specs that drift further apart over time. It would be preferable for W3C to just link to the WHATWG docs which are actually maintained.
  - domenicd 12y ago
    Exactly. Unfortunately they can't even bring themselves to do this. See e.g. http://www.w3.org/TR/html5/references.html#refsURL http://www.w3.org/TR/html5/references.html#refsURL wherein they add in a non-normative note a link to the WHATWG URL spec, but in the normative reference text instead link to an old, outdated working draft from 2012 which specifies an incorrect algorithm and APIs that do not exist in any browser like getParameterNames() and so on. It's very tragic, and not at all good for the health of the web.

82 points by bkardell 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.

dreamweapon 12y ago

Oh -- I thought the "done" in the title meant "done with, finished, over." But alas, it was wishful thinking.

innguest 12y ago
Same here, I was so hopeful.
- CmonDev 12y ago
  You have to wait until ~2050 for that.

ardz 12y ago

HTML, JavaScript and CSS are the worst things that happened to mankind right after C++ - the language which most browsers are written in - horrible, rotten, bug ridden things.

_random_ 12y ago

"...anything that slows the improvement of the Web means programmers are more likely to devote their energies to writing apps for smartphones and tablets running on Apple's iOS and Google's Android operating systems instead of HTML5..." And rightly so. Being locked into a store worries me much, much less than being locked into using JS and HTML.

Igglyboo 12y ago
Wow, I can't believe he said that.
- wavefunction 12y ago
  I don't understand the OP's view at all, I have to admit. JS and HTML are about the only things offering freedom on the internet these days.
  - shakethemonkey 12y ago
    Essentially every Android phone or tablet permits side-loading of apps, and installing third-party app directories ("stores"). People may not use such very much, but the freedom is still there.
  - rimantas 12y ago
    Well, when I want internet I launch browser. When I need something else, I launch an app. More likely than not it gets data from some web server via HTTP and in JSON. It may even use bits of HTML for some views. Who cares. I don't get this obsession to defeat native on mobiles. Like don't get at all. Some dark thoughts start to creep in: maybe that's just some lazy webdevs who see mobile as new hotness but cannot be bored to learn native try to pull the only thing they know into that space? If embeded programming will be the new hotness, will we see the same? Why complain about developers developing for Android and iOS, but not metion those developing for Windows or OS X? And throwing half-baked (at best) features so just some capabilities can be checked on the HTML-on-mobile laundry list won't make them more fun to work with. How's that offline web apps thing going?

fidotron 12y ago

I've been doing mobile professionally for well over a decade, and every three months or so something happens in that world which annoys me into thinking that the web is the future again. The times when I've ever actually done anything to look into it - well, mobile's a mess, but the web is a whole other level of horrific. Guess what I spent this afternoon doing. This is why backend server devs seem to actually make it to middle age, whereas front end types go to burning man one time and never come back.

CmonDev 12y ago
Life is not worth spending on trying to position DIVs properly or locating a JS typo.

guelo 12y ago

W3C has been proven useless or harmful time and time again. If it hadn't been for WHATWG they'd be at ICANN level of awfulness by now.

matthewmacleod 12y ago

I'm not quite sure why there's such a negative opinion of the front-end web stack around these parts. Yeah, HTML/CSS/JS have lots of warts and hangovers from their respective document-oriented origins. But recent developments have been great, and there are myriad tools to make working with these technologies pretty enjoyable (SASS in particular changes the whole business of styling.) I think that ultimately, building cross-platform, cross-device apps is always going to involve a fair bit of work. The web's still the best tool for doing that, and it's getting better.

CmonDev 12y ago
C++ has warts but you don't have to use it or "compile" to it. HTML/CSS/JS have warts but you have no choice but to use them.
sjogress 12y ago
The web stack is not just about the web anymore. I'm seeing it being used in all sorts of customer-facing products. For instance TV set-top boxes very often use the web stack for their GUIs. Though, to be honest, they often use SVG for markup instead of HTML.

chadzawistowski 12y ago

I'm confused why WHATWG is concerned about W3C plagiarizing their work on an HTML5 spec, when the alternative is competing specs which drift further apart. Surely interoperability is key here?

wanderr 12y ago
I'm very much a distant observer here so I might not even know what I'm talking about, but my understanding is that a large part of the problem is that W3C declares a spec as final and stops updating it, while WHATWG is still working on it. So we do end up with competing specs that drift further apart over time. It would be preferable for W3C to just link to the WHATWG docs which are actually maintained.
- domenicd 12y ago
  Exactly. Unfortunately they can't even bring themselves to do this. See e.g. http://www.w3.org/TR/html5/references.html#refsURL http://www.w3.org/TR/html5/references.html#refsURL wherein they add in a non-normative note a link to the WHATWG URL spec, but in the normative reference text instead link to an old, outdated working draft from 2012 which specifies an incorrect algorithm and APIs that do not exist in any browser like getParameterNames() and so on. It's very tragic, and not at all good for the health of the web.