A Rational Web Platform

[Dimitri Glazkov]

Hello Blinkers!

The freshly-minted 2014 is here and we're looking it over, kicking the tires. For me, the amazing 2013 was a blur, and I thought it would be important to spend some time early in the year, catching glimpses of insight and perhaps even pearls of wisdom from the year past.

So, with love and care, I wrote you Blink-people a little doc. It's not a poem or a novel, but rather my thoughts on the future of the Web platform, viewed through the lens of the platform builders (that's us!).

https://docs.google.com/a/chromium.org/document/d/1ZkV1PpPsJJgdSZOA10Jh0VrThR6D_Q0XWv_2B9-0gGE/edit

Comments, discussion, and any productive feedback are appreciated.

:DG<

[Jon Rimmer]

Hi Dimitri,

Very good document, and I agree with most of what you say. My thoughts are as follows:

Firstly, you mention the problem of layering putting pressure on performance, but another issue is the possibility of over-constraining future implementations in other ways. The best example of this I have heard is how Apple reworked a number of HTML's UI elements for iOS to work better on a small touch-screen. Had things like input[type=date] or select been specced in ways that explained exactly how they should be rendered, the pseudo elements they should provide, etc. then this would have prevented Apple from innovating like this, or at least required them to break the standards to do it.

Somewhat related to that, as you note, low-level APIs tend to provide less abstraction over the underlying system, but this becomes dangerous when, as with the web, there isn't one underlying system, but many. There is a risk of exposing things like endianness in a way that introduces compatibility problems into the platform. Browser engineers wrangling cross-platform C++ have to deal with these issues all the time, of course, but web developers don't, so they're far more like to be tripped up by APIs with unpredictable results on different systems. The nightmare scenario would be that the web platform ceases to be a platform at all, and simply becomes an amalgamation of JS bindings to various operating system APIs of varying capability.

Similarly, is there a danger that these low-level APIs may end up freezing the web into a particular view of the hardware and the network that gradually becomes anachronistic? Like the old joke about the PDP-11 being dead, but its assembly language living on as C, will the platform end up becoming ossified, too constrained by its own legacy, eventually necessitating the kind of rip-it-up-and-start-again API reboots that operating systems seem to go through every few years.

Anyway, all of that sounds quite negative, and I should say I am a supporter of the extensible web in principle, but I worry that it's being presented as a panacea when I'm sure it was have problems and unexpected consequences, just like any engineering approach.

Thanks,

Jon

[Dimitri Glazkov]

On Tue, Jan 7, 2014 at 3:14 AM, Jon Rimmer <jon.r...@gmail.com> wrote:

Hi Dimitri,

Very good document, and I agree with most of what you say. My thoughts are as follows:

Firstly, you mention the problem of layering putting pressure on performance, but another issue is the possibility of over-constraining future implementations in other ways. The best example of this I have heard is how Apple reworked a number of HTML's UI elements for iOS to work better on a small touch-screen. Had things like input[type=date] or select been specced in ways that explained exactly how they should be rendered, the pseudo elements they should provide, etc. then this would have prevented Apple from innovating like this, or at least required them to break the standards to do it.

Somewhat related to that, as you note, low-level APIs tend to provide less abstraction over the underlying system, but this becomes dangerous when, as with the web, there isn't one underlying system, but many. There is a risk of exposing things like endianness in a way that introduces compatibility problems into the platform. Browser engineers wrangling cross-platform C++ have to deal with these issues all the time, of course, but web developers don't, so they're far more like to be tripped up by APIs with unpredictable results on different systems. The nightmare scenario would be that the web platform ceases to be a platform at all, and simply becomes an amalgamation of JS bindings to various operating system APIs of varying capability.

Similarly, is there a danger that these low-level APIs may end up freezing the web into a particular view of the hardware and the network that gradually becomes anachronistic? Like the old joke about the PDP-11 being dead, but its assembly language living on as C, will the platform end up becoming ossified, too constrained by its own legacy, eventually necessitating the kind of rip-it-up-and-start-again API reboots that operating systems seem to go through every few years.

Anyway, all of that sounds quite negative, and I should say I am a supporter of the extensible web in principle, but I worry that it's being presented as a panacea when I'm sure it was have problems and unexpected consequences, just like any engineering approach.

Thanks for the feedback. Everything you mentioned is exactly the type of thinking one should apply when designing a good layered system. Based on what I've experienced when designing Web Components, I fully expect this to be a long, windy road, riddled with hard decisions and ugly compromises.

:DG<

[Michael[tm] Smith]

Hi Dimitri,


Dimitri Glazkov <dgla...@chromium.org>, 2014-01-06 15:04 -0800:

> [...] my thoughts on the future of the Web platform, viewed through the

> lens of the platform builders (that's us!).
>
> https://docs.google.com/a/chromium.org/document/d/1ZkV1PpPsJJgdSZOA10Jh0VrThR6D_Q0XWv_2B9-0gGE/edit

I think you might want to say a lot more about JavaScript in that document.

You write "HTML is a UI toolkit, written on top of DOM" -- which is
intriguing, and I get your point. You clarify it by saying, "I should be
able to do so with the lower-layer APIs of the platform (DOM in this case)"
and the point is even more clear.

But I think it's interesting to contrast that with Alex's "DOM, therefore,
is merely the largest built-in JS library" (from his blog posting at
http://infrequently.org/2012/04/one-for-dave-and-david/ that you actually
cite in your document) and with Alex's diagram of the mental model of
a webdev "scripting the browser" at http://goo.gl/ZVvhUR which basically
looks like, "Render Tree on top of DOM on top of JS on top of HTML Parser".

The current description in your document looks to me a lot more like Alex's
"if this looks reasonable to you, you might be a browser developer" (bad)
mental model at http://goo.gl/82gbCP -- where "JS is just a growth
protruding from the side of an otherwise healthy platform".

I'm not saying Alex is necessarily right or wrong here. But if you think
he's more right that wrong (in this particular case..), you could refine
your description of what a webdev should be able to do with the platform,
by making it clear that the lower(est) layer (APIs) of the platform comes
from JavaScript.

Your document at this point doesn't even mention JavaScript at all. It
seems like it should say a lot more about it.

--Mike

--
Michael[tm] Smith http://people.w3.org/mike

[Elliott Sprehn]

On Tue, Jan 7, 2014 at 11:09 PM, Michael[tm] Smith <mi...@w3.org> wrote:

...

But I think it's interesting to contrast that with Alex's "DOM, therefore,
is merely the largest built-in JS library" (from his blog posting at
http://infrequently.org/2012/04/one-for-dave-and-david/ that you actually
cite in your document) and with Alex's diagram of the mental model of
a webdev "scripting the browser" at http://goo.gl/ZVvhUR which basically
looks like, "Render Tree on top of DOM on top of JS on top of HTML Parser".

Perhaps Alex can clarify but that model doesn't make any sense to me either. Why is the render tree built on JS but the HTML parser isn't?

- E 

[Dimitri Glazkov]

On Tue, Jan 7, 2014 at 11:09 PM, Michael[tm] Smith <mi...@w3.org> wrote:

I don't see a contradiction between what Alex wrote and my blabbering. I just state that DOM a lower layer than HTML. I intentionally avoided going into the discussion on specifics of how the layers are structured. That's a much larger and more difficult task, and I totally don't believe that I can just crank out the whole system design all by myself. I mean, I could, but then it would be full of hot air :) I need you folks to help discovering/defining/refining this.

:DG<

[Alec Flett]

 I think "JS" in the diagram is more about "there's some user-level JavaScript code running at this layer" more than Javascript-the-language-interpreter.

My interpretation is that from a web developer's perspective, the HTML parser might as well just be a JS library which parses some text and makes DOM calls to construct the render tree. So web page code, also written in JS, is just a peer of the parser, or might even be involved in constructing the DOM.

From this perspective, there's a lot of magic still in the platform - i.e. why can't I override document.createElement() and affect what the http parser does when it creates elements?

Alec