[whatwg] Global Script proposal.

(Grabbing from the end...)

On Sat, Aug 29, 2009 at 2:40 PM, Ian Hickson <ian at hixie.ch> wrote:
> implementation experience before specifying it. But I really don't think
> it is the direction we should be taking the platform in. Granted,
> programmers today don't want to use threads -- but, well, tough. All
> indications are that that's what the programming model of the next few
> decades is going to be; now is the time to move that way. We shouldn't be
> adding features that actually move us back to the single-threaded world.

Shared workers aren't analogous to a multithreaded programming model.
They're a multiple-single-threaded-process model. It makes a
difference. The former is familiar to many programmers. The latter is
much less common.


In general, your arguments seem to fall into three categories.
(Apologies if I'm misrepresenting you by paraphrasing. My intent is
not to argue against a straw man, but to actually address your
concerns.)

- People should be writing multi-threaded web apps.
- UI code can be a small shim, so code sharing can be accomplished
through shared workers.
- The async model isn't really that tough.

For the first, I would argue that the web should progress much like
desktop apps. Computationally intensive algorithms will be done in a
background thread, but all UI interaction will continue to be done on
one thread. This is how desktop apps work. Scalability is accomplished
by putting different apps on different cores, not by requiring each
application view to run in its own thread. The application itself can
decide how best to take advantage of multiple cores, balancing coding
complexity against performance. This is how I'd like to see web apps
work. Sharing data should be separate from splitting across cores. If
an app needs to push computation to a worker thread, that facility is
available, but it should be up to the app. (Of course, computationally
intensive desktop applications have access to a shared heap, which
would make shared workers much more attractive.)

For the last two, I don't believe that they can be true simultaneously.

> I know that some consider the asynchronous interaction with workers to be
> a blocker problem, but I don't really understand why. We already have to
> have asynchronous communication with the server, which holds the roster
> data structure, and so on. What difference does it make if instead of
> talking to the server, you talk to a worker?


It is true that XHRs to the server are async. If shared workers simply
replace the server, then it's true, programming that way is exactly
what people are used to. However, under that model pages that access
the shared worker have all the complex code that they have today. If
the shared worker replaces a server, then the worker is adding code to
the client, not replacing it. For the UI to be a simple shim, shared
workers have to replace more than just the server. They have to
encompass the entire data model of the application. Pushing the async
line from network I/O up to the data layer of the app is a huge
change. I am unaware of any programming frameworks that work this way.

It's not just that this is a difficult way to program, it's entirely
new. You have said previously that having to rewrite Gmail is not
justification for a feature, and I agree. However, since this is a
totally different programming model, I find it unlikely that weekend
coding projects will start off taking advantage of shared workers in a
way that will maximize code reuse. Since almost all web apps start as
weekend coding projects, by the time they get big enough to require
code sharing, synchronous access to the data model from the UI will be
endemic to the app, and it will require a rewrite. It seems to me that
having shared workers as the only mechanism for code sharing is going
to require a rewrite of nearly every web app, even those written in
the future.

(It's possible that frameworks will evolve to encourage async
programming to the data model like they currently do to the network,
but they will all require a rewrite before that happens.)

> Again, use a shared worker. The UI side of things can be quite dumb, with
> data pushed to it from a shared worker.

Finally, I don't think the UI can ever be a simple shim. There's a
long list of things that have to be in the UI: complex widget
rendering, UI effects, event handling, etc. Popular frameworks like
jQuery have huge amounts of code dedicated to UI programming. It's not
possible to push this code to a shared worker. Every render process
will have to have its own copy. Especially if the shared worker is
more than just a local cache for the server, the UI layer will always
be complex.

Michael

Received on Monday, 31 August 2009 10:53:34 UTC