- From: Michael Davidson <mpd@google.com>
- Date: Mon, 31 Aug 2009 10:53:34 -0700
(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