On Thu, Oct 1, 2009 at 9:24 AM, Sami Jaber <[email protected]> wrote:
> I was wondering why wouldn't it be possible to automatically create the > split point based on the information provided by the AST and Compilation > Analysis .... > We know precisely where the code cost JS size and where are the call sites > for a given split point. Why not hooking up the AST to create a balanced > tree and thus create several small sized fragment ? > Those generated split points would be adapted regarding the code evolution > and the user would never care of this hidden functionality > If you mean transparently changing a synchronous call into an asynchronous call, there are a couple of insurmountable (IMHO) problems: - you can't return back to the event loop or you lose the call stack, which means the browser is totally locked (except on Chrome) until the fetch returns. On most browsers, timers won't fire during a busy-wait poll and you will also get slow script warnings - async calls can fail, and you have no way of handling the errors in a useful way. Even if you throw an exception, the programmer has to be prepared for every call to fail, which in practice means only catching the exception at a high level and aborting I think it is far better to have the programmer explicitly specify the split point so they know that it is in fact an async call, can usefully handle error conditions at that point, and allows the browser to run its event loop. -- John A. Tamplin Software Engineer (GWT), Google --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
