<br><br><div class="gmail_quote">On Mon, Nov 30, 2009 at 4:15 PM, Ian Hickson <span dir="ltr">&lt;<a href="mailto:ian@hixie.ch">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 class="im">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>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><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>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><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>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> </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>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> </div><div>dave</div>
</div>