[whatwg] Global Script proposal.

[Ian Hickson]

On Sun, 30 Aug 2009, Michael Nordman wrote:
>
> These arguments against the proposal are not persuasive. I remain of the 
> opinion that the GlobalScript proposal has merit.

That's possible; I would recommend taking up a Global Script proposal in 
the public-webapps working group, though, as it is more of a Web App API 
type of thing than an HTML5 core feature.


> On Sat, Aug 29, 2009 at 2:40 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Mon, 17 Aug 2009, Dmitry Titov wrote:
> > >
> > > Currently there is no mechanism to directly share DOM, code and data 
> > > on the same ui thread across several pages of the web application. 
> > > Multi-page applications and the sites that navigate from page to 
> > > page would benefit from having access to a shared "global script 
> > > context" (naming?) with direct synchronous script access and ability 
> > > to manipulate DOM.
> >
> > This feature is of minimal use if there are multiple global objects 
> > per application. For instance, if each instance of GMail results in a 
> > separate global object, we really haven't solved the problem this is 
> > setting out to solve. We can already get a hold of the Window objects 
> > of subwindows (e.g. for popping out a chat window), which effectively 
> > provides a global object for those cases, so it's only an interesting 
> > proposal if we can guarantee global objects to more than just those.
> 
> What problem do you think this is trying to solve? I think you're 
> misunderstanding the motivation. The motivation is frame/page navigation 
> performance once an app is up and running.
> 
> > However, we can't. Given that all frames in a browsing context have to 
> > be on the same thread, regardless of domain, then unless we put all 
> > the browsing contexts on the same thread, we can't guarantee that all 
> > frames from the same domain across all browsing contexts will be on 
> > the same thread.
> 
> As proposed, there is nothing that forces things into a single thread. 
> Those contexts that happen to be on the same thread can benefit from the 
> feature.

We already have a single global object today, in the world where 
independent windows end up with different "global script" objects. It's 
the Window object of the opener.


> > 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?
> 
> Provided you can talk to the 'shared worker' in the same fashion you can 
> talk to the server (XHR)... you have a point here when it comes to 
> keeping application 'state' in memory and quickly retrieving it from any 
> page in the application. But, using a worker does nothing to keep 
> application 'code' required to run in pages 'hot'... code that does HTML 
> DOM manipulation for example can't run in the worker.
> 
> You can't rely on opener since it can be closed at any time... including 
> prior to the openee being loaded.

It won't get garbage-collected though, so if it's closed, just grab the 
"hot" stuff you want over to a new "master" window.


> Maybe a better approach would be to make frame navigations not so 
> costly.

That's up to browser vendors.


> Does that mean you won't help produce a draft spec of this for us to 
> work with?

I think it's a bad idea, so no. :-)


On Mon, 31 Aug 2009, Michael Davidson wrote:
> 
> 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.

That's fine today, but it won't do us much good when we have orders of 
magnitude more cores than running applications.


> 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

...should be in the browser, not the Web app.


> UI effects

...should be in the CSS, not the script.


> event handling

That's pretty much all that should be in the UI-thread script, and it 
should just defer to the workers.


On Mon, 31 Aug 2009, Mike Shaver wrote:
>
> The multiple server-side processes that end up involved over the course 
> of the user's interaction do need to share state with each other, and 
> preserving blocking semantics for accessing such state makes the 
> programs much simpler to reason about given today's programming 
> languages.  Is that shared state not what the Global Script Object would 
> provide?

Aren't global script objects supposed to be client-side? I don't see how 
they would help with server-side state.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'