Received: by 10.115.80.1 with SMTP id h1mr1326146wal.24.1255469667148;
Tue, 13 Oct 2009 14:34:27 -0700 (PDT)
Received: by 10.115.80.1 with SMTP id h1mr1326145wal.24.1255469667098;
Tue, 13 Oct 2009 14:34:27 -0700 (PDT)
Return-Path: <bradneub...@google.com>
Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13])
by gmr-mx.google.com with ESMTP id 18si16906pzk.9.2009.10.13.14.34.25;
Tue, 13 Oct 2009 14:34:26 -0700 (PDT)
Received-SPF: pass (google.com: domain of bradneub...@google.com designates 216.239.45.13 as permitted sender) client-ip=216.239.45.13;
Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of bradneub...@google.com designates 216.239.45.13 as permitted sender) smtp.mail=bradneub...@google.com; dkim=pass (test mode) header...@google.com
Received: from zps18.corp.google.com (zps18.corp.google.com [172.25.146.18])
by smtp-out.google.com with ESMTP id n9DLYPCW027910
for <openweb-group@googlegroups.com>; Tue, 13 Oct 2009 14:34:25 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta;
t=1255469665; bh=mFeTm/1RIJA6cvTPfJROL4C956A=;
h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date:
Message-ID:Subject:From:To:Content-Type:X-System-Of-Record; b=DjOz
QeGwDXurZeUlqeTcM7La3Pt5sAsfYf9dhEIODN8C9kYe6tmuPUoZNe5u5FW/KpFwoh/
e7Wf//sNkgX3zBw==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to:
content-type:x-system-of-record;
b=Lcej7TQP7CVKFYcXfuDNUsUqVx78MelX93KN/Rl2bjtAiMMKiJcx3uKh+s6PB1a0V
SrN6gHK9GwNxjyw0M8gTg==
Received: from pzk17 (pzk17.prod.google.com [10.243.19.145])
by zps18.corp.google.com with ESMTP id n9DLXKCp001915
for <openweb-group@googlegroups.com>; Tue, 13 Oct 2009 14:34:23 -0700
Received: by pzk17 with SMTP id 17so4373236pzk.6
for <openweb-group@googlegroups.com>; Tue, 13 Oct 2009 14:34:23 -0700 (PDT)
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary="000e0cd4cb38503c9f0475d7cf66"
Received: by 10.143.139.2 with SMTP id r2mr705001wfn.168.1255469663402; Tue,
13 Oct 2009 14:34:23 -0700 (PDT)
In-Reply-To: <178b8d440910131429w699d3bc3lfd61314100218...@mail.gmail.com>
References: <1bc4603e0909141404tda86de0j1087ebbf2ae4c...@mail.gmail.com>
<178b8d440909150853h30415773l308bf02e9f0c8...@mail.gmail.com>
<6fc58d0d0910112159s5b5826cen2c69c7c7bb31...@mail.gmail.com>
<178b8d440910131018kcc5f256q862870c3bb8ee...@mail.gmail.com>
<6fc58d0d0910131157p4303ef4bx8a56ae5f90dde...@mail.gmail.com>
<d31b640910131212v4ddf1d7br914fa61126c9f...@mail.gmail.com>
<6fc58d0d0910131308u23ec7b4g337d73c6d74d2...@mail.gmail.com>
<d31b640910131325i2008e8c9x3a724dbac4026...@mail.gmail.com>
<4679b0290910131413i1cf0fa9rf04fd718c18b7...@mail.gmail.com>
<178b8d440910131429w699d3bc3lfd61314100218...@mail.gmail.com>
Date: Tue, 13 Oct 2009 14:34:23 -0700
Message-ID: <4679b0290910131434h4f10a7b1k54b488c1a1b3b...@mail.gmail.com>
Subject: Re: FluidHTML
From: Brad Neuberg <bradneub...@google.com>
To: openweb-group@googlegroups.com
X-System-Of-Record: true
--000e0cd4cb38503c9f0475d7cf66
Content-Type: text/plain; charset=ISO-8859-1
This would definitely require changing the semantics of script loading.
Perhaps we can take a pointer from what FF has been doing with this and you
can flag it in your script tags, either with the deferred attribute or
similar to how FF exposes JS 1.7 features:
<script type="application/javascript;version=1.7"/>
Would become
<script type="application/javascript;batch=true"/>
Or something; document.write simply would not work when used in this context
or might throw an exception.
Best,
Brad
bradneub...@google.com
On Tue, Oct 13, 2009 at 2:29 PM, Mike Samuel <mikesam...@gmail.com> wrote:
>
> 2009/10/13 Brad Neuberg <bradneub...@google.com>:
> >
> >
> > On Tue, Oct 13, 2009 at 1:25 PM, Chris Wilson <cwi...@gmail.com> wrote:
> >>
> >> I see. I agree, the web does owe a lot to the culture of enforced
> >> cross-sharing - though realistically, compressed/obfuscated JavaScript
> isn't
> >> much more intelligible than disassembled C++ code, to me. :)
> >
> > Totally agree. I'd like to find some good architectural fixes to some of
> the
> > unintentional obfuscation that is occurring to get better optimizations
> on
> > the web. Basically, is it possible to get the size down and have low
> latency
> > while still having things be readable and easy for people to code?
> Perhaps
> > this might result in 10 or 20% less optimizations then the hard core code
> > compression being done but it would be worth it to keep things readable.
> >
> > As a first stab, most people combine all their JavaScript files into one
> and
> > then also essentially strip out everything and obfuscate it to make it
> > smaller. The most important optimization is actually combining everything
> > together, as that reduces the latency of page load by about 60%. Is it
> > possible perhaps to have a way for the browser to fetch all the
> JavaScript
> > at once on page load with one HTTP request to mimic putting all the files
> > together? In terms of bandwidth size on the JS files, I think that
> becomes
>
> Not without changing behavior unless the scripts are deferred.
>
> The problem is the weird semantics of document.write.
> <script src=foo.js></script><script src=bar.js></script>
> cannot be automatically combined if foo.js (or indirectly a handler
> invoked by it such as window.onerror) does the following
> if (Math.random() < 0.5) document.write('<script src=baz.js>');
>
> In this case, half the time, the browser would have to load and
> execute foo.js followed by baz.js without ever fetching bar.js, and
> half the time foo.js followed by bar.js. No amount of static analysis
> will let you tell which files you can load in this scenario.
>
>
>
>
> > less important as bandwidth is getting better and most people turn on
> GZip
> > compression anyway.
>
>
>
> > Other things people do to reduce latency is combining all image files
> into
> > one and using CSS tricks to just mask in the ones needed. This again
> makes
> > deployment difficult for most users and essentially obfuscates the page.
> > Maybe something similar can be done.
> >
> > I haven't followed up on it, but I know over in the Atom/GData world
> there
> > was talk of an HTTP batch GET request which could essentially request
> > multiple URLs at once, which would solve the issues above. I think there
> > might be a proposed RFC on this.
> >
> >>
> >> On Tue, Oct 13, 2009 at 1:08 PM, Alex Russell <slightly...@google.com>
> >> wrote:
> >>>
> >>> On Tue, Oct 13, 2009 at 12:12 PM, Chris Wilson <cwi...@gmail.com>
> wrote:
> >>> >
> >>> >
> >>> > On Tue, Oct 13, 2009 at 11:57 AM, Alex Russell <
> slightly...@google.com>
> >>> > wrote:
> >>> >>
> >>> >> >> Please also explain why the
> >>> >> >> inability to sandbox third-party code allows for more
> applications
> >>> >> >> to
> >>> >> >> be written than fewer.
> >>> >> >
> >>> >> >That part seems easy...in the short run, it reduces barriers to
> >>> >> > entry.
> >>> >> >Is that positive over the long haul? No, but systems like ad
> delivery
> >>> >> >were invented on the back of this openness. Dangerous? You bet, and
> >>> >> > we
> >>> >> >need to clean up that mess, but it seems pretty straightforward to
> me
> >>> >> >how openness leads to success in commodity platforms.
> >>> >>
> >>> > That seems like you're referring to the openness of "no compiled code
> >>> > delivery," not the inability to sandbox (from a security perspective)
> >>> > third-party code. Or am I misunderstanding?
> >>>
> >>> You've got it right. I have no problems with sandboxing, a better
> >>> eval(), capabilities for x-domain communication, etc.
> >>>
> >>> Regards
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> > >
> >
>
> >
>
--000e0cd4cb38503c9f0475d7cf66
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
This would definitely require changing the semantics of script loading. Per=
haps we can take a pointer from what FF has been doing with this and you ca=
n flag it in your script tags, either with the deferred attribute or simila=
r to how FF exposes JS 1.7 features:<br>
<br><pre><script type=3D"application/javascript;version=3D1.7"=
/></pre><br>Would become<br><br><pre><script type=3D"application=
/javascript;batch=3Dtrue"/></pre><br>Or something; document.write s=
imply would not work when used in this context or might throw an exception.=
<br>
<br clear=3D"all">Best,<br> =A0Brad<br><br> =A0<a href=3D"mailto:bradneuber=
g...@google.com">bradneub...@google.com</a><br>
<br><br><div class=3D"gmail_quote">On Tue, Oct 13, 2009 at 2:29 PM, Mike Sa=
muel <span dir=3D"ltr"><<a href=3D"mailto:mikesam...@gmail.com">mikesamu=
e...@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204);=
padding-left: 1ex;">
<br>
2009/10/13 Brad Neuberg <<a href=3D"mailto:bradneub...@google.com">bradn=
eub...@google.com</a>>:<br>
<div class=3D"im">><br>
><br>
> On Tue, Oct 13, 2009 at 1:25 PM, Chris Wilson <<a href=3D"mailto:cw=
i...@gmail.com">cwi...@gmail.com</a>> wrote:<br>
>><br>
>> I see. =A0I agree, the web does owe a lot to the culture of enforc=
ed<br>
>> cross-sharing - though realistically, compressed/obfuscated JavaSc=
ript isn't<br>
>> much more intelligible than disassembled C++ code, to me. =A0:)<br=
>
><br>
> Totally agree. I'd like to find some good architectural fixes to s=
ome of the<br>
> unintentional obfuscation that is occurring to get better optimization=
s on<br>
> the web. Basically, is it possible to get the size down and have low l=
atency<br>
> while still having things be readable and easy for people to code? Per=
haps<br>
> this might result in 10 or 20% less optimizations then the hard core c=
ode<br>
> compression being done but it would be worth it to keep things readabl=
e.<br>
><br>
> As a first stab, most people combine all their JavaScript files into o=
ne and<br>
> then also essentially strip out everything and obfuscate it to make it=
<br>
> smaller. The most important optimization is actually combining everyth=
ing<br>
> together, as that reduces the latency of page load by about 60%. Is it=
<br>
> possible perhaps to have a way for the browser to fetch all the JavaSc=
ript<br>
> at once on page load with one HTTP request to mimic putting all the fi=
les<br>
> together? In terms of bandwidth size on the JS files, I think that bec=
omes<br>
<br>
</div>Not without changing behavior unless the scripts are deferred.<br>
<br>
The problem is the weird semantics of document.write.<br>
=A0<script src=3Dfoo.js></script><script src=3Dbar.js>&l=
t;/script><br>
cannot be automatically combined if foo.js (or indirectly a handler<br>
invoked by it such as window.onerror) does the following<br>
=A0if (Math.random() < 0.5) document.write('<script src=3Dbaz.js=
>');<br>
<br>
In this case, half the time, the browser would have to load and<br>
execute foo.js followed by baz.js without ever fetching bar.js, and<br>
half the time foo.js followed by bar.js. =A0No amount of static analysis<br=
>
will let you tell which files you can load in this scenario.<br>
<div><div></div><div class=3D"h5"><br>
<br>
<br>
<br>
> less important as bandwidth is getting better and most people turn on =
GZip<br>
> compression anyway.<br>
<br>
<br>
<br>
> Other things people do to reduce latency is combining all image files =
into<br>
> one and using CSS tricks to just mask in the ones needed. This again m=
akes<br>
> deployment difficult for most users and essentially obfuscates the pag=
e.<br>
> Maybe something similar can be done.<br>
><br>
> I haven't followed up on it, but I know over in the Atom/GData wor=
ld there<br>
> was talk of an HTTP batch GET request which could essentially request<=
br>
> multiple URLs at once, which would solve the issues above. I think the=
re<br>
> might be a proposed RFC on this.<br>
><br>
>><br>
>> On Tue, Oct 13, 2009 at 1:08 PM, Alex Russell <<a href=3D"mailt=
o:slightly...@google.com">slightly...@google.com</a>><br>
>> wrote:<br>
>>><br>
>>> On Tue, Oct 13, 2009 at 12:12 PM, Chris Wilson <<a href=3D"=
mailto:cwi...@gmail.com">cwi...@gmail.com</a>> wrote:<br>
>>> ><br>
>>> ><br>
>>> > On Tue, Oct 13, 2009 at 11:57 AM, Alex Russell <<a hre=
f=3D"mailto:slightly...@google.com">slightly...@google.com</a>><br>
>>> > wrote:<br>
>>> >><br>
>>> >> >>=A0Please also explain why the<br>
>>> >> >> inability to sandbox third-party code allows=
for more applications<br>
>>> >> >> to<br>
>>> >> >> be written than fewer.<br>
>>> >> ><br>
>>> >> >That part seems easy...in the short run, it reduc=
es barriers to<br>
>>> >> > entry.<br>
>>> >> >Is that positive over the long haul? No, but syst=
ems like ad delivery<br>
>>> >> >were invented on the back of this openness. Dange=
rous? You bet, and<br>
>>> >> > we<br>
>>> >> >need to clean up that mess, but it seems pretty s=
traightforward to me<br>
>>> >> >how openness leads to success in commodity platfo=
rms.<br>
>>> >><br>
>>> > That seems like you're referring to the openness of &=
quot;no compiled code<br>
>>> > delivery," not the inability to sandbox (from a secu=
rity perspective)<br>
>>> > third-party code. =A0Or am I misunderstanding?<br>
>>><br>
>>> You've got it right. I have no problems with sandboxing, a=
better<br>
>>> eval(), capabilities for x-domain communication, etc.<br>
>>><br>
>>> Regards<br>
>>><br>
>>><br>
>><br>
>><br>
>><br>
><br>
><br>
> ><br>
><br>
<br>
<br>
</div></div></blockquote></div><br>
--000e0cd4cb38503c9f0475d7cf66--
Message from discussion FluidHTML
| Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy |
| ©2013 Google |