[webkit-dev] Bright Future Tomorrow vs. Boring Today, was: GlobalScript in WebKit

[Dimitri Glazkov]

Indeed. I tend to think that designing specs to work in the future
with future applications in a great leap of engineering faith is not
the approach that's worked. The argument that we should design for new
applications made from scratch smells very XHTMLey to me. Let's take
realistic small steps instead.

:DG<

On Mon, Nov 30, 2009 at 4:29 PM, David Levin <levin at google.com> wrote:
>
>
> On Mon, Nov 30, 2009 at 4:15 PM, Ian Hickson <ian at hixie.ch> wrote:
>>
>> On Mon, 30 Nov 2009, Dmitry Titov wrote:
>> >
>> > That also pretty much means if we won't do SharedScript, we'll need to
>> > explore other opportunities toward efficient sharing of code and data
>> > which does not make people to write a multithreaded UI as SharedWorker
>> > solution would do. We have practically zero positive response to
>> > SharedWorkers being used this way. Granted, this is "just one company"
>> > but the limited unscientific poll kind of shows the direction...
>>
>> The pushback on SharedWorkers at Google is because Google teams don't want
>> to rewrite their apps to work with workers -- SharedScript lets them
>> handle some of the cases SharedWorkers would get them, without having to
>> rewrite as much code.
>>
>
> 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.
> The majority of applications are not written to do all 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.
>
>>
>> However, we should not be basing the platform's progress on transition
>> cost avoidance of one company. Google can afford to rewrite GMail if it
>> comes down to that. It is not in the Web's long term interests for us to
>> design features that are optimised for the transition phase at the cost of
>> the long-term health of the Web.
>
> On the other hand, just because there is a hammer, it doesn't mean that
> everything is a nail no matter how much we want it to be.
>
>>
>> What we should be looking at is what API do teams prefer to work with when
>> starting from scratch,
>
> 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).
>
>>
>> because on the long term that will be the far more
>> common case than transitioning from a legacy codebase. I don't think that
>> our (Google's) response is representative here.
>>
>
> Based on my 10+ years of experience as an app developer, I think the
> response is very representative of what I'd want.
>
> dave
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>