Re: Lifecycle - booting up web apps

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.

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>

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.

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>

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...

Kevin Peno
E: kevinpeno@gmail.com
C: 425.408.1094


On Mon, Sep 5, 2011 at 6:25 AM, Marcos Caceres <marcosscaceres@gmail.com>wrote:

> So, taking up Brian's proposal to solve immediate problems (and for us not
> to fly off the rails into [insert browser engine here]-dependency-land), I
> would like to propose addressing the following use case (I think Scott,
> cc'ed, raised this one a while ago on public-webapps and I've been
> discussing it a friend recently).
>
>  When one writes a native application, usually they are able to pass that
> application options through the the command line. For example:
>
> foo --help
> foo --do this --with that --with this
>
> This is naturally very useful for native applications that are CLI-based…
> but are also very useful for enabling/disabling things in graphical
> applications.
>
> In non-webby applications, the usual pattern to handle this is (e.g., in
> java):
>
> public static void main(String[] args){
> //process args
> }
>
> On the Webs, the usual way of handling this is unload and DOMContentLoaded,
> I guess…. there is probably other ways (e.g., $(function(){…}) and setting
> some cookie/localStorage flag).
>
> Without getting into an interesting discussion about REST, and what it
> means for Installable Web Apps, the idea that an installed application is
> started in much the same way as any other native application.
>
> ==Strawman==
> What would be cool would be to have a lifecycle event fired at the widget
> with these options (calling it "boot", but it could be "options", "start",
> "main", whatever):
>
> widget.addEventListener("boot", function(e){
> var args = e.args; //String[] args :)
>  //process args
> })
>
> if widget apps where native:
>
> ./my.wgt -foo bar -x y -z
>
> I guess for other systems that boot applications from a uri:
>
> [uri]://aeb12cxv-adsf-vv/?foo=bar&x=y&z
>
> Not sure yet exactly when the event would be fired (before
> DOMContentLoaded? After?).
>
> Kind regards,
> Marcos
>
> --
> Marcos Caceres
> http://datadriven.com.au
>
>
>