Re: Lifecycle - booting up web apps

Hi Kevin,  


On Monday, September 5, 2011 at 6:34 PM, Kevin Peno wrote:

> When we talk about passing arguments via query string, I can't help but thing of all the things that go on at the server before the user agent even gets to rendering, much less DOMContentLoaded. To me it sounds like we need an event that fires before anything is done with the document at all.
Right, this is why I said in the previous email that I wanted to avoid the whole RESTful aspect… it seems we need a general working model of what an "Installable Web App" is for sanity:  

1. is it a W3C Widget running on a local machine?

2. A W3C Widget running on a server, whose content is served in a web page (e.g., Wookie, Google gadgets)?  

2. is it an (PHP, Ruby, foo) application on the server that is served and whose resources are cached through app cache?

My working assumption is something like 1: a W3C widget or a PhoneGap application (i.e., a locally installed native application… written in html, css, javascript).  

I think we need another thread just to nail this down as a group. There is no need to just pick one, we could tackle the issues for all three (or more) case.  

>  
> Something similar exists in XML with the xml-stylesheet processing instruction. If set to an xsl document then, before the output is displayed, the XSL processor takes the data and outputs the resulting document. A similar processing instruction could be created to native apps? Here's the doc I'd see loaded for a web app prior to bootstrap:  
>  
> <?xml version="1.0"?>  
> <?web-app-bootstrap type="application/javascript" href="./bootstap.js"?>
> <app>
> <name>My Cool Web App</name>
> <version>0.1</version>
> </app>

This is kinda interesting… and a good analogy.  

>  
> The pros to this are that the app could be given a blank DOM by the user agent when it loads (perhaps even blank HTML DOM so that things like document.body are available) and that, theoretically, everything will be "ready" when the bootstrap runs. This lets the app do whatever it wants. Some cons: requires XML, not backward compatible. I'm sure there are others.  

The cons is that I need to hack bootstrap.js. The use case I wanted to focus on was starting an application from the command line (as I assume the App is a black box … like a zip file).  

> An alternative could be to simply add an attribute to script elements in the head of a document to differentiate between script elements in head and execute bootstrap first.  
>  
> <script type="application/javascript" src="./bootstrap" bootstrap="bootstrap"></script>  
Right, again, the use case is a little different. But absolutely this solves the problem for traditional web applications.  
>  
> Pro: by putting this as the first script in the document, it is backward compatible to current parser/dom execution of scripts (it will get executed first [mostly], before display is available).  
> Cons:
> The document is not "ready" when this is called. This isn't a terrible thing, but it means that the application can only load any dependencies and save those config options. Then it would have to set a callback on whatever even it wants (DOMContentLoaded for example) to start the application "loop".
>  If we specify that this must be executed first, then parsers will have to look ahead to find it and run the script. I don't think browser vendors (specifically) will like this since it will slow display in a case where bootstrap doesn't exist.
>  
> Now for more coffee...
Me too! :)

Received on Tuesday, 6 September 2011 07:27:21 UTC