<div class="gmail_quote">On Mon, Nov 30, 2009 at 4:29 PM, David Levin <span dir="ltr">&lt;<a href="mailto:levin@google.com">levin@google.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br><br><div class="gmail_quote"><div class="im">On Mon, Nov 30, 2009 at 4:15 PM, Ian Hickson <span dir="ltr">&lt;<a href="mailto:ian@hixie.ch" target="_blank">ian@hixie.ch</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div>On Mon, 30 Nov 2009, Dmitry Titov wrote:<br>
&gt;<br>
&gt; That also pretty much means if we won&#39;t do SharedScript, we&#39;ll need to<br>
&gt; explore other opportunities toward efficient sharing of code and data<br>
&gt; which does not make people to write a multithreaded UI as SharedWorker<br>
&gt; solution would do. We have practically zero positive response to<br>
&gt; SharedWorkers being used this way. Granted, this is &quot;just one company&quot;<br>
&gt; but the limited unscientific poll kind of shows the direction...<br>
<br>
</div>The pushback on SharedWorkers at Google is because Google teams don&#39;t want<br>
to rewrite their apps to work with workers -- SharedScript lets them<br>
handle some of the cases SharedWorkers would get them, without having to<br>
rewrite as much code.<br>
<br></blockquote><div><br></div></div><div>Presenting this as a SharedWorker vs SharedScript thing is a false dichotomy. SharedWorkers and SharedScript serve different purposes for the people who want to use each.</div><div>

<br>
</div><div>The majority of applications are not written to do <b>all</b> of their logic in a background thread, so it is odd to me that it is espoused as the right paradigm on web developers. There is a certain amount of logic that makes sense to happen on the main thread and be shared across windows.</div>

<div class="im">
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
However, we should not be basing the platform&#39;s progress on transition<br>
cost avoidance of one company. Google can afford to rewrite GMail if it<br>
comes down to that. It is not in the Web&#39;s long term interests for us to<br>
design features that are optimised for the transition phase at the cost of<br>
the long-term health of the Web.<br></blockquote><div><br></div></div><div>On the other hand, just because there is a hammer, it doesn&#39;t mean that everything is a nail no matter how much we want it to be.</div><div class="im">

<div><br></div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What we should be looking at is what API do teams prefer to work with when<br>
starting from scratch,</blockquote><div><br></div></div><div>And it makes a lot of sense for new apps to do some logic that is quick on the main thread (and not proxy it off to another thread).</div><div class="im"><div>

 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 because on the long term that will be the far more<br>
common case than transitioning from a legacy codebase. I don&#39;t think that<br>
our (Google&#39;s) response is representative here.<br>
<font color="#888888"><br></font></blockquote><div><br></div></div><div>Based on my 10+ years of experience as an app developer, I think the response is very representative of what I&#39;d want.</div></div></blockquote><div>

<br></div><div>To be fair, app developers in general want to do everything synchronously but we (in standards land) have pushed back very hard because software research has shown that such interfaces are very difficult (if not impossible) to parallelize.  That&#39;s why SharedScript sidesteps the issue by saying there should be no parallelism.  Which really is a step backwards.</div>

</div>