Another factor in memory usage of b2g and android is likely the absence of XUL. And possibly other optimisations which are not present in the Firefox build<span></span>. We need to investigate what it would take to enable these in webapprt Linux build.<br>
<br>On Tuesday, 5 February 2013, Daniel Narvaez  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'll start with a very general consideration. I'm more and more convinced we should not just add support for html5 but build directly on the top of web applications, as they are emerging both in the Mozilla and in Chrome ecosystems. This means no native/html activities mashups and more importantly the same kind of logic for installation, distribution etc. I've not fully rationalised this assumption yet but, some advantages I see with it<div>


<br></div><div>* Sugar activities will run wherever Firefox (or Chrome) runs. Firefox web activities will run in Sugar.</div><div>* No adaptation necessary, no wrappers, nothing.</div><div>* It will be possible to submit Sugar activities to, say, the Firefox store, giving them more visibility.</div>


<div>* We will not have to maintain browser embedding code, which can be<span></span> really painful</div><div>* We will be able to use new APIs which are being developed as part of efforts like Firefox OS.</div><div>* Developers with experience with web apps will know what to expect.</div>


<div><br></div><div>Now the ironic part is that while it would be pretty straightforward to get this going on desktops and on Android, it looks more tricky in Sugar. I investigated using Firefox and these are the issue I run into.</div>


<div><br></div><div>* No support for offline, browser-less installation. It's actually mostly there for b2g but it only applies to a set of zip files which are found on the first startup.</div><div>* No support for webapps addons (needed to interact with the sugar services, datastore for example). According to a developer comment on a bug report it is planned for the future though.<span></span></div>

<div>* Necessity to replace Browse with a Firefox based webapp, to integrate with the normal installation mechanisms.</div><div>* Very high per process memory usage. I think it's > 50 MB per activity. I have not tested but I suspect b2g (and perhaps Android) gets around this with electrolysis child processes, but Mozilla is not currently working on electrolysis for the desktop browser.</div>

<div><br></div><div>Now the first two are probably solvable nicely by working a bit upstream and has work arounds on the short time (not quite sure about addons, but I have some good hopes).</div><div>The need to replace Browse is a bit scary. I hoped we could take an incremental approach and would not need to rewrite any native activity. I suppose we could have a webapp store activity instead.<br>

</div><div>Memory is a blocker I'd say, even if not an immediate one, we would want it solved before we can start using webapps in the field. I've not looked into it much but as far as I understood electrolysis is on hold mainly because of compatibility with existing (non jetpack) plugins. So I wonder if you could enable electrolysis at build time and have it working for webapp rt. After all it works in b2g which is not hugely different.<br>

</div><div><br></div><div>I'll keep investigating this direction and update the list as I make progress.</div><div><div><br></div>
</div><br><br>-- <br>Daniel Narvaez<br><br>
</blockquote><br><br>-- <br>Daniel Narvaez<br><br>