Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Proposition of an architectural change for Gaia apps
182 views
Skip to first unread message
Vivien
Jun 12, 2013, 10:06:06 AM6/12/13
to dev-...@lists.mozilla.org
Hello folks,
Last year or so many Gaia apps has been built using a framework-less
based approach, using a combination of libraries + css building blocks.
In parallel, during last year a lot of things has been learned about
device constraints, mobile constraints, app constraints,
cross-teams-work constraints.
-----------------
Based on this here are some of those constraints (some are already
partially solved) I would like to reach primarily:
1. *Fast loading application*
Andreas said it a few times already. Apps should load in less than 600ms.
2. *Low memory consumption*
The memory of the device is limited. A limited number of applications
can run at the same time. Less memory used means more applications can
run at the same time.
3. *Stable memory consumption*
It is OK to consume an extra memory while making a particular task of
an application. But this memory needs to be freed once the task has been
finished.
4. *Smooth panel transitions*
Transitions should happen really quick after a hit on a button.
Ideally a panel should be fully loaded when the transition is complete,
but it sounds OK if informations such as the list of wifi networks
around, loads delayed.
5. *Inline activities friendly*
The whole application should not be required to be loaded for
handling a particular operation.
6. *Scoped Panels*
Panels should be independent. So a panel is directly responsible of
its own load time and of any JS breakage it can generate. Also, an
individual panel should not be able to break the application. Different
authors can work on the same application and each of them would be
directly responsible of one or many panels.
It sounds me that is could be a good set of constraints to solve with a
framewor-less based approach, using a combination of libraries + css
building blocks... and html.
(There are other issues obviously and some of them are already handled
by brave folks, like Tim and others in Taipei working on multiple
resolutions support for example. Also, I have omit voluntarily the
specific set of issues of the System app, which is similar in some
cases, but has some special cases too IMHO)
-----------------
The proposal:
<iframe mozbrowser mozapp="app://myapp.gaiamobile.org/myapp.manifest"
src="app://myapp.gaiamobile.org/index.html">
<!doctype html>
<html>
<head>
<!-- This is a dirty little js lib that handle navigation between
panels with a local postMessage protocol -->
<!-- XXX Please don't focus tptionoo much on it - there are some
plans to get rid of it in a potential near future but this
discussion is way out of the scope of this proposal and I
don't want to mix both discussions -->
<script src="shared/js/navigation.js"></script>
</head>
<body>
<!-- This panel will be created only once the application has
loaded. Or it could be directly included in the html if the author wants
to delay the mozbrowserloadend event for some reasons -->
<iframe sandbox="allow-scripts allow-forms"
src="main-panel.html"></iframe>
<!-- This iframe will be created only once the user has made a
choice in the main-panel -->
<iframe sandbox="allow-scripts allow-forms"
src="next-panel.html"></iframe>
<!-- this iframe will be created only once the user has made a
choice in the next panel -->
<iframe sandbox="allow-scripts allow-forms"
src="next-next-panel.html"></iframe>
<!-- Back buttons that lives outside of the panels. A user will
always be able to exit a panel even if this one breaks -->
<button id="back">
</body>
</html>
</iframe>
This is mostly it.
Basically the <navigation.js> helper creates sandbox-ed <iframe>s on
demand and handle the navigation, as well as the back button.
As long the user navigates forward, new sandbox-ed <iframe>s are
created. As soon the user hit the back button the last <iframe> is
removed in order to free the relevant part of memory. Since <iframe>s
are sandboxed without the allow-same-origin flag, the only way to
communicate should be postMessage and data would be serialized that
should prevent references to each other and guarantee that the memory
will be freed.
I feel like this will address 1., 2. and 3. since the memory used will
be directly related to the real user activity and it will be freed once
it is done. Also, an application will be able to detach the previous
state of the application to save some memory if needed. (For example the
settings app would be able to detach the <iframe src="main-panel.html">
if the user has finished the activity but, instead of going back to the
application starts using the back button, he/she hits the home button,
leaving completely the app to do something else.
1. Will be addressed because nothing else than the main code would be
loaded on cold launch. If the app is slow it will be trivial to identify
the responsible panel and to fix it.
5. Will be addressed since it will be easy to declare in the manifest
which urls correlate with a particular inline activity.
6. Will be addressed since each panels will not be able to access others
because of the sandbox. Also, the back button being part of the main app
container will ensure the user will always be able to go back and reload
the panel to see if it works finally (poor's man solution to race
condition, bugs that appear only if your follow a specific code path).
About 4. This model will let us get rid of the <!-- html comment -->
hack used in different applications as well as a big part of
<lazy_loader.js> since only the necessary part of a panel should be
loaded with it. Everything that is not vital and can be delayed like
getting the list of wifi networks can be loaded using <script async>.
As a result Gaia apps will be split in many html files. The directory
organization may reflect it.
How much is it going to impatc load time of a specific panel? I feel
like it should be fast since this is not the equivalent of opening a new
process (it has already been opened), but just spawning a new
compartment and parse js/css file again (see next paragraph about that).
-----------------
Possible issues:
a. Global states cannot be shared.
b. Load time for each panels
1. JavaScript files / libraries needs to be replicated.
2. CSS files need to be replicated.
3. Assets needs to be replicated.
c. Memory overhead for each compartments
I have probably forgot some obvious things, please feel free to add to
the list!
-----------------
Possible answers:
For *a* and *b1*.
Four things comes to my mind.
- Shared Workers - https://bugzilla.mozilla.org/show_bug.cgi?id=643325
- IndexedDB support in Workers -
https://bugzilla.mozilla.org/show_bug.cgi?id=701634
- Lazy bytecode generation -
https://bugzilla.mozilla.org/show_bug.cgi?id=678037
- JSScript sharing - https://bugzilla.mozilla.org/show_bug.cgi?id=679940
First I feel like states should not be shared between panels, but data
should be. I can imagine that there are some cases where some kind of
state needs to be shared, but I'm not convinced this is the most common
case. Shared worker and indexedDB support in workers should solve many
issues and help a lot here. Many different panels would be able to
access the worker that will have been loaded once. I cannot tell how
glad I am to have seen a recent path on the SharedWorker implementation.
bent++.
Lazy bytecode generation will help save some startup time / memory. If a
utility library is replicated, but some part are not used, that will be
less an issue.
JSScript sharing. As far as I have understood those sharing of JSScript
data is mostly for the self-hosted methods, like Array.map and so on. I
wonder if some JSScript data can be shared for scripts with the same
mozapp context, same origin as long as they come from offline cache /
packaged content.
For *b2*, *b3*.
Two things come to my mind:
- Seamless iframe - https://bugzilla.mozilla.org/show_bug.cgi?id=631218
- Similarly to JSScript sharing I wonder if some data can be shared as
well for offline cache/packaged same origin css files ? (obviously I
don't know much about layout/ and it this is possible).
As far as I understand the specification of the 'seamless' attribute,
the sub-iframes will inherit the parent rule. If that means the
style-set rules are shared that would be a good fit to avoid extra load
time and fit our memory constraints.
For c. I made a little measurement and found an extra JS overhead of
100k per compartment on my laptop using about:memory. It is not always
easy to read it so I could have made a mistake. Layout data were adding
an overhead of ~180k per iframes. (140k on the 180k seems to be
html.css/forms.css/... recomputed for each iframes. If seamless is what
I think I wonder it this could be solved in the same bucket partially).
-----------------
Possible Implementation plan
Obviously some part of Gecko are not ready, Shared Worker has only
started the review process, IndexedDB is not accessible from worker,
seamless is not implemented, there is no lazy bytecode evaluation yet,
... But that should not prevent to implement the model for many parts in
many apps.
In the first time of the implementation the sandbox attribute can be
added only based on a whitelist in <navigation.js> in order to allow a
smooth transition. Then, some apps should be able to load some custom
scripts in the main context of their applications until SharedWorker lands.
-----------------
I have more details in my head, but I want to dump this somewhere while
the roadmap for the next version is not final in order to include this
engineering works to the workload for the next coming months if that
makes sense.
Feel free to comments / criticize / etc.
Vivien.
Last year or so many Gaia apps has been built using a framework-less
based approach, using a combination of libraries + css building blocks.
In parallel, during last year a lot of things has been learned about
device constraints, mobile constraints, app constraints,
cross-teams-work constraints.
-----------------
Based on this here are some of those constraints (some are already
partially solved) I would like to reach primarily:
1. *Fast loading application*
Andreas said it a few times already. Apps should load in less than 600ms.
2. *Low memory consumption*
The memory of the device is limited. A limited number of applications
can run at the same time. Less memory used means more applications can
run at the same time.
3. *Stable memory consumption*
It is OK to consume an extra memory while making a particular task of
an application. But this memory needs to be freed once the task has been
finished.
4. *Smooth panel transitions*
Transitions should happen really quick after a hit on a button.
Ideally a panel should be fully loaded when the transition is complete,
but it sounds OK if informations such as the list of wifi networks
around, loads delayed.
5. *Inline activities friendly*
The whole application should not be required to be loaded for
handling a particular operation.
6. *Scoped Panels*
Panels should be independent. So a panel is directly responsible of
its own load time and of any JS breakage it can generate. Also, an
individual panel should not be able to break the application. Different
authors can work on the same application and each of them would be
directly responsible of one or many panels.
It sounds me that is could be a good set of constraints to solve with a
framewor-less based approach, using a combination of libraries + css
building blocks... and html.
(There are other issues obviously and some of them are already handled
by brave folks, like Tim and others in Taipei working on multiple
resolutions support for example. Also, I have omit voluntarily the
specific set of issues of the System app, which is similar in some
cases, but has some special cases too IMHO)
-----------------
The proposal:
<iframe mozbrowser mozapp="app://myapp.gaiamobile.org/myapp.manifest"
src="app://myapp.gaiamobile.org/index.html">
<!doctype html>
<html>
<head>
<!-- This is a dirty little js lib that handle navigation between
panels with a local postMessage protocol -->
<!-- XXX Please don't focus tptionoo much on it - there are some
plans to get rid of it in a potential near future but this
discussion is way out of the scope of this proposal and I
don't want to mix both discussions -->
<script src="shared/js/navigation.js"></script>
</head>
<body>
<!-- This panel will be created only once the application has
loaded. Or it could be directly included in the html if the author wants
to delay the mozbrowserloadend event for some reasons -->
<iframe sandbox="allow-scripts allow-forms"
src="main-panel.html"></iframe>
<!-- This iframe will be created only once the user has made a
choice in the main-panel -->
<iframe sandbox="allow-scripts allow-forms"
src="next-panel.html"></iframe>
<!-- this iframe will be created only once the user has made a
choice in the next panel -->
<iframe sandbox="allow-scripts allow-forms"
src="next-next-panel.html"></iframe>
<!-- Back buttons that lives outside of the panels. A user will
always be able to exit a panel even if this one breaks -->
<button id="back">
</body>
</html>
</iframe>
This is mostly it.
Basically the <navigation.js> helper creates sandbox-ed <iframe>s on
demand and handle the navigation, as well as the back button.
As long the user navigates forward, new sandbox-ed <iframe>s are
created. As soon the user hit the back button the last <iframe> is
removed in order to free the relevant part of memory. Since <iframe>s
are sandboxed without the allow-same-origin flag, the only way to
communicate should be postMessage and data would be serialized that
should prevent references to each other and guarantee that the memory
will be freed.
I feel like this will address 1., 2. and 3. since the memory used will
be directly related to the real user activity and it will be freed once
it is done. Also, an application will be able to detach the previous
state of the application to save some memory if needed. (For example the
settings app would be able to detach the <iframe src="main-panel.html">
if the user has finished the activity but, instead of going back to the
application starts using the back button, he/she hits the home button,
leaving completely the app to do something else.
1. Will be addressed because nothing else than the main code would be
loaded on cold launch. If the app is slow it will be trivial to identify
the responsible panel and to fix it.
5. Will be addressed since it will be easy to declare in the manifest
which urls correlate with a particular inline activity.
6. Will be addressed since each panels will not be able to access others
because of the sandbox. Also, the back button being part of the main app
container will ensure the user will always be able to go back and reload
the panel to see if it works finally (poor's man solution to race
condition, bugs that appear only if your follow a specific code path).
About 4. This model will let us get rid of the <!-- html comment -->
hack used in different applications as well as a big part of
<lazy_loader.js> since only the necessary part of a panel should be
loaded with it. Everything that is not vital and can be delayed like
getting the list of wifi networks can be loaded using <script async>.
As a result Gaia apps will be split in many html files. The directory
organization may reflect it.
How much is it going to impatc load time of a specific panel? I feel
like it should be fast since this is not the equivalent of opening a new
process (it has already been opened), but just spawning a new
compartment and parse js/css file again (see next paragraph about that).
-----------------
Possible issues:
a. Global states cannot be shared.
b. Load time for each panels
1. JavaScript files / libraries needs to be replicated.
2. CSS files need to be replicated.
3. Assets needs to be replicated.
c. Memory overhead for each compartments
I have probably forgot some obvious things, please feel free to add to
the list!
-----------------
Possible answers:
For *a* and *b1*.
Four things comes to my mind.
- Shared Workers - https://bugzilla.mozilla.org/show_bug.cgi?id=643325
- IndexedDB support in Workers -
https://bugzilla.mozilla.org/show_bug.cgi?id=701634
- Lazy bytecode generation -
https://bugzilla.mozilla.org/show_bug.cgi?id=678037
- JSScript sharing - https://bugzilla.mozilla.org/show_bug.cgi?id=679940
First I feel like states should not be shared between panels, but data
should be. I can imagine that there are some cases where some kind of
state needs to be shared, but I'm not convinced this is the most common
case. Shared worker and indexedDB support in workers should solve many
issues and help a lot here. Many different panels would be able to
access the worker that will have been loaded once. I cannot tell how
glad I am to have seen a recent path on the SharedWorker implementation.
bent++.
Lazy bytecode generation will help save some startup time / memory. If a
utility library is replicated, but some part are not used, that will be
less an issue.
JSScript sharing. As far as I have understood those sharing of JSScript
data is mostly for the self-hosted methods, like Array.map and so on. I
wonder if some JSScript data can be shared for scripts with the same
mozapp context, same origin as long as they come from offline cache /
packaged content.
For *b2*, *b3*.
Two things come to my mind:
- Seamless iframe - https://bugzilla.mozilla.org/show_bug.cgi?id=631218
- Similarly to JSScript sharing I wonder if some data can be shared as
well for offline cache/packaged same origin css files ? (obviously I
don't know much about layout/ and it this is possible).
As far as I understand the specification of the 'seamless' attribute,
the sub-iframes will inherit the parent rule. If that means the
style-set rules are shared that would be a good fit to avoid extra load
time and fit our memory constraints.
For c. I made a little measurement and found an extra JS overhead of
100k per compartment on my laptop using about:memory. It is not always
easy to read it so I could have made a mistake. Layout data were adding
an overhead of ~180k per iframes. (140k on the 180k seems to be
html.css/forms.css/... recomputed for each iframes. If seamless is what
I think I wonder it this could be solved in the same bucket partially).
-----------------
Possible Implementation plan
Obviously some part of Gecko are not ready, Shared Worker has only
started the review process, IndexedDB is not accessible from worker,
seamless is not implemented, there is no lazy bytecode evaluation yet,
... But that should not prevent to implement the model for many parts in
many apps.
In the first time of the implementation the sandbox attribute can be
added only based on a whitelist in <navigation.js> in order to allow a
smooth transition. Then, some apps should be able to load some custom
scripts in the main context of their applications until SharedWorker lands.
-----------------
I have more details in my head, but I want to dump this somewhere while
the roadmap for the next version is not final in order to include this
engineering works to the workload for the next coming months if that
makes sense.
Feel free to comments / criticize / etc.
Vivien.
tofumatt
Jun 12, 2013, 1:18:34 PM6/12/13
to dev-...@lists.mozilla.org
So, this flies in the face of the way most front-end developers have been writing client-side web apps since pretty much when that whole business started. It strikes me as very confusing, something that will reload libraries per-"panel" and something that would get very heavy (or be useless) when you have many subviews.
What's the issue with using an approach similar to Backbone or whatever that removes views from memory and templates from the DOM when they are no longer needed? And loading them on-demand? I've been doing that with my Podcasts app for Firefox OS and performance, memory usage, and developer happiness have all been great.
Is this how we want third party developers to write their apps? Frankly, if I looked at a web app and saw code like this I'd run the other way. At all of the hack days I've attended, developers look at gaia on how to write apps. This method seems very odd.
Are there measurable performance gains to this? I'm at a loss as to why this is better than something most client-side MVC frameworks.
- tofumatt | http://tofumatt.com
> _______________________________________________
> dev-gaia mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-gaia
What's the issue with using an approach similar to Backbone or whatever that removes views from memory and templates from the DOM when they are no longer needed? And loading them on-demand? I've been doing that with my Podcasts app for Firefox OS and performance, memory usage, and developer happiness have all been great.
Is this how we want third party developers to write their apps? Frankly, if I looked at a web app and saw code like this I'd run the other way. At all of the hack days I've attended, developers look at gaia on how to write apps. This method seems very odd.
Are there measurable performance gains to this? I'm at a loss as to why this is better than something most client-side MVC frameworks.
- tofumatt | http://tofumatt.com
> dev-gaia mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-gaia
Kevin Grandon
Jun 12, 2013, 2:05:01 PM6/12/13
to Vivien, dev-...@lists.mozilla.org
The iframes are a nice trick, but do we *really* want to code that way, and set this as an example for third-party developers?
I'm honestly really happy with the way we do things in the calendar app today. We lazy-load templates on demand from separate files. Right now these templates are hand coded in javascript, but it would be pretty trivial to use some build step to convert HTML files into templates if desired.
Best,
Kevin
I'm honestly really happy with the way we do things in the calendar app today. We lazy-load templates on demand from separate files. Right now these templates are hand coded in javascript, but it would be pretty trivial to use some build step to convert HTML files into templates if desired.
Best,
Kevin
Salvador de la Puente González
Jun 12, 2013, 3:34:29 PM6/12/13
to Vivien, dev-...@lists.mozilla.org
Hello Vivien
Long time no talking to you! I'm really happy you open this topic. You
know I'm glad of helping. Here my comments:
Detaching from DOM is somewhat tricky as it cause a reflow (or, at
least, a noticeable repaint) but we could set src to '' and reuse empty
iframes. ,)
declare the navigation flow) allows the library to preload those panel
more likely to be accessed.
As you said later, it should be great is "seamless" were available.
problem of freeing the memory not related with the current activity but
it introduces the overhead to reload all the related objects and causes
issue (a). Maybe we could cause the garbage collector to retrieve all
the memory by doing:
1) Encouraging the good practice of not communicate via window.parent /
iframe.contentDocument
2) When the library don't need the iframe, just make its src to ''
(then, eventually detach or reuse)
Furthermore, we could dynamically cut the access to iframe window.parent
(by nullifying it) allowing only Partent -> Children communications /
injections.
You mean like a "JavaScript seamless"?
Again, I think we should push such a initiative!
Best.
________________________________
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
Long time no talking to you! I'm really happy you open this topic. You
know I'm glad of helping. Here my comments:
least, a noticeable repaint) but we could set src to '' and reuse empty
iframes. ,)
>
> I feel like this will address 1., 2. and 3. since the memory used will
> be directly related to the real user activity and it will be freed
> once it is done. Also, an application will be able to detach the
> previous state of the application to save some memory if needed. (For
> example the settings app would be able to detach the <iframe
> src="main-panel.html"> if the user has finished the activity but,
> instead of going back to the application starts using the back button,
> he/she hits the home button, leaving completely the app to do
> something else.
Optionally, simple declarations of what is next a prev (i.e. some way to
> I feel like this will address 1., 2. and 3. since the memory used will
> be directly related to the real user activity and it will be freed
> once it is done. Also, an application will be able to detach the
> previous state of the application to save some memory if needed. (For
> example the settings app would be able to detach the <iframe
> src="main-panel.html"> if the user has finished the activity but,
> instead of going back to the application starts using the back button,
> he/she hits the home button, leaving completely the app to do
> something else.
declare the navigation flow) allows the library to preload those panel
more likely to be accessed.
> 3. Assets needs to be replicated.
> c. Memory overhead for each compartments
>
> I have probably forgot some obvious things, please feel free to add to
> the list!
I think the sandbox attribute is an impediment. I know it solves the
> c. Memory overhead for each compartments
>
> I have probably forgot some obvious things, please feel free to add to
> the list!
problem of freeing the memory not related with the current activity but
it introduces the overhead to reload all the related objects and causes
issue (a). Maybe we could cause the garbage collector to retrieve all
the memory by doing:
1) Encouraging the good practice of not communicate via window.parent /
iframe.contentDocument
2) When the library don't need the iframe, just make its src to ''
(then, eventually detach or reuse)
Furthermore, we could dynamically cut the access to iframe window.parent
(by nullifying it) allowing only Partent -> Children communications /
injections.
>
> For *b2*, *b3*.
> Two things come to my mind:
> - Seamless iframe - https://bugzilla.mozilla.org/show_bug.cgi?id=631218
> - Similarly to JSScript sharing I wonder if some data can be shared
> as well for offline cache/packaged same origin css files ? (obviously
> I don't know much about layout/ and it this is possible).
>
> As far as I understand the specification of the 'seamless' attribute,
> the sub-iframes will inherit the parent rule. If that means the
> style-set rules are shared that would be a good fit to avoid extra
> load time and fit our memory constraints.
+1
> For *b2*, *b3*.
> Two things come to my mind:
> - Seamless iframe - https://bugzilla.mozilla.org/show_bug.cgi?id=631218
> - Similarly to JSScript sharing I wonder if some data can be shared
> as well for offline cache/packaged same origin css files ? (obviously
> I don't know much about layout/ and it this is possible).
>
> As far as I understand the specification of the 'seamless' attribute,
> the sub-iframes will inherit the parent rule. If that means the
> style-set rules are shared that would be a good fit to avoid extra
> load time and fit our memory constraints.
Best.
________________________________
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
Julien Wajsberg
Jun 12, 2013, 4:30:02 PM6/12/13
to tofumatt, dev-...@lists.mozilla.org
Something Vivien has not insisted on, is that lots of developers are
developing on these Gaia apps. In the end, ensuring scoped context is
what will help having consistent and maintenable apps.
Another point is to _not_ use a framework. Trying to be as close as
possible to the real stuff.
About performance, the only way to know is to try it. It's quite sure
that having a less deep DOM tree will help reflows and repaint, but I
agree that we can have unknown penalties too. Let's try on an easy app
(like Clock).
Le 12/06/2013 19:18, tofumatt a écrit :
> So, this flies in the face of the way most front-end developers have been writing client-side web apps since pretty much when that whole business started. It strikes me as very confusing, something that will reload libraries per-"panel" and something that would get very heavy (or be useless) when you have many subviews.
>
> What's the issue with using an approach similar to Backbone or whatever that removes views from memory and templates from the DOM when they are no longer needed? And loading them on-demand? I've been doing that with my Podcasts app for Firefox OS and performance, memory usage, and developer happiness have all been great.
>
> Is this how we want third party developers to write their apps? Frankly, if I looked at a web app and saw code like this I'd run the other way. At all of the hack days I've attended, developers look at gaia on how to write apps. This method seems very odd.
>
> Are there measurable performance gains to this? I'm at a loss as to why this is better than something most client-side MVC frameworks.
>
> - tofumatt | http://tofumatt.com
>
developing on these Gaia apps. In the end, ensuring scoped context is
what will help having consistent and maintenable apps.
Another point is to _not_ use a framework. Trying to be as close as
possible to the real stuff.
About performance, the only way to know is to try it. It's quite sure
that having a less deep DOM tree will help reflows and repaint, but I
agree that we can have unknown penalties too. Let's try on an easy app
(like Clock).
Le 12/06/2013 19:18, tofumatt a écrit :
> So, this flies in the face of the way most front-end developers have been writing client-side web apps since pretty much when that whole business started. It strikes me as very confusing, something that will reload libraries per-"panel" and something that would get very heavy (or be useless) when you have many subviews.
>
> What's the issue with using an approach similar to Backbone or whatever that removes views from memory and templates from the DOM when they are no longer needed? And loading them on-demand? I've been doing that with my Podcasts app for Firefox OS and performance, memory usage, and developer happiness have all been great.
>
> Is this how we want third party developers to write their apps? Frankly, if I looked at a web app and saw code like this I'd run the other way. At all of the hack days I've attended, developers look at gaia on how to write apps. This method seems very odd.
>
> Are there measurable performance gains to this? I'm at a loss as to why this is better than something most client-side MVC frameworks.
>
> - tofumatt | http://tofumatt.com
>
>> I feel like this will address 1., 2. and 3. since the memory used will be directly related to the real user activity and it will be freed once it is done. Also, an application will be able to detach the previous state of the application to save some memory if needed. (For example the settings app would be able to detach the <iframe src="main-panel.html"> if the user has finished the activity but, instead of going back to the application starts using the back button, he/she hits the home button, leaving completely the app to do something else.
>>
>>
>> 1. Will be addressed because nothing else than the main code would be loaded on cold launch. If the app is slow it will be trivial to identify the responsible panel and to fix it.
>>
>> 5. Will be addressed since it will be easy to declare in the manifest which urls correlate with a particular inline activity.
>> 6. Will be addressed since each panels will not be able to access others because of the sandbox. Also, the back button being part of the main app container will ensure the user will always be able to go back and reload the panel to see if it works finally (poor's man solution to race condition, bugs that appear only if your follow a specific code path).
>>
>> About 4. This model will let us get rid of the <!-- html comment --> hack used in different applications as well as a big part of <lazy_loader.js> since only the necessary part of a panel should be loaded with it. Everything that is not vital and can be delayed like getting the list of wifi networks can be loaded using <script async>.
>> As a result Gaia apps will be split in many html files. The directory organization may reflect it.
>>
>> How much is it going to impatc load time of a specific panel? I feel like it should be fast since this is not the equivalent of opening a new process (it has already been opened), but just spawning a new compartment and parse js/css file again (see next paragraph about that).
>>
>> -----------------
>> Possible issues:
>> a. Global states cannot be shared.
>> b. Load time for each panels
>> 1. JavaScript files / libraries needs to be replicated.
>> 2. CSS files need to be replicated.
>>
>> 5. Will be addressed since it will be easy to declare in the manifest which urls correlate with a particular inline activity.
>> 6. Will be addressed since each panels will not be able to access others because of the sandbox. Also, the back button being part of the main app container will ensure the user will always be able to go back and reload the panel to see if it works finally (poor's man solution to race condition, bugs that appear only if your follow a specific code path).
>>
>> About 4. This model will let us get rid of the <!-- html comment --> hack used in different applications as well as a big part of <lazy_loader.js> since only the necessary part of a panel should be loaded with it. Everything that is not vital and can be delayed like getting the list of wifi networks can be loaded using <script async>.
>> As a result Gaia apps will be split in many html files. The directory organization may reflect it.
>>
>> How much is it going to impatc load time of a specific panel? I feel like it should be fast since this is not the equivalent of opening a new process (it has already been opened), but just spawning a new compartment and parse js/css file again (see next paragraph about that).
>>
>> -----------------
>> Possible issues:
>> a. Global states cannot be shared.
>> b. Load time for each panels
>> 1. JavaScript files / libraries needs to be replicated.
>> 2. CSS files need to be replicated.
>> 3. Assets needs to be replicated.
>> c. Memory overhead for each compartments
>>
>> I have probably forgot some obvious things, please feel free to add to the list!
>>
>> c. Memory overhead for each compartments
>>
>> I have probably forgot some obvious things, please feel free to add to the list!
>>
>> -----------------
>> Possible answers:
>> For *a* and *b1*.
>> Four things comes to my mind.
>> - Shared Workers - https://bugzilla.mozilla.org/show_bug.cgi?id=643325
>> - IndexedDB support in Workers - https://bugzilla.mozilla.org/show_bug.cgi?id=701634
>> - Lazy bytecode generation - https://bugzilla.mozilla.org/show_bug.cgi?id=678037
>> - JSScript sharing - https://bugzilla.mozilla.org/show_bug.cgi?id=679940
>>
>> First I feel like states should not be shared between panels, but data should be. I can imagine that there are some cases where some kind of state needs to be shared, but I'm not convinced this is the most common case. Shared worker and indexedDB support in workers should solve many issues and help a lot here. Many different panels would be able to access the worker that will have been loaded once. I cannot tell how glad I am to have seen a recent path on the SharedWorker implementation. bent++.
>>
>> Lazy bytecode generation will help save some startup time / memory. If a utility library is replicated, but some part are not used, that will be less an issue.
>>
>> JSScript sharing. As far as I have understood those sharing of JSScript data is mostly for the self-hosted methods, like Array.map and so on. I wonder if some JSScript data can be shared for scripts with the same mozapp context, same origin as long as they come from offline cache / packaged content.
>>
>> Possible answers:
>> For *a* and *b1*.
>> Four things comes to my mind.
>> - Shared Workers - https://bugzilla.mozilla.org/show_bug.cgi?id=643325
>> - IndexedDB support in Workers - https://bugzilla.mozilla.org/show_bug.cgi?id=701634
>> - Lazy bytecode generation - https://bugzilla.mozilla.org/show_bug.cgi?id=678037
>> - JSScript sharing - https://bugzilla.mozilla.org/show_bug.cgi?id=679940
>>
>> First I feel like states should not be shared between panels, but data should be. I can imagine that there are some cases where some kind of state needs to be shared, but I'm not convinced this is the most common case. Shared worker and indexedDB support in workers should solve many issues and help a lot here. Many different panels would be able to access the worker that will have been loaded once. I cannot tell how glad I am to have seen a recent path on the SharedWorker implementation. bent++.
>>
>> Lazy bytecode generation will help save some startup time / memory. If a utility library is replicated, but some part are not used, that will be less an issue.
>>
>> JSScript sharing. As far as I have understood those sharing of JSScript data is mostly for the self-hosted methods, like Array.map and so on. I wonder if some JSScript data can be shared for scripts with the same mozapp context, same origin as long as they come from offline cache / packaged content.
>>
>> For *b2*, *b3*.
>> Two things come to my mind:
>> - Seamless iframe - https://bugzilla.mozilla.org/show_bug.cgi?id=631218
>> - Similarly to JSScript sharing I wonder if some data can be shared as well for offline cache/packaged same origin css files ? (obviously I don't know much about layout/ and it this is possible).
>>
>> As far as I understand the specification of the 'seamless' attribute, the sub-iframes will inherit the parent rule. If that means the style-set rules are shared that would be a good fit to avoid extra load time and fit our memory constraints.
>>
>> Two things come to my mind:
>> - Seamless iframe - https://bugzilla.mozilla.org/show_bug.cgi?id=631218
>> - Similarly to JSScript sharing I wonder if some data can be shared as well for offline cache/packaged same origin css files ? (obviously I don't know much about layout/ and it this is possible).
>>
>> As far as I understand the specification of the 'seamless' attribute, the sub-iframes will inherit the parent rule. If that means the style-set rules are shared that would be a good fit to avoid extra load time and fit our memory constraints.
>>
Vivien
Jun 12, 2013, 4:43:38 PM6/12/13
to Salvador de la Puente González, dev-...@lists.mozilla.org
Ola!
On 12/06/2013 21:34, Salvador de la Puente González wrote:
>
>>
>> Basically the <navigation.js> helper creates sandbox-ed <iframe>s on
>> demand and handle the navigation, as well as the back button.
>>
>> As long the user navigates forward, new sandbox-ed <iframe>s are
>> created. As soon the user hit the back button the last <iframe> is
>> removed in order to free the relevant part of memory. Since <iframe>s
>> are sandboxed without the allow-same-origin flag, the only way to
>> communicate should be postMessage and data would be serialized that
>> should prevent references to each other and guarantee that the memory
>> will be freed.
two ago and proposed the named quote-quote for this model!
https://bugzilla.mozilla.org/show_bug.cgi?id=730101 (Implement
prerendering in FF). So this is kind of similar to what you propose.
like each panel should be a kind of view that is independent from global
states. IMHO It should be data based and that's where SharedWorker /
IndexedDB comes into play.
Also I'm not that afraid of fixing the platform. The implementation can
be started even if the platform is not fully ready and any platform
fixes would be sugar on top of that. It can be enhance based on the
issues encountered. Let's make the platform better.
like to be 100% confident in the model.
to cut as well.
sub-iframes. Just want to share the generated bytecode if possible.
Vivien.
On 12/06/2013 21:34, Salvador de la Puente González wrote:
>
>>
>> Basically the <navigation.js> helper creates sandbox-ed <iframe>s on
>> demand and handle the navigation, as well as the back button.
>>
>> As long the user navigates forward, new sandbox-ed <iframe>s are
>> created. As soon the user hit the back button the last <iframe> is
>> removed in order to free the relevant part of memory. Since <iframe>s
>> are sandboxed without the allow-same-origin flag, the only way to
>> communicate should be postMessage and data would be serialized that
>> should prevent references to each other and guarantee that the memory
>> will be freed.
> Detaching from DOM is somewhat tricky as it cause a reflow (or, at
> least, a noticeable repaint) but we could set src to '' and reuse empty
> iframes. ,)
Yep that's also an option. Actually Etienne suggest that to me a day or
> least, a noticeable repaint) but we could set src to '' and reuse empty
> iframes. ,)
two ago and proposed the named quote-quote for this model!
>>
>> I feel like this will address 1., 2. and 3. since the memory used will
>> be directly related to the real user activity and it will be freed
>> once it is done. Also, an application will be able to detach the
>> previous state of the application to save some memory if needed. (For
>> example the settings app would be able to detach the <iframe
>> src="main-panel.html"> if the user has finished the activity but,
>> instead of going back to the application starts using the back button,
>> he/she hits the home button, leaving completely the app to do
>> something else.
>> I feel like this will address 1., 2. and 3. since the memory used will
>> be directly related to the real user activity and it will be freed
>> once it is done. Also, an application will be able to detach the
>> previous state of the application to save some memory if needed. (For
>> example the settings app would be able to detach the <iframe
>> src="main-panel.html"> if the user has finished the activity but,
>> instead of going back to the application starts using the back button,
>> he/she hits the home button, leaving completely the app to do
>> something else.
> Optionally, simple declarations of what is next a prev (i.e. some way to
> declare the navigation flow) allows the library to preload those panel
> more likely to be accessed.
I forgot to mention that part of the plan would rely on
> declare the navigation flow) allows the library to preload those panel
> more likely to be accessed.
https://bugzilla.mozilla.org/show_bug.cgi?id=730101 (Implement
prerendering in FF). So this is kind of similar to what you propose.
>
>> 3. Assets needs to be replicated.
>> c. Memory overhead for each compartments
>>
>> I have probably forgot some obvious things, please feel free to add to
>> the list!
>> 3. Assets needs to be replicated.
>> c. Memory overhead for each compartments
>>
>> I have probably forgot some obvious things, please feel free to add to
>> the list!
> I think the sandbox attribute is an impediment. I know it solves the
> problem of freeing the memory not related with the current activity but
> it introduces the overhead to reload all the related objects and causes
> issue (a). Maybe we could cause the garbage collector to retrieve all
> the memory by doing:
'related objects' is exactly one of the issue I want to tackle. I feel
> problem of freeing the memory not related with the current activity but
> it introduces the overhead to reload all the related objects and causes
> issue (a). Maybe we could cause the garbage collector to retrieve all
> the memory by doing:
like each panel should be a kind of view that is independent from global
states. IMHO It should be data based and that's where SharedWorker /
IndexedDB comes into play.
Also I'm not that afraid of fixing the platform. The implementation can
be started even if the platform is not fully ready and any platform
fixes would be sugar on top of that. It can be enhance based on the
issues encountered. Let's make the platform better.
>
> 1) Encouraging the good practice of not communicate via window.parent /
> iframe.contentDocument
This is way too easy to do a mistake in JS in my opinion and I would
> 1) Encouraging the good practice of not communicate via window.parent /
> iframe.contentDocument
like to be 100% confident in the model.
>
> 2) When the library don't need the iframe, just make its src to ''
> (then, eventually detach or reuse)
>
> Furthermore, we could dynamically cut the access to iframe window.parent
> (by nullifying it) allowing only Partent -> Children communications /
> injections.
Parent -> children injections can create some dependencies I would like
> 2) When the library don't need the iframe, just make its src to ''
> (then, eventually detach or reuse)
>
> Furthermore, we could dynamically cut the access to iframe window.parent
> (by nullifying it) allowing only Partent -> Children communications /
> injections.
to cut as well.
> You mean like a "JavaScript seamless"?
Not exactly. I don't want to expose the object of the parent inside the
sub-iframes. Just want to share the generated bytecode if possible.
Vivien.
James Burke
Jun 12, 2013, 4:59:21 PM6/12/13
to Vivien, dev-...@lists.mozilla.org
I believe the iframes will be more expensive than just using modular
code with HTML templates and data binding. There are a few ways to go
about that, some even future web platform-related (see summary at
end). Here is one:
I have done working experiments along those lines in the email app in
this branch:
https://github.com/jrburke/gaia/tree/groupload-htmlinabox
That experiment splits all the code into modules and has a mechanism
to save the startup HTML in a cookie. As it is a code retrofit, it is
not as modularly clean as I would prefer, but a good first pass that
tries to minimize diffs to make review easier.
On cold launch, it just inserts that saved HTML into the DOM. It is
quite fast (700ms range, and as actual HTML, not just a fakeout of the
"app load" event), and the app has control over what HTML it chooses
to save.
This experiment goes further:
https://github.com/jrburke/carmino
Each card is represented by a module with an HTML template. The card
module does not bind events, but instead, the card controller uses
event delegation to pass events to the card module. This means that
when the HTML is rehydrated from storage, all the card controller has
to do is
Also, the HTML uses fragment IDs to indicate what card module will be
triggered by an action, like '#list-detail', and data can be passed
via querystring-link arguments in that string.
This allows the card controller to scan the DOM of the just inserted
card and find the "next card" modules by looking for those IDs, and
lazy load them in the background. This allows for quick transitions,
but delayed loading of code. Loading a card module does not trigger an
HTML insertion, just defines the module, so the cost of loading the
next actions are low.
Furthermore, by using AMD modules with a loader plugin, the HTML
templates can be inlined as either HTML strings or as compiled JS
functions in build layers. Since the build tool can scan module
relationships, it is easier to work out build layers without having to
know the full dependency chain.
I used that approach in the email experiment to inline the card
modules for the first two possible cards as part of the startup layer.
For both of those experiments, by using modular code and a "cards"
controller I believe it will give similar benefits but be lighter
weight over all since iframes are not in play. Some further details
below:
On Wed, Jun 12, 2013 at 7:06 AM, Vivien <vnic...@mozilla.com> wrote:
> Hello folks,
>
> Last year or so many Gaia apps has been built using a framework-less based
> approach, using a combination of libraries + css building blocks.
> In parallel, during last year a lot of things has been learned about device
> constraints, mobile constraints, app constraints, cross-teams-work
> constraints.
>
> -----------------
> Based on this here are some of those constraints (some are already partially
> solved) I would like to reach primarily:
> 1. *Fast loading application*
> Andreas said it a few times already. Apps should load in less than 600ms.
This approach does not guarantee faster loading, and due to the iframe
usage, could lead to more resource use, depending on how much is in
the iframe. The blockers to me on fast startup have been:
1) Async storage means waiting on the event loop to make first card
choice if that choice depends on app data. However, the event loop is
clogged because the platform wants to paint. That, with the
screenshotting at inopportune times cost 200ms of startup.
I believe this was also reflected in the "IndexedDB is slow" thread a
while back -- the DB was not slow, but there was other things in the
event loop clogging it up.
By hiding the app's iframe and avoiding the screenshot until it
considers itself truly loaded saved on that time.
2) This was a few months ago now, but I measured about 300ms from app
launch before my app JS could do any work. Reducing that cost would
help all apps.
I believe the HTML reserialization from cookie storage mitigates those
issues by cramming in some HTML synchronously as soon as possible. But
getting platform changes would be even sweeter.
> 2. *Low memory consumption*
> The memory of the device is limited. A limited number of applications can
> run at the same time. Less memory used means more applications can run at
> the same time.
Modules will be cheaper than iframes.
> 3. *Stable memory consumption*
> It is OK to consume an extra memory while making a particular task of an
> application. But this memory needs to be freed once the task has been
> finished.
Hopefully by using a module "singleton" for each card type and using
event delegation in the card controller, it should control memory
well, leaving the rest to garbage collection. The card controller
removes the HTML for cards in the "forward" section once the user goes
back.
> 4. *Smooth panel transitions*
> Transitions should happen really quick after a hit on a button. Ideally a
> panel should be fully loaded when the transition is complete, but it sounds
> OK if informations such as the list of wifi networks around, loads delayed.
This works well in the approach I mention above: there is delayed
loading of card modules, but next action card modules get preloaded at
the end of the current card insertion, making the transition fast.
> 5. *Inline activities friendly*
> The whole application should not be required to be loaded for handling a
> particular operation.
The card controller can process the web activity and dynamically load
the right card module based on that information.
> 6. *Scoped Panels*
> Panels should be independent. So a panel is directly responsible of its
> own load time and of any JS breakage it can generate. Also, an individual
> panel should not be able to break the application. Different authors can
> work on the same application and each of them would be directly responsible
> of one or many panels.
I believe modules give good scoping behavior. The event delegation
means that the card controller is routing events vs the panels, so if
a panel messes up its bindings, as long as the HTML shows up, the user
can usually get "back".
--- summary ---
To echo tofumatt's feedback, the iframe approach is also very
non-standard -- not what web developers do today, and looking to the
future, hard to see how it would fit in.
Non-standard would be fine (anything new is non-standard), but at this
point, if gaia will be doing speculative work, I would rather see it
use future platform aspects and work out the issues with them as they
are likely to be more relevant in the future. Things like modules, web
components, Object.observe, maybe even model driven views. We will do
the web platform more service by doing so.
What I do think would help is just embracing a card-based framework
already. This is effectively what this thread is proposing. There will
need to be a standard library to manage the card transitions and card
communication. This is not an unopinionated choice. I think that is
fine, because we want uniformity in the apps, and having some common
modules/classes handling lifecycle events uniformly and directing
traffic.
So some sort of card controller is a great idea, and having cards fit
into a model with lifecycle events/callbacks will make a big
difference. Modules too. Ones that can be dynamically loaded, and a
build system that understands them. Modules are coming anyway, and
even using AMD modules for today while we wait for ES6 means some easy
static transforms when ES modules come online. Particularly since AMD
modules have great build support, and will be adapted to the future to
parse ES modules.
For any route though, I expect the way to find a common solution is to
work with a specific app first, and convert it. The changes should be
done based on data -- doing a change and seeing if it holds
performance and has good developer ergonomics. I am hopeful I can land
some of the ideas of the experiments in the email app, but of course
that is gated by the keepers of gaia, the appropriateness of the fix,
and schedule.
James
code with HTML templates and data binding. There are a few ways to go
about that, some even future web platform-related (see summary at
end). Here is one:
I have done working experiments along those lines in the email app in
this branch:
https://github.com/jrburke/gaia/tree/groupload-htmlinabox
That experiment splits all the code into modules and has a mechanism
to save the startup HTML in a cookie. As it is a code retrofit, it is
not as modularly clean as I would prefer, but a good first pass that
tries to minimize diffs to make review easier.
On cold launch, it just inserts that saved HTML into the DOM. It is
quite fast (700ms range, and as actual HTML, not just a fakeout of the
"app load" event), and the app has control over what HTML it chooses
to save.
This experiment goes further:
https://github.com/jrburke/carmino
Each card is represented by a module with an HTML template. The card
module does not bind events, but instead, the card controller uses
event delegation to pass events to the card module. This means that
when the HTML is rehydrated from storage, all the card controller has
to do is
Also, the HTML uses fragment IDs to indicate what card module will be
triggered by an action, like '#list-detail', and data can be passed
via querystring-link arguments in that string.
This allows the card controller to scan the DOM of the just inserted
card and find the "next card" modules by looking for those IDs, and
lazy load them in the background. This allows for quick transitions,
but delayed loading of code. Loading a card module does not trigger an
HTML insertion, just defines the module, so the cost of loading the
next actions are low.
Furthermore, by using AMD modules with a loader plugin, the HTML
templates can be inlined as either HTML strings or as compiled JS
functions in build layers. Since the build tool can scan module
relationships, it is easier to work out build layers without having to
know the full dependency chain.
I used that approach in the email experiment to inline the card
modules for the first two possible cards as part of the startup layer.
For both of those experiments, by using modular code and a "cards"
controller I believe it will give similar benefits but be lighter
weight over all since iframes are not in play. Some further details
below:
On Wed, Jun 12, 2013 at 7:06 AM, Vivien <vnic...@mozilla.com> wrote:
> Hello folks,
>
> Last year or so many Gaia apps has been built using a framework-less based
> approach, using a combination of libraries + css building blocks.
> In parallel, during last year a lot of things has been learned about device
> constraints, mobile constraints, app constraints, cross-teams-work
> constraints.
>
> -----------------
> Based on this here are some of those constraints (some are already partially
> solved) I would like to reach primarily:
> 1. *Fast loading application*
> Andreas said it a few times already. Apps should load in less than 600ms.
usage, could lead to more resource use, depending on how much is in
the iframe. The blockers to me on fast startup have been:
1) Async storage means waiting on the event loop to make first card
choice if that choice depends on app data. However, the event loop is
clogged because the platform wants to paint. That, with the
screenshotting at inopportune times cost 200ms of startup.
I believe this was also reflected in the "IndexedDB is slow" thread a
while back -- the DB was not slow, but there was other things in the
event loop clogging it up.
By hiding the app's iframe and avoiding the screenshot until it
considers itself truly loaded saved on that time.
2) This was a few months ago now, but I measured about 300ms from app
launch before my app JS could do any work. Reducing that cost would
help all apps.
I believe the HTML reserialization from cookie storage mitigates those
issues by cramming in some HTML synchronously as soon as possible. But
getting platform changes would be even sweeter.
> 2. *Low memory consumption*
> The memory of the device is limited. A limited number of applications can
> run at the same time. Less memory used means more applications can run at
> the same time.
> 3. *Stable memory consumption*
> It is OK to consume an extra memory while making a particular task of an
> application. But this memory needs to be freed once the task has been
> finished.
event delegation in the card controller, it should control memory
well, leaving the rest to garbage collection. The card controller
removes the HTML for cards in the "forward" section once the user goes
back.
> 4. *Smooth panel transitions*
> Transitions should happen really quick after a hit on a button. Ideally a
> panel should be fully loaded when the transition is complete, but it sounds
> OK if informations such as the list of wifi networks around, loads delayed.
loading of card modules, but next action card modules get preloaded at
the end of the current card insertion, making the transition fast.
> 5. *Inline activities friendly*
> The whole application should not be required to be loaded for handling a
> particular operation.
the right card module based on that information.
> 6. *Scoped Panels*
> Panels should be independent. So a panel is directly responsible of its
> own load time and of any JS breakage it can generate. Also, an individual
> panel should not be able to break the application. Different authors can
> work on the same application and each of them would be directly responsible
> of one or many panels.
means that the card controller is routing events vs the panels, so if
a panel messes up its bindings, as long as the HTML shows up, the user
can usually get "back".
--- summary ---
To echo tofumatt's feedback, the iframe approach is also very
non-standard -- not what web developers do today, and looking to the
future, hard to see how it would fit in.
Non-standard would be fine (anything new is non-standard), but at this
point, if gaia will be doing speculative work, I would rather see it
use future platform aspects and work out the issues with them as they
are likely to be more relevant in the future. Things like modules, web
components, Object.observe, maybe even model driven views. We will do
the web platform more service by doing so.
What I do think would help is just embracing a card-based framework
already. This is effectively what this thread is proposing. There will
need to be a standard library to manage the card transitions and card
communication. This is not an unopinionated choice. I think that is
fine, because we want uniformity in the apps, and having some common
modules/classes handling lifecycle events uniformly and directing
traffic.
So some sort of card controller is a great idea, and having cards fit
into a model with lifecycle events/callbacks will make a big
difference. Modules too. Ones that can be dynamically loaded, and a
build system that understands them. Modules are coming anyway, and
even using AMD modules for today while we wait for ES6 means some easy
static transforms when ES modules come online. Particularly since AMD
modules have great build support, and will be adapted to the future to
parse ES modules.
For any route though, I expect the way to find a common solution is to
work with a specific app first, and convert it. The changes should be
done based on data -- doing a change and seeing if it holds
performance and has good developer ergonomics. I am hopeful I can land
some of the ideas of the experiments in the email app, but of course
that is gated by the keepers of gaia, the appropriateness of the fix,
and schedule.
James
Vivien
Jun 12, 2013, 5:07:28 PM6/12/13
to Kevin Grandon, dev-...@lists.mozilla.org
On 12/06/2013 20:05, Kevin Grandon wrote:
> The iframes are a nice trick, but do we *really* want to code that way, and set this as an example for third-party developers?
Not my goal to tackle this. Fixing the platform/Gaia is already a big
> The iframes are a nice trick, but do we *really* want to code that way, and set this as an example for third-party developers?
enough - full time job! There are others team that are completely
dedicated to apps and developers ecosystem. Let's fix the platform and
found what's wrong there in order to let third party developers create
their own framework / set of tools.
>
> I'm honestly really happy with the way we do things in the calendar app today. We lazy-load templates on demand from separate files. Right now these templates are hand coded in javascript, but it would be pretty trivial to use some build step to convert HTML files into templates if desired.
I do have some questions:
> I'm honestly really happy with the way we do things in the calendar app today. We lazy-load templates on demand from separate files. Right now these templates are hand coded in javascript, but it would be pretty trivial to use some build step to convert HTML files into templates if desired.
- Do you know how much memory is consumed by the calendar app at
startup versus how much is really needed at startup?
- Do you know if memory is fully freed when an activity is finished?
How much guarantee do you have here?
- The calendar app does not have any activities. But do you expect to
load the full app is you want to support an inline activity to create an
event?
- Same thing for system message, alarm. Is there any good reason to
load the full app here?
I honestly don't know if the calendar app reach all those but I feel
like this it is hard to reach. And even if you reach all those points,
it is still hard to ensure at the whole Gaia level. Having some simple
rules would format all apps in such a way that those points would
(hopefully) be guaranteed by design.
Not saying my proposal is the final way to tackle this btw - this is an
untested proposal after all :)
> Best,
> Kevin
>
> ----- Original Message -----
> From: "Vivien" <vnic...@mozilla.com>
> To: dev-...@lists.mozilla.org
> Sent: Wednesday, June 12, 2013 7:06:06 AM
> Subject: Proposition of an architectural change for Gaia apps
>
> Kevin
>
> ----- Original Message -----
> From: "Vivien" <vnic...@mozilla.com>
> To: dev-...@lists.mozilla.org
> Sent: Wednesday, June 12, 2013 7:06:06 AM
> Subject: Proposition of an architectural change for Gaia apps
>
> Hello folks,
>
> Last year or so many Gaia apps has been built using a framework-less
> based approach, using a combination of libraries + css building blocks.
> In parallel, during last year a lot of things has been learned about
> device constraints, mobile constraints, app constraints,
> cross-teams-work constraints.
>
> -----------------
> Based on this here are some of those constraints (some are already
> partially solved) I would like to reach primarily:
> 1. *Fast loading application*
> Andreas said it a few times already. Apps should load in less than 600ms.
>
>
> Last year or so many Gaia apps has been built using a framework-less
> based approach, using a combination of libraries + css building blocks.
> In parallel, during last year a lot of things has been learned about
> device constraints, mobile constraints, app constraints,
> cross-teams-work constraints.
>
> -----------------
> Based on this here are some of those constraints (some are already
> partially solved) I would like to reach primarily:
> 1. *Fast loading application*
> Andreas said it a few times already. Apps should load in less than 600ms.
>
> 2. *Low memory consumption*
> The memory of the device is limited. A limited number of applications
> can run at the same time. Less memory used means more applications can
> run at the same time.
>
> The memory of the device is limited. A limited number of applications
> can run at the same time. Less memory used means more applications can
> run at the same time.
>
> 3. *Stable memory consumption*
> It is OK to consume an extra memory while making a particular task of
> an application. But this memory needs to be freed once the task has been
> finished.
>
> It is OK to consume an extra memory while making a particular task of
> an application. But this memory needs to be freed once the task has been
> finished.
>
> 4. *Smooth panel transitions*
> Transitions should happen really quick after a hit on a button.
> Ideally a panel should be fully loaded when the transition is complete,
> but it sounds OK if informations such as the list of wifi networks
> around, loads delayed.
>
> Transitions should happen really quick after a hit on a button.
> Ideally a panel should be fully loaded when the transition is complete,
> but it sounds OK if informations such as the list of wifi networks
> around, loads delayed.
>
> 5. *Inline activities friendly*
> The whole application should not be required to be loaded for
> handling a particular operation.
>
> The whole application should not be required to be loaded for
> handling a particular operation.
>
> 6. *Scoped Panels*
> Panels should be independent. So a panel is directly responsible of
> its own load time and of any JS breakage it can generate. Also, an
> individual panel should not be able to break the application. Different
> authors can work on the same application and each of them would be
> directly responsible of one or many panels.
>
> Panels should be independent. So a panel is directly responsible of
> its own load time and of any JS breakage it can generate. Also, an
> individual panel should not be able to break the application. Different
> authors can work on the same application and each of them would be
> directly responsible of one or many panels.
>
> Basically the <navigation.js> helper creates sandbox-ed <iframe>s on
> demand and handle the navigation, as well as the back button.
>
> As long the user navigates forward, new sandbox-ed <iframe>s are
> created. As soon the user hit the back button the last <iframe> is
> removed in order to free the relevant part of memory. Since <iframe>s
> are sandboxed without the allow-same-origin flag, the only way to
> communicate should be postMessage and data would be serialized that
> should prevent references to each other and guarantee that the memory
> will be freed.
>
> demand and handle the navigation, as well as the back button.
>
> As long the user navigates forward, new sandbox-ed <iframe>s are
> created. As soon the user hit the back button the last <iframe> is
> removed in order to free the relevant part of memory. Since <iframe>s
> are sandboxed without the allow-same-origin flag, the only way to
> communicate should be postMessage and data would be serialized that
> should prevent references to each other and guarantee that the memory
> will be freed.
>
> I feel like this will address 1., 2. and 3. since the memory used will
> be directly related to the real user activity and it will be freed once
> it is done. Also, an application will be able to detach the previous
> state of the application to save some memory if needed. (For example the
> settings app would be able to detach the <iframe src="main-panel.html">
> if the user has finished the activity but, instead of going back to the
> application starts using the back button, he/she hits the home button,
> leaving completely the app to do something else.
>
> be directly related to the real user activity and it will be freed once
> it is done. Also, an application will be able to detach the previous
> state of the application to save some memory if needed. (For example the
> settings app would be able to detach the <iframe src="main-panel.html">
> if the user has finished the activity but, instead of going back to the
> application starts using the back button, he/she hits the home button,
> leaving completely the app to do something else.
>
> 3. Assets needs to be replicated.
> c. Memory overhead for each compartments
>
> I have probably forgot some obvious things, please feel free to add to
> the list!
>
> c. Memory overhead for each compartments
>
> I have probably forgot some obvious things, please feel free to add to
> the list!
>
Matt Claypotch
Jun 12, 2013, 7:54:01 PM6/12/13
to James Burke, Vivien, dev-...@lists.mozilla.org
I agree with James' notion that creating an iframe-based approach and using
it extensively within Gaia apps *is* making a framework. There will be
shared code or patterns. Worse, the framework you're making is a *new*
framework, which doesn't benefit from the stability that comes from wider
usage. Look at buildingfirefoxos- if you don't release a standard form of
styles/code, someone will use your code as an example anyway.
I understand the desire to stay close to the metal. But rewriting the same
thing over and over (or more accurately, slightly differently every time)
isn't making development easier, and makes it harder to approach from
outside developers. I'm afraid I simply don't understand the vehement
allergy to the notion of abstracting repeated tasks into some even *basic*
loosely coupled app-development framework, even if it were only cleared for
internal gaia usage.
As for the iframe-based approach itself- I'm all for unorthodox if it leads
to performance wins, but that is some funky stuff. That said, it does hit
upon the 'card' based UI that James mentioned, and something we're working
on with x-tags. In particular, the notion of a 'deck' tag that can contain
multiple panes. In the coming week or two, we should have a demo of a
working deck-based app.
Last, I'd direct people to check out the current Marketplace app- great
scrolling performance and snappy UI on Keon-grade devices. They're using a
template-based approach with deferred rendering of data that needs to be
fetched asynchronously. A great success story, and I know the frontend team
is working on abstracting out the core for usage on other apps.
~potch
it extensively within Gaia apps *is* making a framework. There will be
shared code or patterns. Worse, the framework you're making is a *new*
framework, which doesn't benefit from the stability that comes from wider
usage. Look at buildingfirefoxos- if you don't release a standard form of
styles/code, someone will use your code as an example anyway.
I understand the desire to stay close to the metal. But rewriting the same
thing over and over (or more accurately, slightly differently every time)
isn't making development easier, and makes it harder to approach from
outside developers. I'm afraid I simply don't understand the vehement
allergy to the notion of abstracting repeated tasks into some even *basic*
loosely coupled app-development framework, even if it were only cleared for
internal gaia usage.
As for the iframe-based approach itself- I'm all for unorthodox if it leads
to performance wins, but that is some funky stuff. That said, it does hit
upon the 'card' based UI that James mentioned, and something we're working
on with x-tags. In particular, the notion of a 'deck' tag that can contain
multiple panes. In the coming week or two, we should have a demo of a
working deck-based app.
Last, I'd direct people to check out the current Marketplace app- great
scrolling performance and snappy UI on Keon-grade devices. They're using a
template-based approach with deferred rendering of data that needs to be
fetched asynchronously. A great success story, and I know the frontend team
is working on abstracting out the core for usage on other apps.
~potch
> > Hello folks,
> >
> > Last year or so many Gaia apps has been built using a framework-less
> based
> > approach, using a combination of libraries + css building blocks.
> > In parallel, during last year a lot of things has been learned about
> device
> > constraints, mobile constraints, app constraints, cross-teams-work
> > constraints.
> >
> > -----------------
> > Based on this here are some of those constraints (some are already
> partially
> > solved) I would like to reach primarily:
> > 1. *Fast loading application*
> > Andreas said it a few times already. Apps should load in less than
> 600ms.
>
> >
> > Last year or so many Gaia apps has been built using a framework-less
> based
> > approach, using a combination of libraries + css building blocks.
> > In parallel, during last year a lot of things has been learned about
> device
> > constraints, mobile constraints, app constraints, cross-teams-work
> > constraints.
> >
> > -----------------
> > Based on this here are some of those constraints (some are already
> partially
> > solved) I would like to reach primarily:
> > 1. *Fast loading application*
> > Andreas said it a few times already. Apps should load in less than
> 600ms.
>
> This approach does not guarantee faster loading, and due to the iframe
> usage, could lead to more resource use, depending on how much is in
> the iframe. The blockers to me on fast startup have been:
>
> 1) Async storage means waiting on the event loop to make first card
> choice if that choice depends on app data. However, the event loop is
> clogged because the platform wants to paint. That, with the
> screenshotting at inopportune times cost 200ms of startup.
>
> I believe this was also reflected in the "IndexedDB is slow" thread a
> while back -- the DB was not slow, but there was other things in the
> event loop clogging it up.
>
> By hiding the app's iframe and avoiding the screenshot until it
> considers itself truly loaded saved on that time.
>
> 2) This was a few months ago now, but I measured about 300ms from app
> launch before my app JS could do any work. Reducing that cost would
> help all apps.
>
> I believe the HTML reserialization from cookie storage mitigates those
> issues by cramming in some HTML synchronously as soon as possible. But
> getting platform changes would be even sweeter.
>
> usage, could lead to more resource use, depending on how much is in
> the iframe. The blockers to me on fast startup have been:
>
> 1) Async storage means waiting on the event loop to make first card
> choice if that choice depends on app data. However, the event loop is
> clogged because the platform wants to paint. That, with the
> screenshotting at inopportune times cost 200ms of startup.
>
> I believe this was also reflected in the "IndexedDB is slow" thread a
> while back -- the DB was not slow, but there was other things in the
> event loop clogging it up.
>
> By hiding the app's iframe and avoiding the screenshot until it
> considers itself truly loaded saved on that time.
>
> 2) This was a few months ago now, but I measured about 300ms from app
> launch before my app JS could do any work. Reducing that cost would
> help all apps.
>
> I believe the HTML reserialization from cookie storage mitigates those
> issues by cramming in some HTML synchronously as soon as possible. But
> getting platform changes would be even sweeter.
>
> > 2. *Low memory consumption*
> > The memory of the device is limited. A limited number of applications
> can
> > run at the same time. Less memory used means more applications can run at
> > the same time.
>
> > The memory of the device is limited. A limited number of applications
> can
> > run at the same time. Less memory used means more applications can run at
> > the same time.
>
> Modules will be cheaper than iframes.
>
>
> > 3. *Stable memory consumption*
> > It is OK to consume an extra memory while making a particular task of
> an
> > application. But this memory needs to be freed once the task has been
> > finished.
>
> > It is OK to consume an extra memory while making a particular task of
> an
> > application. But this memory needs to be freed once the task has been
> > finished.
>
> Hopefully by using a module "singleton" for each card type and using
> event delegation in the card controller, it should control memory
> well, leaving the rest to garbage collection. The card controller
> removes the HTML for cards in the "forward" section once the user goes
> back.
>
> event delegation in the card controller, it should control memory
> well, leaving the rest to garbage collection. The card controller
> removes the HTML for cards in the "forward" section once the user goes
> back.
>
> > 4. *Smooth panel transitions*
> > Transitions should happen really quick after a hit on a button.
> Ideally a
> > panel should be fully loaded when the transition is complete, but it
> sounds
> > OK if informations such as the list of wifi networks around, loads
> delayed.
>
> > Transitions should happen really quick after a hit on a button.
> Ideally a
> > panel should be fully loaded when the transition is complete, but it
> sounds
> > OK if informations such as the list of wifi networks around, loads
> delayed.
>
> This works well in the approach I mention above: there is delayed
> loading of card modules, but next action card modules get preloaded at
> the end of the current card insertion, making the transition fast.
>
> loading of card modules, but next action card modules get preloaded at
> the end of the current card insertion, making the transition fast.
>
> > 5. *Inline activities friendly*
> > The whole application should not be required to be loaded for handling
> a
> > particular operation.
>
> > The whole application should not be required to be loaded for handling
> a
> > particular operation.
>
> The card controller can process the web activity and dynamically load
> the right card module based on that information.
>
> the right card module based on that information.
>
> > 6. *Scoped Panels*
> > Panels should be independent. So a panel is directly responsible of its
> > own load time and of any JS breakage it can generate. Also, an individual
> > panel should not be able to break the application. Different authors can
> > work on the same application and each of them would be directly
> responsible
> > of one or many panels.
>
> > Panels should be independent. So a panel is directly responsible of its
> > own load time and of any JS breakage it can generate. Also, an individual
> > panel should not be able to break the application. Different authors can
> > work on the same application and each of them would be directly
> responsible
> > of one or many panels.
>
Matt Claypotch
Jun 12, 2013, 7:55:10 PM6/12/13
to James Burke, Vivien, dev-...@lists.mozilla.org
Matt Claypotch
Jun 12, 2013, 8:02:03 PM6/12/13
to Julien Wajsberg, tofumatt, dev-...@lists.mozilla.org
On Wed, Jun 12, 2013 at 1:30 PM, Julien Wajsberg <jwaj...@mozilla.com>wrote:
> Something Vivien has not insisted on, is that lots of developers are
> developing on these Gaia apps. In the end, ensuring scoped context is
> what will help having consistent and maintenable apps.
>
> Another point is to _not_ use a framework. Trying to be as close as
> possible to the real stuff.
>
I'll bite. Why _not_ use a framework? Why would you not encapsulate all
> Something Vivien has not insisted on, is that lots of developers are
> developing on these Gaia apps. In the end, ensuring scoped context is
> what will help having consistent and maintenable apps.
>
> Another point is to _not_ use a framework. Trying to be as close as
> possible to the real stuff.
>
your repeated best practices in a place where they all don't have to be
repeated by the next person to touch the code? I haven't heard a compelling
reason why a framework shouldn't be used.
>
> About performance, the only way to know is to try it. It's quite sure
> that having a less deep DOM tree will help reflows and repaint, but I
> agree that we can have unknown penalties too. Let's try on an easy app
> (like Clock).
>
> Le 12/06/2013 19:18, tofumatt a écrit :
> > So, this flies in the face of the way most front-end developers have
> been writing client-side web apps since pretty much when that whole
> business started. It strikes me as very confusing, something that will
> reload libraries per-"panel" and something that would get very heavy (or be
> useless) when you have many subviews.
> >
> > What's the issue with using an approach similar to Backbone or whatever
> that removes views from memory and templates from the DOM when they are no
> longer needed? And loading them on-demand? I've been doing that with my
> Podcasts app for Firefox OS and performance, memory usage, and developer
> happiness have all been great.
> >
> > Is this how we want third party developers to write their apps? Frankly,
> if I looked at a web app and saw code like this I'd run the other way. At
> all of the hack days I've attended, developers look at gaia on how to write
> apps. This method seems very odd.
> >
> > Are there measurable performance gains to this? I'm at a loss as to why
> this is better than something most client-side MVC frameworks.
> >
> > - tofumatt | http://tofumatt.com
> >
> > On 2013-06-12, at 10:06 AM, Vivien <vnic...@mozilla.com> wrote:
> >
> >> Hello folks,
> >>
> >> Last year or so many Gaia apps has been built using a framework-less
> based approach, using a combination of libraries + css building blocks.
> >> In parallel, during last year a lot of things has been learned about
> device constraints, mobile constraints, app constraints, cross-teams-work
> constraints.
> >>
> >> -----------------
> >> Based on this here are some of those constraints (some are already
> partially solved) I would like to reach primarily:
> >> 1. *Fast loading application*
> >> Andreas said it a few times already. Apps should load in less than
> 600ms.
> >>
> >
> >> Hello folks,
> >>
> >> Last year or so many Gaia apps has been built using a framework-less
> based approach, using a combination of libraries + css building blocks.
> >> In parallel, during last year a lot of things has been learned about
> device constraints, mobile constraints, app constraints, cross-teams-work
> constraints.
> >>
> >> -----------------
> >> Based on this here are some of those constraints (some are already
> partially solved) I would like to reach primarily:
> >> 1. *Fast loading application*
> >> Andreas said it a few times already. Apps should load in less than
> 600ms.
> >>
> >> 2. *Low memory consumption*
> >> The memory of the device is limited. A limited number of applications
> can run at the same time. Less memory used means more applications can run
> at the same time.
> >>
> >> The memory of the device is limited. A limited number of applications
> can run at the same time. Less memory used means more applications can run
> at the same time.
> >>
> >> 3. *Stable memory consumption*
> >> It is OK to consume an extra memory while making a particular task of
> an application. But this memory needs to be freed once the task has been
> finished.
> >>
> >> It is OK to consume an extra memory while making a particular task of
> an application. But this memory needs to be freed once the task has been
> finished.
> >>
> >> 4. *Smooth panel transitions*
> >> Transitions should happen really quick after a hit on a button.
> Ideally a panel should be fully loaded when the transition is complete, but
> it sounds OK if informations such as the list of wifi networks around,
> loads delayed.
> >>
> >> Transitions should happen really quick after a hit on a button.
> Ideally a panel should be fully loaded when the transition is complete, but
> it sounds OK if informations such as the list of wifi networks around,
> loads delayed.
> >>
> >> 5. *Inline activities friendly*
> >> The whole application should not be required to be loaded for handling
> a particular operation.
> >>
> >> The whole application should not be required to be loaded for handling
> a particular operation.
> >>
> >> 6. *Scoped Panels*
> >> Panels should be independent. So a panel is directly responsible of
> its own load time and of any JS breakage it can generate. Also, an
> individual panel should not be able to break the application. Different
> authors can work on the same application and each of them would be directly
> responsible of one or many panels.
> >>
> >> Panels should be independent. So a panel is directly responsible of
> its own load time and of any JS breakage it can generate. Also, an
> individual panel should not be able to break the application. Different
> authors can work on the same application and each of them would be directly
> responsible of one or many panels.
> >>
tofumatt
Jun 12, 2013, 8:06:13 PM6/12/13
to Matt Claypotch, Julien Wajsberg, dev-...@lists.mozilla.org
Right. It should be made clear, that jQuery is not a framework. Using something like Backbone.js in gaia doesn't prevent us from being close to the metal (I'd know, I've wrote two apps for FxOS with that setup, including a Podcasts app that extensively uses a lot of "stock" JS), but simply allows common tasks to be abstracted and a design pattern across apps.
Gaia code is harder to work on and will not benefit from the help of many outside web developers as long as it eschews any form of abstraction, as it will simply be too much to absorb for most front-end web developers, good as they may be.
- tofumatt | http://tofumatt.com
Gaia code is harder to work on and will not benefit from the help of many outside web developers as long as it eschews any form of abstraction, as it will simply be too much to absorb for most front-end web developers, good as they may be.
- tofumatt | http://tofumatt.com
Salvador de la Puente González
Jun 13, 2013, 3:29:44 AM6/13/13
to tofumatt, Matt Claypotch, dev-...@lists.mozilla.org, Julien Wajsberg
Hello folks
We should throw framework panic away once forever. Nobody is encouraging
to use heavy overhead frameworks but gathering best practices and
offering a model to work on. It is only another step further than the
utilities or mock modules from shared. The framework, in addition,
should offer a secure, fast, device-friendly way of working.
We should throw framework panic away once forever. Nobody is encouraging
to use heavy overhead frameworks but gathering best practices and
offering a model to work on. It is only another step further than the
utilities or mock modules from shared. The framework, in addition,
should offer a secure, fast, device-friendly way of working.
Salvador de la Puente González
Jun 13, 2013, 3:34:50 AM6/13/13
to Vivien, dev-...@lists.mozilla.org
Hi Vivien
I'm applying TDD in order to refactor Cost Control and (at the current
moment), I only have a couple of blockers. I mean I almost free of heavy
duty. In addition, Cost Control has several panels with extensive
options and a lot of work on settings and the extra challenges of
keeping synced two different views in different processes. Do you want
to try these ideas with the Cost Control application?
Cheers.
On 12/06/13 22:43, Vivien wrote:
> Ola!
>
> On 12/06/2013 21:34, Salvador de la Puente González wrote:
>>
>>>
I'm applying TDD in order to refactor Cost Control and (at the current
moment), I only have a couple of blockers. I mean I almost free of heavy
duty. In addition, Cost Control has several panels with extensive
options and a lot of work on settings and the extra challenges of
keeping synced two different views in different processes. Do you want
to try these ideas with the Cost Control application?
Cheers.
On 12/06/13 22:43, Vivien wrote:
> Ola!
>
> On 12/06/2013 21:34, Salvador de la Puente González wrote:
>>
>>>
>>> Basically the <navigation.js> helper creates sandbox-ed <iframe>s on
>>> demand and handle the navigation, as well as the back button.
>>>
>>> As long the user navigates forward, new sandbox-ed <iframe>s are
>>> created. As soon the user hit the back button the last <iframe> is
>>> removed in order to free the relevant part of memory. Since <iframe>s
>>> are sandboxed without the allow-same-origin flag, the only way to
>>> communicate should be postMessage and data would be serialized that
>>> should prevent references to each other and guarantee that the memory
>>> will be freed.
>>> demand and handle the navigation, as well as the back button.
>>>
>>> As long the user navigates forward, new sandbox-ed <iframe>s are
>>> created. As soon the user hit the back button the last <iframe> is
>>> removed in order to free the relevant part of memory. Since <iframe>s
>>> are sandboxed without the allow-same-origin flag, the only way to
>>> communicate should be postMessage and data would be serialized that
>>> should prevent references to each other and guarantee that the memory
>>> will be freed.
>> Detaching from DOM is somewhat tricky as it cause a reflow (or, at
>> least, a noticeable repaint) but we could set src to '' and reuse empty
>> iframes. ,)
>
> Yep that's also an option. Actually Etienne suggest that to me a day
> or two ago and proposed the named quote-quote for this model!
>>>
>> least, a noticeable repaint) but we could set src to '' and reuse empty
>> iframes. ,)
>
> Yep that's also an option. Actually Etienne suggest that to me a day
> or two ago and proposed the named quote-quote for this model!
>>>
>>> I feel like this will address 1., 2. and 3. since the memory used will
>>> be directly related to the real user activity and it will be freed
>>> once it is done. Also, an application will be able to detach the
>>> previous state of the application to save some memory if needed. (For
>>> example the settings app would be able to detach the <iframe
>>> src="main-panel.html"> if the user has finished the activity but,
>>> instead of going back to the application starts using the back button,
>>> he/she hits the home button, leaving completely the app to do
>>> something else.
>>> be directly related to the real user activity and it will be freed
>>> once it is done. Also, an application will be able to detach the
>>> previous state of the application to save some memory if needed. (For
>>> example the settings app would be able to detach the <iframe
>>> src="main-panel.html"> if the user has finished the activity but,
>>> instead of going back to the application starts using the back button,
>>> he/she hits the home button, leaving completely the app to do
>>> something else.
>> Optionally, simple declarations of what is next a prev (i.e. some way to
>> declare the navigation flow) allows the library to preload those panel
>> more likely to be accessed.
>
> I forgot to mention that part of the plan would rely on
> https://bugzilla.mozilla.org/show_bug.cgi?id=730101 (Implement
> prerendering in FF). So this is kind of similar to what you propose.
>>
>> declare the navigation flow) allows the library to preload those panel
>> more likely to be accessed.
>
> I forgot to mention that part of the plan would rely on
> https://bugzilla.mozilla.org/show_bug.cgi?id=730101 (Implement
> prerendering in FF). So this is kind of similar to what you propose.
>>
>>> 3. Assets needs to be replicated.
>>> c. Memory overhead for each compartments
>>>
>>> I have probably forgot some obvious things, please feel free to add to
>>> the list!
>>> c. Memory overhead for each compartments
>>>
>>> I have probably forgot some obvious things, please feel free to add to
>>> the list!
>> I think the sandbox attribute is an impediment. I know it solves the
>> problem of freeing the memory not related with the current activity but
>> it introduces the overhead to reload all the related objects and causes
>> issue (a). Maybe we could cause the garbage collector to retrieve all
>> the memory by doing:
>
> 'related objects' is exactly one of the issue I want to tackle. I feel
> like each panel should be a kind of view that is independent from
> global states. IMHO It should be data based and that's where
> SharedWorker / IndexedDB comes into play.
>
> Also I'm not that afraid of fixing the platform. The implementation
> can be started even if the platform is not fully ready and any
> platform fixes would be sugar on top of that. It can be enhance based
> on the issues encountered. Let's make the platform better.
>>
>> 1) Encouraging the good practice of not communicate via window.parent /
>> iframe.contentDocument
> This is way too easy to do a mistake in JS in my opinion and I would
> like to be 100% confident in the model.
>>
>> 2) When the library don't need the iframe, just make its src to ''
>> (then, eventually detach or reuse)
>>
>> Furthermore, we could dynamically cut the access to iframe window.parent
>> (by nullifying it) allowing only Partent -> Children communications /
>> injections.
>
> Parent -> children injections can create some dependencies I would
> like to cut as well.
>>
>>>
>> problem of freeing the memory not related with the current activity but
>> it introduces the overhead to reload all the related objects and causes
>> issue (a). Maybe we could cause the garbage collector to retrieve all
>> the memory by doing:
>
> 'related objects' is exactly one of the issue I want to tackle. I feel
> like each panel should be a kind of view that is independent from
> global states. IMHO It should be data based and that's where
> SharedWorker / IndexedDB comes into play.
>
> Also I'm not that afraid of fixing the platform. The implementation
> can be started even if the platform is not fully ready and any
> platform fixes would be sugar on top of that. It can be enhance based
> on the issues encountered. Let's make the platform better.
>>
>> 1) Encouraging the good practice of not communicate via window.parent /
>> iframe.contentDocument
> This is way too easy to do a mistake in JS in my opinion and I would
> like to be 100% confident in the model.
>>
>> 2) When the library don't need the iframe, just make its src to ''
>> (then, eventually detach or reuse)
>>
>> Furthermore, we could dynamically cut the access to iframe window.parent
>> (by nullifying it) allowing only Partent -> Children communications /
>> injections.
>
> Parent -> children injections can create some dependencies I would
> like to cut as well.
>>
>>>
>> You mean like a "JavaScript seamless"?
>
> Not exactly. I don't want to expose the object of the parent inside
> the sub-iframes. Just want to share the generated bytecode if possible.
>
>
> Not exactly. I don't want to expose the object of the parent inside
> the sub-iframes. Just want to share the generated bytecode if possible.
>
> Vivien.
> _______________________________________________
> dev-gaia mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-gaia
>
>
> _______________________________________________
> dev-gaia mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-gaia
>
>
Julien Wajsberg
Jun 13, 2013, 5:24:28 AM6/13/13
to Matt Claypotch, tofumatt, dev-...@lists.mozilla.org
Le 13/06/2013 02:02, Matt Claypotch a écrit :
>
>
>
> On Wed, Jun 12, 2013 at 1:30 PM, Julien Wajsberg
> <jwaj...@mozilla.com <mailto:jwaj...@mozilla.com>> wrote:
>
> Something Vivien has not insisted on, is that lots of developers are
> developing on these Gaia apps. In the end, ensuring scoped context is
> what will help having consistent and maintenable apps.
>
> Another point is to _not_ use a framework. Trying to be as close as
> possible to the real stuff.
>
>
> I'll bite. Why _not_ use a framework? Why would you not encapsulate
> all your repeated best practices in a place where they all don't have
> to be repeated by the next person to touch the code? I haven't heard a
> compelling reason why a framework shouldn't be used.
I was exagerating a bit. And we're not against libraries either. And the
>
>
>
> On Wed, Jun 12, 2013 at 1:30 PM, Julien Wajsberg
> <jwaj...@mozilla.com <mailto:jwaj...@mozilla.com>> wrote:
>
> Something Vivien has not insisted on, is that lots of developers are
> developing on these Gaia apps. In the end, ensuring scoped context is
> what will help having consistent and maintenable apps.
>
> Another point is to _not_ use a framework. Trying to be as close as
> possible to the real stuff.
>
>
> I'll bite. Why _not_ use a framework? Why would you not encapsulate
> all your repeated best practices in a place where they all don't have
> to be repeated by the next person to touch the code? I haven't heard a
> compelling reason why a framework shouldn't be used.
difference between libraries and frameworks is subtile :)
Of course it's good to encapsulate best practices. The danger with
frameworks is that we tend to build everything in it, whereas I think we
all agree that the main goal for Firefox OS is to make the web platform
better, in the end. It's difficult to see what's missing in the platform
if we build a framework. Our goal isn't to build a framework.
We're not saying frameworks are bad, per se. We're saying that for _our_
goal, we should thrive to find other solutions, including make the
platform better.
--
Julien
Fabien Cazenave
Jun 13, 2013, 5:28:04 AM6/13/13
to Vivien, dev-...@lists.mozilla.org
On 12/06/13 16:06, Vivien wrote:
> <!-- This is a dirty little js lib that handle navigation between
> panels with a local postMessage protocol -->
> <!-- XXX Please don't focus tptionoo much on it - there are some
> plans to get rid of it in a potential near future but this
> discussion is way out of the scope of this proposal and I
> don't want to mix both discussions -->
> <script src="shared/js/navigation.js"></script>
Well, I hope I’m not mixing both discussions but I think this shared
> panels with a local postMessage protocol -->
> <!-- XXX Please don't focus tptionoo much on it - there are some
> plans to get rid of it in a potential near future but this
> discussion is way out of the scope of this proposal and I
> don't want to mix both discussions -->
> <script src="shared/js/navigation.js"></script>
`navigation.js' lib is a very good example.
In the Settings app we’ve tried to use vanilla-JS as much as possible
from the beginning. The result has been a heavy startup time + poor
panning, and we ended up with a whole bunch of hacks in the code just to
make inner links work smoothly.
I don’t want to tie Gaia with any framework either, and I think our “one
lib for one need” approach makes perfect sense. I think we’ve come to a
point where quite a few apps would benefit from:
• a shared and minimalistic routing library that helps using Gecko’s
fast paths and sharing a common navigation UX;
• a shared and minimalistic templating library allowing to use
readable templates, and playing nice with localization process.
There are a bunch of such libs on github, I’ll trust our talented
front-end developers to propose good candidates that we could use and
improve. If we need to rely on <iframe> elements behind the scenes to
achieve a good performance then it’s fine — the sandbox argument makes a
lot of sense, imho — but I’d prefer to abstract them properly.
:kazé
Fabien Cazenave
Jun 13, 2013, 5:28:04 AM6/13/13
to Vivien, dev-...@lists.mozilla.org
On 12/06/13 16:06, Vivien wrote:
> <!-- This is a dirty little js lib that handle navigation between
> panels with a local postMessage protocol -->
> <!-- XXX Please don't focus tptionoo much on it - there are some
> plans to get rid of it in a potential near future but this
> discussion is way out of the scope of this proposal and I
> don't want to mix both discussions -->
> <script src="shared/js/navigation.js"></script>
> panels with a local postMessage protocol -->
> <!-- XXX Please don't focus tptionoo much on it - there are some
> plans to get rid of it in a potential near future but this
> discussion is way out of the scope of this proposal and I
> don't want to mix both discussions -->
> <script src="shared/js/navigation.js"></script>
Fabien Cazenave
Jun 13, 2013, 5:28:04 AM6/13/13
to Vivien, dev-...@lists.mozilla.org
On 12/06/13 16:06, Vivien wrote:
> <!-- This is a dirty little js lib that handle navigation between
> panels with a local postMessage protocol -->
> <!-- XXX Please don't focus tptionoo much on it - there are some
> plans to get rid of it in a potential near future but this
> discussion is way out of the scope of this proposal and I
> don't want to mix both discussions -->
> <script src="shared/js/navigation.js"></script>
> panels with a local postMessage protocol -->
> <!-- XXX Please don't focus tptionoo much on it - there are some
> plans to get rid of it in a potential near future but this
> discussion is way out of the scope of this proposal and I
> don't want to mix both discussions -->
> <script src="shared/js/navigation.js"></script>
Vivien
Jun 13, 2013, 5:30:06 AM6/13/13
to James Burke, dev-...@lists.mozilla.org
I wrote more or less that later in my inline comments but I want to
promote it here: Modules and <iframe>s are not two different approaches
to resolve the same issue, there are different set of issues and
possibly some overlaps but <iframe>s will never solve modularity of the
JS code, it is a way to scope functionalities and responsibilities at a
macro level.
So in order for this discussion to go further let's make sure to not try
to compare apples and oranges (I like both).
On 12/06/2013 22:59, James Burke wrote:
> I believe the iframes will be more expensive than just using modular
> code with HTML templates and data binding.
to keep track of all the objects potentially create in the global scope,
circular references and event listeners. Instead of trying to manage
them individually my proposal is to tackle them at a macro level.
> There are a few ways to go
> about that, some even future web platform-related (see summary at
> end). Here is one:
>
> I have done working experiments along those lines in the email app in
> this branch:
>
> https://github.com/jrburke/gaia/tree/groupload-htmlinabox
>
> That experiment splits all the code into modules and has a mechanism
> to save the startup HTML in a cookie. As it is a code retrofit, it is
> not as modularly clean as I would prefer, but a good first pass thatiff
> about that, some even future web platform-related (see summary at
> end). Here is one:
>
> I have done working experiments along those lines in the email app in
> this branch:
>
> https://github.com/jrburke/gaia/tree/groupload-htmlinabox
>
> That experiment splits all the code into modules and has a mechanism
> to save the startup HTML in a cookie. As it is a code retrofit, it is
> tries to minimize diffs to make review easier.
>
> On cold launch, it just inserts that saved HTML into the DOM. It is
> quite fast (700ms range, and as actual HTML, not just a fakeout of the
> "app load" event), and the app has control over what HTML it chooses
> to save.
It sounds nice and nothing prevent you to use that in the 'main panel'.
>
> On cold launch, it just inserts that saved HTML into the DOM. It is
> quite fast (700ms range, and as actual HTML, not just a fakeout of the
> "app load" event), and the app has control over what HTML it chooses
> to save.
I'm kind of curious though about why you have to do that. What is
impossible to inline the relevant HTML in different files and just load
the relevant one?
>
> This experiment goes further:
>
> https://github.com/jrburke/carmino
>
> Each card is represented by a module with an HTML template. The card
> module does not bind events, but instead, the card controller uses
> event delegation to pass events to the card module. This means that
> when the HTML is rehydrated from storage, all the card controller has
> to do is
>
> Also, the HTML uses fragment IDs to indicate what card module will be
> triggered by an action, like '#list-detail', and data can be passed
> via querystring-link arguments in that string.
>
> This allows the card controller to scan the DOM of the just inserted
> card and find the "next card" modules by looking for those IDs, and
> lazy load them in the background. This allows for quick transitions,
> but delayed loading of code. Loading a card module does not trigger an
> HTML insertion, just defines the module, so the cost of loading the
> next actions are low.
<navigation.js> should probably be a kind of 'card' controller as well.
> This experiment goes further:
>
> https://github.com/jrburke/carmino
>
> Each card is represented by a module with an HTML template. The card
> module does not bind events, but instead, the card controller uses
> event delegation to pass events to the card module. This means that
> when the HTML is rehydrated from storage, all the card controller has
> to do is
>
> Also, the HTML uses fragment IDs to indicate what card module will be
> triggered by an action, like '#list-detail', and data can be passed
> via querystring-link arguments in that string.
>
> This allows the card controller to scan the DOM of the just inserted
> card and find the "next card" modules by looking for those IDs, and
> lazy load them in the background. This allows for quick transitions,
> but delayed loading of code. Loading a card module does not trigger an
> HTML insertion, just defines the module, so the cost of loading the
> next actions are low.
Except that cards are iframes to scope js / reflows.
>
> Furthermore, by using AMD modules with a loader plugin, the HTML
> templates can be inlined as either HTML strings or as compiled JS
> functions in build layers. Since the build tool can scan module
> relationships, it is easier to work out build layers without having to
> know the full dependency chain.
>
I have nothing against AMD but afaict JS will still be in the same
> Furthermore, by using AMD modules with a loader plugin, the HTML
> templates can be inlined as either HTML strings or as compiled JS
> functions in build layers. Since the build tool can scan module
> relationships, it is easier to work out build layers without having to
> know the full dependency chain.
>
global. That means it makes it harder to offer a guarantee about memory
consumption / leaks. I cannot wait for the day where Harmony Modules
will make it in the tree
(https://bugzilla.mozilla.org/show_bug.cgi?id=568953 ftr). I agree that
a better modular pattern would be a great improvement but I feel like
modules is an orthogonal problem.
> I used that approach in the email experiment to inline the card
> modules for the first two possible cards as part of the startup layer.
>
> For both of those experiments, by using modular code and a "cards"
> controller I believe it will give similar benefits but be lighter
> weight over all since iframes are not in play. Some further details
> below:
>
> modules for the first two possible cards as part of the startup layer.
>
> For both of those experiments, by using modular code and a "cards"
> controller I believe it will give similar benefits but be lighter
> weight over all since iframes are not in play. Some further details
> below:
>
> On Wed, Jun 12, 2013 at 7:06 AM, Vivien <vnic...@mozilla.com> wrote:
>> Hello folks,
>>
>> Last year or so many Gaia apps has been built using a framework-less based
>> approach, using a combination of libraries + css building blocks.
>> In parallel, during last year a lot of things has been learned about device
>> constraints, mobile constraints, app constraints, cross-teams-work
>> constraints.
>>
>> -----------------
>> Based on this here are some of those constraints (some are already partially
>> solved) I would like to reach primarily:
>> 1. *Fast loading application*
>> Andreas said it a few times already. Apps should load in less than 600ms.
>> Hello folks,
>>
>> Last year or so many Gaia apps has been built using a framework-less based
>> approach, using a combination of libraries + css building blocks.
>> In parallel, during last year a lot of things has been learned about device
>> constraints, mobile constraints, app constraints, cross-teams-work
>> constraints.
>>
>> -----------------
>> Based on this here are some of those constraints (some are already partially
>> solved) I would like to reach primarily:
>> 1. *Fast loading application*
>> Andreas said it a few times already. Apps should load in less than 600ms.
> This approach does not guarantee faster loading, and due to the iframe
> usage, could lead to more resource use, depending on how much is in
> the iframe. The blockers to me on fast startup have been:
More resource use is relative. In terms of memory: If you use a few
> usage, could lead to more resource use, depending on how much is in
> the iframe. The blockers to me on fast startup have been:
hundreds additional Ks but remove a few other hundreds Ks (or more... on
some apps) of unused stuffs that should be fine. In terms of CPU cycles
it seems similar. If you spend more times to load an additional iframe
and less time to parse / load unused stuffs that sounds good. (Just to
make sure they will be only one iframe at the beginning).
>
> 1) Async storage means waiting on the event loop to make first card
> choice if that choice depends on app data. However, the event loop is
> clogged because the platform wants to paint. That, with the
> screenshotting at inopportune times cost 200ms of startup.
Screenshotting is gone. But I agree that Async storage is delayed and it
> 1) Async storage means waiting on the event loop to make first card
> choice if that choice depends on app data. However, the event loop is
> clogged because the platform wants to paint. That, with the
> screenshotting at inopportune times cost 200ms of startup.
is an issue in some cases. I have been told that using cookies in those
special cases is OK.
> I believe this was also reflected in the "IndexedDB is slow" thread a
> while back -- the DB was not slow, but there was other things in the
> event loop clogging it up.
>
> By hiding the app's iframe and avoiding the screenshot until it
> considers itself truly loaded saved on that time.
>
> 2) This was a few months ago now, but I measured about 300ms from app
> launch before my app JS could do any work. Reducing that cost would
> help all apps.
>
> I believe the HTML reserialization from cookie storage mitigates those
> issues by cramming in some HTML synchronously as soon as possible. But
> getting platform changes would be even sweeter.
People are working on making 2). faster. There are still a few things
> while back -- the DB was not slow, but there was other things in the
> event loop clogging it up.
>
> By hiding the app's iframe and avoiding the screenshot until it
> considers itself truly loaded saved on that time.
>
> 2) This was a few months ago now, but I measured about 300ms from app
> launch before my app JS could do any work. Reducing that cost would
> help all apps.
>
> I believe the HTML reserialization from cookie storage mitigates those
> issues by cramming in some HTML synchronously as soon as possible. But
> getting platform changes would be even sweeter.
that can be done to preload more things in our 'template' process. For
example and If you want to help there the file
https://mxr.mozilla.org/mozilla-central/source/b2g/chrome/content/content.css
that should besplit in two toolkits/ parts. A scrollbar.css file and an
additional part in forms.css in order to preload those rules via the
magic of
http://mxr.mozilla.org/mozilla-central/source/layout/style/nsLayoutStylesheetCache.cpp#59
. That would load those rules at preload time and would help a few cycles!
An 'getting platform changes would be even sweeter' match 100% my
personal opinion.
>
>> 2. *Low memory consumption*
>> The memory of the device is limited. A limited number of applications can
>> run at the same time. Less memory used means more applications can run at
>> the same time.
>> 2. *Low memory consumption*
>> The memory of the device is limited. A limited number of applications can
>> run at the same time. Less memory used means more applications can run at
>> the same time.
> Modules will be cheaper than iframes.
As I said above, Modules is an orthogonal problem. In the medium (i
would have hope short...) term, with this proposal, there will be both
iframes and modules.
>
>> 3. *Stable memory consumption*
>> It is OK to consume an extra memory while making a particular task of an
>> application. But this memory needs to be freed once the task has been
>> finished.
>> 3. *Stable memory consumption*
>> It is OK to consume an extra memory while making a particular task of an
>> application. But this memory needs to be freed once the task has been
>> finished.
> Hopefully by using a module "singleton" for each card type and using
> event delegation in the card controller, it should control memory
> well, leaving the rest to garbage collection. The card controller
> removes the HTML for cards in the "forward" section once the user goes
> back.
Same comment as your first point:
> event delegation in the card controller, it should control memory
> well, leaving the rest to garbage collection. The card controller
> removes the HTML for cards in the "forward" section once the user goes
> back.
This is so easy to do a mistake in JS... sandbox would be a simple
platform insurance against mistakes.
>
>> 4. *Smooth panel transitions*
>> Transitions should happen really quick after a hit on a button. Ideally a
>> panel should be fully loaded when the transition is complete, but it sounds
>> OK if informations such as the list of wifi networks around, loads delayed.
>> 4. *Smooth panel transitions*
>> Transitions should happen really quick after a hit on a button. Ideally a
>> panel should be fully loaded when the transition is complete, but it sounds
>> OK if informations such as the list of wifi networks around, loads delayed.
> This works well in the approach I mention above: there is delayed
> loading of card modules, but next action card modules get preloaded at
> the end of the current card insertion, making the transition fast.
Glad yo heard that. As I said in the initial mail - some of those things
> loading of card modules, but next action card modules get preloaded at
> the end of the current card insertion, making the transition fast.
has been reach partly. On an additional note I would like to prototype
with prerender here
(https://bugzilla.mozilla.org/show_bug.cgi?id=730101) , that would let
the platform optimize the next panel based on some heuristics that are
hard at the app level without exposing additional permissions to each
app. For example the platform can know what is in the current view,
knows user idle time (accessible with a permission for certified app
only :(), and know if there are memory to prerender something without
killing, for example, your music app. There could be other heuristics I
have not think of.
>
>> 5. *Inline activities friendly*
>> The whole application should not be required to be loaded for handling a
>> particular operation.
>> 5. *Inline activities friendly*
>> The whole application should not be required to be loaded for handling a
>> particular operation.
> The card controller can process the web activity and dynamically load
> the right card module based on that information.
My point is: do we really need to load the 16 css files and 14 js files
> the right card module based on that information.
of the email's index.html page for sending an email ? (I'm not even
counting what is lazy loaded).
What if the inline activity targets directly the right URL specified by
the manifest ? With the iframe approach this will be managed directly by
the platform, not at the application level.
>
>> 6. *Scoped Panels*
>> Panels should be independent. So a panel is directly responsible of its
>> own load time and of any JS breakage it can generate. Also, an individual
>> panel should not be able to break the application. Different authors can
>> work on the same application and each of them would be directly responsible
>> of one or many panels.
>> 6. *Scoped Panels*
>> Panels should be independent. So a panel is directly responsible of its
>> own load time and of any JS breakage it can generate. Also, an individual
>> panel should not be able to break the application. Different authors can
>> work on the same application and each of them would be directly responsible
>> of one or many panels.
> I believe modules give good scoping behavior. The event delegation
> means that the card controller is routing events vs the panels, so if
> a panel messes up its bindings, as long as the HTML shows up, the user
> can usually get "back".
Again modules and iframes are not 2 different approach of the same
> means that the card controller is routing events vs the panels, so if
> a panel messes up its bindings, as long as the HTML shows up, the user
> can usually get "back".
problem. There are different problems. One is a design that formats app
in a way that it offers you a memory insurance an promote URLs, the
other is (a third party lib for now but let's assume there it is
built-in in the platform) a mechanism that improves significantly
different aspects of a software.
If you think of it differently, like if you think of each panel like a
tab in your browser then you will see what I mean by scoping. You can
work on the main page of mywebsite.org while I'm working on the credits
page. None of us should have to worry about any methods, abstractions,
etc.. You and I will be 100% sure to not collapsed our global scopes,
etc...
Also nothing prevents to use AMD into the pages of mywebsite.org.
Modules are completely orthogonal to this tab problem.
>
> --- summary ---
>
> To echo tofumatt's feedback, the iframe approach is also very
> non-standard -- not what web developers do today, and looking to the
> future, hard to see how it would fit in.
>
> Non-standard would be fine (anything new is non-standard), but at this
> point, if gaia will be doing speculative work, I would rather see it
> use future platform aspects and work out the issues with them as they
> are likely to be more relevant in the future. Things like modules, web
> components, Object.observe, maybe even model driven views. We will do
> the web platform more service by doing so.
world and I already <3 Web Components. Object.observe sounds cool, as
well as Object.freeze and friends. Not sure about the event model driven
views at the platform level?
I'm all for enhancing the platform!
>
> What I do think would help is just embracing a card-based framework
> already. This is effectively what this thread is proposing. There will
> need to be a standard library to manage the card transitions and card
> communication. This is not an unopinionated choice. I think that is
> fine, because we want uniformity in the apps, and having some common
> modules/classes handling lifecycle events uniformly and directing
> traffic.
This thread is proposing to use a more URLs based approach with all what
> What I do think would help is just embracing a card-based framework
> already. This is effectively what this thread is proposing. There will
> need to be a standard library to manage the card transitions and card
> communication. This is not an unopinionated choice. I think that is
> fine, because we want uniformity in the apps, and having some common
> modules/classes handling lifecycle events uniformly and directing
> traffic.
it implies. The card controller is a side effect of this proposal in the
current form (that I honestly don't like).
>
> So some sort of card controller is a great idea, and having cards fit
> into a model with lifecycle events/callbacks will make a big
> difference. Modules too. Ones that can be dynamically loaded, and a
> build system that understands them. Modules are coming anyway, and
> even using AMD modules for today while we wait for ES6 means some easy
> static transforms when ES modules come online. Particularly since AMD
> modules have great build support, and will be adapted to the future to
> parse ES modules.
> For any route though, I expect the way to find a common solution is to
> work with a specific app first, and convert it. The changes should be
> done based on data -- doing a change and seeing if it holds
> performance and has good developer ergonomics.
+1
> work with a specific app first, and convert it. The changes should be
> done based on data -- doing a change and seeing if it holds
> performance and has good developer ergonomics.
> I am hopeful I can land
> some of the ideas of the experiments in the email app, but of course
> that is gated by the keepers of gaia, the appropriateness of the fix,
> and schedule.
Before any work it should be clear what is the goal of the proposal and
> some of the ideas of the experiments in the email app, but of course
> that is gated by the keepers of gaia, the appropriateness of the fix,
> and schedule.
that it is no ambiguous. I know I repeat myself but to me Modules and
<iframe>s are two different things and I'm not sure the line is clearly
drawn at this point?
> James
Vivien
Jun 13, 2013, 5:41:52 AM6/13/13
to Fabien Cazenave, dev-...@lists.mozilla.org
On 13/06/2013 11:28, Fabien Cazenave wrote:
> On 12/06/13 16:06, Vivien wrote:
> On 12/06/13 16:06, Vivien wrote:
>> <!-- This is a dirty little js lib that handle navigation between
>> panels with a local postMessage protocol -->
>> <!-- XXX Please don't focus tptionoo much on it - there are some
>> plans to get rid of it in a potential near future but this
>> discussion is way out of the scope of this proposal and I
>> don't want to mix both discussions -->
>> <script src="shared/js/navigation.js"></script>
>
>> panels with a local postMessage protocol -->
>> <!-- XXX Please don't focus tptionoo much on it - there are some
>> plans to get rid of it in a potential near future but this
>> discussion is way out of the scope of this proposal and I
>> don't want to mix both discussions -->
>> <script src="shared/js/navigation.js"></script>
>
> Well, I hope I’m not mixing both discussions but I think this shared
> `navigation.js' lib is a very good example.
>
> In the Settings app we’ve tried to use vanilla-JS as much as possible
> from the beginning. The result has been a heavy startup time.
> `navigation.js' lib is a very good example.
>
> In the Settings app we’ve tried to use vanilla-JS as much as possible
An OK startup time has been reached at some point but there are many
people that has worked on this app and there has been hundreds of
milliseconds regressions on it. Isolating the startup panel into one
dedicated sandboxed frame should put the responsibilities on this panel
only and would offer an instant way to git blame the dedicate folder for
this panel.
But we should go further and enforce a strong practice that ensure the
app window is always fast to load (there will be nothing after cold
launch in the window - and then it can load the main panel. Because of
this separation the time taken to load the panel would be directly
imputable to the panel).
> + poor panning, and we ended up with a whole bunch of hacks in the
> code just to make inner links work smoothly.
>
to load a panel that has sub-panels. It does it all in one path and
loading 4 panels before the transition is obviously expensive :/
>
> • a shared and minimalistic templating library allowing to use
> readable templates, and playing nice with localization process.
>
Staś Małolepszy
Jun 13, 2013, 7:09:41 AM6/13/13
to Vivien, dev-...@lists.mozilla.org
Regardless of personal preferences and outlooks for the future, I urge
this group to not take any decision without first seeing hard perf
data. I've seen too many times people on this project say 'I think
this should be faster.' The only way to know if it is indeed faster is
to have numbers.
Implement a prototype, run performance tests, calculate the means and
the standard deviations and run a t-test to understand if the perceived
difference in means is statistically significant. It's easy and it
helps you understand whether or not you're making real progress.
* * *
As far as my own opinion goes, I'll echo Kevin's words: do we really
want developers to code this way? Is this what the future of HTML
looks like according to Mozilla?
Maybe I was naïve but I was hoping that the reason why we did all these
hacky optimization was the hardware that the first version of Gaia was
supposed to run on. I was hoping that the second generation of the
devices will let us go back to coding things normally. In a more webby
way, without resorting to <!-- html comments --> and without having to
inline all localizations as a JSON blog in the HTML file.
Digression: Did you know that because of the build-time optimization
which inlines localizations as JSON in the HTML file, the memory
consumption increases and the app start-up slows down linearly to the
number of locales. Each locale costs about 20ms of the start up time.
See this bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=853933
I guess in this particular case, the iframe proposal would help (see
below). But I tend to think that the real solution would be to fix the
localization framework such that it doesn't need the inlined JSON blobs
at all.
Same goes for everything else. I'd like to see us advancing the Web
and pushing the technology forward so that these hacks are not needed.
Shoehorning iframes to give us better memory management sounds like
something that will come back to haunt us in the future.
Quoting Vivien (2013-06-12 16:06:06)
files somewhere on this list, too.
If Gaia apps end up split in mutliple HTML files, I think it would make
sense to split the related localization files as well. This should
rather straight-forward and shouldn't impact the l10n ecosystem much.
An alternative would be to continue loading all of l10n in the main
HTML file and postMessage localized strings to each panel. However, if
we can be lazy about the translation of unseen panels, I think we
should.
(And if this proposal isn't approved, I still think we should find
a way to lazily load l10n resources for each <section role="region">.)
-stas
--
@stas
this group to not take any decision without first seeing hard perf
data. I've seen too many times people on this project say 'I think
this should be faster.' The only way to know if it is indeed faster is
to have numbers.
Implement a prototype, run performance tests, calculate the means and
the standard deviations and run a t-test to understand if the perceived
difference in means is statistically significant. It's easy and it
helps you understand whether or not you're making real progress.
* * *
As far as my own opinion goes, I'll echo Kevin's words: do we really
want developers to code this way? Is this what the future of HTML
looks like according to Mozilla?
Maybe I was naïve but I was hoping that the reason why we did all these
hacky optimization was the hardware that the first version of Gaia was
supposed to run on. I was hoping that the second generation of the
devices will let us go back to coding things normally. In a more webby
way, without resorting to <!-- html comments --> and without having to
inline all localizations as a JSON blog in the HTML file.
Digression: Did you know that because of the build-time optimization
which inlines localizations as JSON in the HTML file, the memory
consumption increases and the app start-up slows down linearly to the
number of locales. Each locale costs about 20ms of the start up time.
See this bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=853933
I guess in this particular case, the iframe proposal would help (see
below). But I tend to think that the real solution would be to fix the
localization framework such that it doesn't need the inlined JSON blobs
at all.
Same goes for everything else. I'd like to see us advancing the Web
and pushing the technology forward so that these hacks are not needed.
Shoehorning iframes to give us better memory management sounds like
something that will come back to haunt us in the future.
Quoting Vivien (2013-06-12 16:06:06)
> Possible issues:
> a. Global states cannot be shared.
> b. Load time for each panels
> 1. JavaScript files / libraries needs to be replicated.
> 2. CSS files need to be replicated.
> a. Global states cannot be shared.
> b. Load time for each panels
> 1. JavaScript files / libraries needs to be replicated.
> 2. CSS files need to be replicated.
> 3. Assets needs to be replicated.
> c. Memory overhead for each compartments
>
> I have probably forgot some obvious things, please feel free to add to
> the list!
Not sure if it counts as "b3. Assets", but I'd like to put localization
> c. Memory overhead for each compartments
>
> I have probably forgot some obvious things, please feel free to add to
> the list!
files somewhere on this list, too.
If Gaia apps end up split in mutliple HTML files, I think it would make
sense to split the related localization files as well. This should
rather straight-forward and shouldn't impact the l10n ecosystem much.
An alternative would be to continue loading all of l10n in the main
HTML file and postMessage localized strings to each panel. However, if
we can be lazy about the translation of unseen panels, I think we
should.
(And if this proposal isn't approved, I still think we should find
a way to lazily load l10n resources for each <section role="region">.)
-stas
--
@stas
Alive Kuo
Jun 13, 2013, 8:00:31 AM6/13/13
to Staś Małolepszy, Vivien, dev-...@lists.mozilla.org
I wrote this to agree what :stas said here.
If a web developer is not working in a browser company,
he should never have any chance to modify the platform every time he has some performance/memory/... issues when developing his website/webapp.
The platform hack -- forgive me to call it hack --
if we're not promoting them(sandbox iframe) to web standards,
really violates the value of a front-end developer.
Yes we're so GIGA EXTREMELY lucky! We work at Mozilla, so we could gain some resource easily than others,
to fix those problems by "poke" some colleagues who is working in gecko team to create some magic for us.
And we really did so, many times in this project.
But this time, this one, really sounds not be part of future web standards.
I didn't say I don't like any gecko convenient magic.
If we don't have mozChromeEvent in system app we would still have a slow progress now.
But at least they would become removed in the future I believe. And the scope is only limited in system app. No other app involved.(ANY?)
And yes, the original targets of this proposal for sure should be addressed,
but what's the real cause needs iframe hack instead of HTML lazy loading?
Does iframe really save us from memory consumption?
Is memory the only reason we need to abandon current design?
I mean the app with some kind of refined architecture, like Calendar.
Also don't mix performance improvement with architecture refinement. They are different!
The modularization and architecture, sometimes is not at the same side with performance no matter timing(startup) or space(memory).
It's a trade-off.
If we really really need to raise the performance anyway by any possible solution...
If the device hardware is really really that bad…
Then we couldn't avoid to sacrifice -- or destroy -- the architecture, and the proposal is just an example.
As a web developer's point of view.
--
Alive C. Kuo, Front-end Eng., Mozilla Corp. (Taiwan, Taipei)
If a web developer is not working in a browser company,
he should never have any chance to modify the platform every time he has some performance/memory/... issues when developing his website/webapp.
The platform hack -- forgive me to call it hack --
if we're not promoting them(sandbox iframe) to web standards,
really violates the value of a front-end developer.
Yes we're so GIGA EXTREMELY lucky! We work at Mozilla, so we could gain some resource easily than others,
to fix those problems by "poke" some colleagues who is working in gecko team to create some magic for us.
And we really did so, many times in this project.
But this time, this one, really sounds not be part of future web standards.
I didn't say I don't like any gecko convenient magic.
If we don't have mozChromeEvent in system app we would still have a slow progress now.
But at least they would become removed in the future I believe. And the scope is only limited in system app. No other app involved.(ANY?)
And yes, the original targets of this proposal for sure should be addressed,
but what's the real cause needs iframe hack instead of HTML lazy loading?
Does iframe really save us from memory consumption?
Is memory the only reason we need to abandon current design?
I mean the app with some kind of refined architecture, like Calendar.
Also don't mix performance improvement with architecture refinement. They are different!
The modularization and architecture, sometimes is not at the same side with performance no matter timing(startup) or space(memory).
It's a trade-off.
If we really really need to raise the performance anyway by any possible solution...
If the device hardware is really really that bad…
Then we couldn't avoid to sacrifice -- or destroy -- the architecture, and the proposal is just an example.
As a web developer's point of view.
--
Alive C. Kuo, Front-end Eng., Mozilla Corp. (Taiwan, Taipei)
Vivien
Jun 13, 2013, 8:31:19 AM6/13/13
to Staś Małolepszy, dev-...@lists.mozilla.org
On 13/06/2013 13:09, Staś Małolepszy wrote:
> Regardless of personal preferences and outlooks for the future, I urge
> this group to not take any decision without first seeing hard perf
> data.
Don't worry - I don't think nobody here want to takes a quick decision
> Regardless of personal preferences and outlooks for the future, I urge
> this group to not take any decision without first seeing hard perf
> data.
that will involved an more than noticeable amount of work, who involve
the platform as well :)
> I've seen too many times people on this project say 'I think
> this should be faster.'
'too many times people on this project' ? It makes me curious ;)
> this should be faster.'
> The only way to know if it is indeed faster is
> to have numbers.
navigates into it without doing anything special- and there were
evidence about lazy loading in the past. The proposal is not only about
beeing 'faster' too :)
>
> * * *
>
> As far as my own opinion goes, I'll echo Kevin's words: do we really
> want developers to code this way? Is this what the future of HTML
> looks like according to Mozilla?
a lot of confusion here.
>
> Maybe I was naïve but I was hoping that the reason why we did all these
> hacky optimization was the hardware that the first version of Gaia was
> supposed to run on. I was hoping that the second generation of the
> devices will let us go back to coding things normally. In a more webby
> way, without resorting to <!-- html comments --> and without having to
> inline all localizations as a JSON blog in the HTML file.
The proposal would remove the needs for <!-- html comments --> and most
> Maybe I was naïve but I was hoping that the reason why we did all these
> hacky optimization was the hardware that the first version of Gaia was
> supposed to run on. I was hoping that the second generation of the
> devices will let us go back to coding things normally. In a more webby
> way, without resorting to <!-- html comments --> and without having to
> inline all localizations as a JSON blog in the HTML file.
of the lazy_load.js mechanism. I also tend to think that
GAIA_DEFAULT_LOCALE and parallels translated html files can get rid of
this inlining mechanism.
>
> Digression: Did you know that because of the build-time optimization
> which inlines localizations as JSON in the HTML file, the memory
> consumption increases and the app start-up slows down linearly to the
> number of locales. Each locale costs about 20ms of the start up time.
I would have expected it to be related to the size of the JSON globally
> Digression: Did you know that because of the build-time optimization
> which inlines localizations as JSON in the HTML file, the memory
> consumption increases and the app start-up slows down linearly to the
> number of locales. Each locale costs about 20ms of the start up time.
not the number of locales. If there is one string for each locale I
guess it is not 20ms by locale. I think that what's you were trying to
say and this is an interesting point.
>
> See this bug:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=853933
>
> I guess in this particular case, the iframe proposal would help (see
> below). But I tend to think that the real solution would be to fix the
> localization framework such that it doesn't need the inlined JSON blobs
> at all.
This is really interesting. I have never been a fan of in-lining locales
> See this bug:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=853933
>
> I guess in this particular case, the iframe proposal would help (see
> below). But I tend to think that the real solution would be to fix the
> localization framework such that it doesn't need the inlined JSON blobs
> at all.
as JSON at the end of files. I was pushing for a build-time localization
and why not generating one file per locale, per app. But this is a side
discussion IMHO and I would happy to discuss it in the related bug.
>
> Same goes for everything else. I'd like to see us advancing the Web
> and pushing the technology forward so that these hacks are not needed.
I can't wait for a navigator.mozL10n API but tbh I'm far from beeing
> Same goes for everything else. I'd like to see us advancing the Web
> and pushing the technology forward so that these hacks are not needed.
convinced by a translate-on-the-fly html pages. That sounds way too
heavy versus server side localization. But Again this is a side
discussion and I agree that ultimately the platform should help here.
>
> Shoehorning iframes to give us better memory management sounds like
> something that will come back to haunt us in the future.
As I said in a previous email, <iframe>s should be view the way you view
> Shoehorning iframes to give us better memory management sounds like
> something that will come back to haunt us in the future.
tabs. The browser manage the memory for you when you close the tab. As a
web developer you don't think about it.
>
>
> Quoting Vivien (2013-06-12 16:06:06)
>> Possible issues:
>> a. Global states cannot be shared.
>> b. Load time for each panels
>> 1. JavaScript files / libraries needs to be replicated.
>> 2. CSS files need to be replicated.
>> 3. Assets needs to be replicated.
>> c. Memory overhead for each compartments
>>
>> I have probably forgot some obvious things, please feel free to add to
>> the list!
> Not sure if it counts as "b3. Assets", but I'd like to put localization
> files somewhere on this list, too.
I made one of the most common mistakes. Forgot localizations. Thanks :)
>
> Quoting Vivien (2013-06-12 16:06:06)
>> Possible issues:
>> a. Global states cannot be shared.
>> b. Load time for each panels
>> 1. JavaScript files / libraries needs to be replicated.
>> 2. CSS files need to be replicated.
>> 3. Assets needs to be replicated.
>> c. Memory overhead for each compartments
>>
>> I have probably forgot some obvious things, please feel free to add to
>> the list!
> Not sure if it counts as "b3. Assets", but I'd like to put localization
> files somewhere on this list, too.
>
> If Gaia apps end up split in mutliple HTML files, I think it would make
> sense to split the related localization files as well. This should
> rather straight-forward and shouldn't impact the l10n ecosystem much.
In this proposal it would like this likely.
> If Gaia apps end up split in mutliple HTML files, I think it would make
> sense to split the related localization files as well. This should
> rather straight-forward and shouldn't impact the l10n ecosystem much.
> An alternative would be to continue loading all of l10n in the main
> HTML file and postMessage localized strings to each panel. However, if
> we can be lazy about the translation of unseen panels, I think we
> should.
I would like to do as few postMessage calls as possible and would prefer
> HTML file and postMessage localized strings to each panel. However, if
> we can be lazy about the translation of unseen panels, I think we
> should.
having a browser API for l10n that load only what is necessarly for one
panel (as you said above).
>
> (And if this proposal isn't approved, I still think we should find
> a way to lazily load l10n resources for each <section role="region">.)
Based on the data you said in
> (And if this proposal isn't approved, I still think we should find
> a way to lazily load l10n resources for each <section role="region">.)
https://bugzilla.mozilla.org/show_bug.cgi?id=853933 that would makes sense.
> -stas
>
Tim Chien
Jun 13, 2013, 8:44:28 AM6/13/13
to Alive Kuo, Vivien, dev-...@lists.mozilla.org, Staś Małolepszy
Hi all, here is my two cents:
I am basically in agreement with Vivien's proposal here. It sounds promising.
I am not very concern about the use of the sandbox iframe as a
memory-saving measure. Why? Because from the POV on isolation of
scripts, maintaining a sane, testable, scale app, sandbox iframe is
the way to impose the limitations on the runtime level. Even if it
turned out cause _more_ memory. Gaia is a disperse, and decentralized
open source project, and I intend to keep it that way (as opposed to
many other managers), but we have paid too much price on keeping all
of the freedom we are being offered -- it would be good if we set a
common pattern with rules that is implementable at the runtime level.
Evidently, we couldn't even make our code pass gjslint 100% all the
time. Any rules not limited at the runtime will be broken if we are
still organized this way. You could imagine by think of if we have
postMessage() available on mozbrowser iframes, what kind of hack we
would have in the code base right now.
To Vivien's credit, he is solving the problem with machines, not
humans. If we don't impose sandbox iframe on ourselves, it would be
left to people, particularly reviewers, to impose whatever framework
we ended up. I am pretty sure that won't end well no matter which
framework we choose (or built in-house from ground up).
No, sandbox iframe is not prefect. It's arguably a hack, not a Gecko
feature where, we, as privileged web developers work in a browser
company, proposed from bottom-up. I can see many proposed browser
features that could be at help (web components, shadow DOM, scoped
style, etc.), but waiting for these features is exactly what
preventing us from advancing the web. James would not establish AMD
modules if he decided to wait for Harmony -- and to his credit, AMD
helped established use cases for Harmony; and eventually, AMD modules
will be transformed to Harmony modules in a semi-automatically way and
the promise of advancing the web will be fulfilled.
I see the same thing in the proposed sandbox iframe use case, even
though I know they are banana and orange.
To sum up,
-- Memory optimization is a bonus. This proposal is not just about that.
-- Isolation of the scripts; make it testable and maintainable is what
I most valued. It can only be achieved through runtime limitation.
-- Gaia-wide pattern can still be flexible in the future and adopts
the real fix in the future. Everybody-writes-it-own-controller, in
contrast, is not.
With that, I think we could spare some resources to try out this idea
on an app, maybe have a intern to work on it in parallel so we could
still ship code under tight schedule. We would only land it if
everything checks out (performance, possible race, etc.).
>> this should be faster.' The only way to know if it is indeed faster is
>> to have numbers.
>>
Tim Guan-tin Chien, Engineering Manager and Front-end Lead, Firefox
OS, Mozilla Corp. (Taiwan)
I am basically in agreement with Vivien's proposal here. It sounds promising.
I am not very concern about the use of the sandbox iframe as a
memory-saving measure. Why? Because from the POV on isolation of
scripts, maintaining a sane, testable, scale app, sandbox iframe is
the way to impose the limitations on the runtime level. Even if it
turned out cause _more_ memory. Gaia is a disperse, and decentralized
open source project, and I intend to keep it that way (as opposed to
many other managers), but we have paid too much price on keeping all
of the freedom we are being offered -- it would be good if we set a
common pattern with rules that is implementable at the runtime level.
Evidently, we couldn't even make our code pass gjslint 100% all the
time. Any rules not limited at the runtime will be broken if we are
still organized this way. You could imagine by think of if we have
postMessage() available on mozbrowser iframes, what kind of hack we
would have in the code base right now.
To Vivien's credit, he is solving the problem with machines, not
humans. If we don't impose sandbox iframe on ourselves, it would be
left to people, particularly reviewers, to impose whatever framework
we ended up. I am pretty sure that won't end well no matter which
framework we choose (or built in-house from ground up).
No, sandbox iframe is not prefect. It's arguably a hack, not a Gecko
feature where, we, as privileged web developers work in a browser
company, proposed from bottom-up. I can see many proposed browser
features that could be at help (web components, shadow DOM, scoped
style, etc.), but waiting for these features is exactly what
preventing us from advancing the web. James would not establish AMD
modules if he decided to wait for Harmony -- and to his credit, AMD
helped established use cases for Harmony; and eventually, AMD modules
will be transformed to Harmony modules in a semi-automatically way and
the promise of advancing the web will be fulfilled.
I see the same thing in the proposed sandbox iframe use case, even
though I know they are banana and orange.
To sum up,
-- Memory optimization is a bonus. This proposal is not just about that.
-- Isolation of the scripts; make it testable and maintainable is what
I most valued. It can only be achieved through runtime limitation.
-- Gaia-wide pattern can still be flexible in the future and adopts
the real fix in the future. Everybody-writes-it-own-controller, in
contrast, is not.
With that, I think we could spare some resources to try out this idea
on an app, maybe have a intern to work on it in parallel so we could
still ship code under tight schedule. We would only land it if
everything checks out (performance, possible race, etc.).
>> Regardless of personal preferences and outlooks for the future, I urge
>> this group to not take any decision without first seeing hard perf
>> data. I've seen too many times people on this project say 'I think
>> this group to not take any decision without first seeing hard perf
>> this should be faster.' The only way to know if it is indeed faster is
>> to have numbers.
>>
>> Implement a prototype, run performance tests, calculate the means and
>> the standard deviations and run a t-test to understand if the perceived
>> difference in means is statistically significant. It's easy and it
>> helps you understand whether or not you're making real progress.
>>
>> the standard deviations and run a t-test to understand if the perceived
>> difference in means is statistically significant. It's easy and it
>> helps you understand whether or not you're making real progress.
>>
>> * * *
>>
>> As far as my own opinion goes, I'll echo Kevin's words: do we really
>> want developers to code this way? Is this what the future of HTML
>> looks like according to Mozilla?
>>
>>
>> As far as my own opinion goes, I'll echo Kevin's words: do we really
>> want developers to code this way? Is this what the future of HTML
>> looks like according to Mozilla?
>>
>> Maybe I was naïve but I was hoping that the reason why we did all these
>> hacky optimization was the hardware that the first version of Gaia was
>> supposed to run on. I was hoping that the second generation of the
>> devices will let us go back to coding things normally. In a more webby
>> way, without resorting to <!-- html comments --> and without having to
>> inline all localizations as a JSON blog in the HTML file.
>>
>> hacky optimization was the hardware that the first version of Gaia was
>> supposed to run on. I was hoping that the second generation of the
>> devices will let us go back to coding things normally. In a more webby
>> way, without resorting to <!-- html comments --> and without having to
>> inline all localizations as a JSON blog in the HTML file.
>>
>> Digression: Did you know that because of the build-time optimization
>> which inlines localizations as JSON in the HTML file, the memory
>> consumption increases and the app start-up slows down linearly to the
>> number of locales. Each locale costs about 20ms of the start up time.
>> which inlines localizations as JSON in the HTML file, the memory
>> consumption increases and the app start-up slows down linearly to the
>> number of locales. Each locale costs about 20ms of the start up time.
>> See this bug:
>>
>> https://bugzilla.mozilla.org/show_bug.cgi?id=853933
>>
>> I guess in this particular case, the iframe proposal would help (see
>> below). But I tend to think that the real solution would be to fix the
>> localization framework such that it doesn't need the inlined JSON blobs
>> at all.
>>
>>
>> https://bugzilla.mozilla.org/show_bug.cgi?id=853933
>>
>> I guess in this particular case, the iframe proposal would help (see
>> below). But I tend to think that the real solution would be to fix the
>> localization framework such that it doesn't need the inlined JSON blobs
>> at all.
>>
>> Same goes for everything else. I'd like to see us advancing the Web
>> and pushing the technology forward so that these hacks are not needed.
>> and pushing the technology forward so that these hacks are not needed.
>> Shoehorning iframes to give us better memory management sounds like
>> something that will come back to haunt us in the future.
>>
>>
>> something that will come back to haunt us in the future.
>>
>>
>> Quoting Vivien (2013-06-12 16:06:06)
>>> Possible issues:
>>> a. Global states cannot be shared.
>>> b. Load time for each panels
>>> 1. JavaScript files / libraries needs to be replicated.
>>> 2. CSS files need to be replicated.
>>> 3. Assets needs to be replicated.
>>> c. Memory overhead for each compartments
>>>
>>> I have probably forgot some obvious things, please feel free to add to
>>> the list!
>>
>> Not sure if it counts as "b3. Assets", but I'd like to put localization
>> files somewhere on this list, too.
>>
>>> Possible issues:
>>> a. Global states cannot be shared.
>>> b. Load time for each panels
>>> 1. JavaScript files / libraries needs to be replicated.
>>> 2. CSS files need to be replicated.
>>> 3. Assets needs to be replicated.
>>> c. Memory overhead for each compartments
>>>
>>> I have probably forgot some obvious things, please feel free to add to
>>> the list!
>>
>> Not sure if it counts as "b3. Assets", but I'd like to put localization
>> files somewhere on this list, too.
>>
>> If Gaia apps end up split in mutliple HTML files, I think it would make
>> sense to split the related localization files as well. This should
>> rather straight-forward and shouldn't impact the l10n ecosystem much.
>>
>> sense to split the related localization files as well. This should
>> rather straight-forward and shouldn't impact the l10n ecosystem much.
>>
>> An alternative would be to continue loading all of l10n in the main
>> HTML file and postMessage localized strings to each panel. However, if
>> we can be lazy about the translation of unseen panels, I think we
>> should.
>>
>> HTML file and postMessage localized strings to each panel. However, if
>> we can be lazy about the translation of unseen panels, I think we
>> should.
>>
>> (And if this proposal isn't approved, I still think we should find
>> a way to lazily load l10n resources for each <section role="region">.)
>>
>> a way to lazily load l10n resources for each <section role="region">.)
>>
>> -stas
>>
>> --
>> @stas
>> _______________________________________________
>> dev-gaia mailing list
>> dev-...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-gaia
>
> _______________________________________________
> dev-gaia mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-gaia
--
>>
>> --
>> @stas
>> _______________________________________________
>> dev-gaia mailing list
>> dev-...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-gaia
>
> _______________________________________________
> dev-gaia mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-gaia
Tim Guan-tin Chien, Engineering Manager and Front-end Lead, Firefox
OS, Mozilla Corp. (Taiwan)
Gordon Brander
Jun 13, 2013, 8:57:14 AM6/13/13
to Vivien, dev-...@lists.mozilla.org
On Jun 13, 2013, at 2:31 PM, Vivien <vnic...@mozilla.com> wrote:
> This thread is proposing to use a more URLs based approach with all what
it implies. The card controller is a side effect of this proposal in the
current form (that I honestly don't like).
Interestingly, this approach is not far from one that many iOS apps use. iOS's dirty secret is that many apps actually opt to juggle UIWebViews within a thin "controller" app. This shared-nothing approach has it's advantages:
> This thread is proposing to use a more URLs based approach with all what
it implies. The card controller is a side effect of this proposal in the
current form (that I honestly don't like).
* Stateless: state is serialized as URLs, making state-related bugs nonexistant
* Encapsulated: a page cares about what it renders and nothing else.
* Remote and local views can be easily mixed.
As others mentioned, this approach *is* different from the typical patterns found in *single page apps*. However, it is not terribly different from the way the web thinks: an app as a collection of shared-nothing interactive pages at URLs. Single page apps have eschewed the page model largely as a means to work around http delays causing breaks in the flow of the user experience.
The curious thing about Gaia's sliding panels pattern is that it is a deliberate break in the flow of the user experience to denote hierarchy. At a high-level it sounds like a pretty good fit to use what is essentially URLs & history to manage panel navigation history.
-Gordon
JOSE MANUEL CANTERA FONSECA
Jun 13, 2013, 9:51:19 AM6/13/13
to Fabien Cazenave, Vivien, dev-...@lists.mozilla.org
El 13/06/13 11:28, "Fabien Cazenave" <fab...@cazenave.cc> escribió:
>
> € a shared and minimalistic templating library allowing to use
would be happy to make it part of shared/js ...
https://github.com/telefonicaid/B2G-Utility-Libraries.JS/blob/master/compon
ents/templates/templates.js
>
>There are a bunch of such libs on github, I¹ll trust our talented
>front-end developers to propose good candidates that we could use and
>improve. If we need to rely on <iframe> elements behind the scenes to
>achieve a good performance then it¹s fine ‹ the sandbox argument makes a
>lot of sense, imho ‹ but I¹d prefer to abstract them properly.
>
>:kazé
>
> € a shared and minimalistic templating library allowing to use
>readable templates, and playing nice with localization process.
Already used in the Contacts App and recently adapted to remove eval. We
would be happy to make it part of shared/js ...
https://github.com/telefonicaid/B2G-Utility-Libraries.JS/blob/master/compon
ents/templates/templates.js
>
>There are a bunch of such libs on github, I¹ll trust our talented
>front-end developers to propose good candidates that we could use and
>improve. If we need to rely on <iframe> elements behind the scenes to
>achieve a good performance then it¹s fine ‹ the sandbox argument makes a
>lot of sense, imho ‹ but I¹d prefer to abstract them properly.
>
>:kazé
>_______________________________________________
>dev-gaia mailing list
>dev-...@lists.mozilla.org
>https://lists.mozilla.org/listinfo/dev-gaia
>
>dev-gaia mailing list
>dev-...@lists.mozilla.org
>https://lists.mozilla.org/listinfo/dev-gaia
>
Vivien
Jun 13, 2013, 10:02:33 AM6/13/13
to Alive Kuo, Staś Małolepszy, dev-...@lists.mozilla.org
On 13/06/2013 14:00, Alive Kuo wrote:
> I wrote this to agree what :stas said here.
> If a web developer is not working in a browser company,
> he should never have any chance to modify the platform every time he
> has some performance/memory/... issues when developing his website/webapp.
>
I agree. If page loading inside an iframe is an issue, it should be the
> I wrote this to agree what :stas said here.
> If a web developer is not working in a browser company,
> he should never have any chance to modify the platform every time he
> has some performance/memory/... issues when developing his website/webapp.
>
first thing to fix since a non-neglige-able time on the web is spent
loading pages and I have been told that web developers are spending a
lot of times on this.
So let's fix the platform for the benefit of everyone and let the
creativity of web developers be free to create tools on top of that.
> The platform hack -- forgive me to call it hack --
> if we're not promoting them(sandbox iframe) to web standards,
> really violates the value of a front-end developer.
>
> Yes we're so GIGA EXTREMELY lucky! We work at Mozilla, so we could
> gain some resource easily than others,
> to fix those problems by "poke" some colleagues who is working in
> gecko team to create some magic for us.
> And we really did so, many times in this project.
>
> But this time, this one, really sounds not be part of future web
> standards.
Sounds like to me that a solution based on <iframe>, sandbox, seamless,
> if we're not promoting them(sandbox iframe) to web standards,
> really violates the value of a front-end developer.
>
> Yes we're so GIGA EXTREMELY lucky! We work at Mozilla, so we could
> gain some resource easily than others,
> to fix those problems by "poke" some colleagues who is working in
> gecko team to create some magic for us.
> And we really did so, many times in this project.
>
> But this time, this one, really sounds not be part of future web
> standards.
SharedWorker, indexedDB in workers, etc.. is nothing more than using
standards?
>
> I didn't say I don't like any gecko convenient magic.
> If we don't have mozChromeEvent in system app we would still have a
> slow progress now.
> But at least they would become removed in the future I believe. And
> the scope is only limited in system app. No other app involved.(ANY?)
>
I agree. mozChromeEvent is evil imo and I hate it. But it was hard to do
> I didn't say I don't like any gecko convenient magic.
> If we don't have mozChromeEvent in system app we would still have a
> slow progress now.
> But at least they would become removed in the future I believe. And
> the scope is only limited in system app. No other app involved.(ANY?)
>
anything without it at some point of the project.
> And yes, the original targets of this proposal for sure should be
> addressed,
> but what's the real cause needs iframe hack instead of HTML lazy loading?
while all web browsers are doing it natively.
> Does iframe really save us from memory consumption?
sandbox-ed w/o same origin policy this is much harder to create
cross-compartment. This is like a remote website you load inside your
iframe. I tend to think that this mechanism as been correctly isolated.
> Is memory the only reason we need to abandon current design?
> I mean the app with some kind of refined architecture, like Calendar.
little bit the Gaia codebase (and for sure you do) that it does not
matter that much if we change the architecture of some apps. For apps
will a well defined architecture it is more questionable. I tend to
think that this can be done primarily on some of the apps where it won't
change much and then from what we learned there it can be applied to the
rest of the world if needed.
For example I'm pretty sure than many apps would be happy to leverage
workers, and possibly use a SharedWorker with indexedDB as a reaction to
a system message and connect to that worker when the user 'starts' the
app. The point is that application will benefit from the work for my
proposal since except the re-organization of the code of some apps, the
rest will be enhancement on the platform side. And third party authors
will still be able to install a dedicated framework that take advantages
/ use the platform capabilities.
>
> Also don't mix performance improvement with architecture refinement.
> They are different!
application then the performance of one apps would be affected by the
performance of other running apps in a really bad way.
I'm not saying this is true for all cases though. Some architecture
changes are really for cleaning reasons (i wish there is time for such
things...)
> The modularization and architecture, sometimes is not at the same side
> with performance no matter timing(startup) or space(memory).
> It's a trade-off.
was slowing down startup time drastically at the beginning. I still
think this was a necessary architecture.
>
> If we really really need to raise the performance anyway by any
> possible solution...
>
> If the device hardware is really really that bad…
>
> Then we couldn't avoid to sacrifice -- or destroy -- the
> architecture, and the proposal is just an example.
> As a web developer's point of view.
> --
> Alive C. Kuo, Front-end Eng., Mozilla Corp. (Taiwan, Taipei)
>
>> dev-gaia mailing list
>> dev-...@lists.mozilla.org <mailto:dev-...@lists.mozilla.org>
>> https://lists.mozilla.org/listinfo/dev-gaia
>
Ben Kelly
Jun 13, 2013, 10:26:59 AM6/13/13
to Staś Małolepszy, Vivien, dev-...@lists.mozilla.org
On Jun 13, 2013, at 7:09 AM, Staś Małolepszy <st...@mozilla.com> wrote:
> Regardless of personal preferences and outlooks for the future, I urge
> this group to not take any decision without first seeing hard perf
> data. I've seen too many times people on this project say 'I think
> this should be faster.' The only way to know if it is indeed faster is
> to have numbers.
>
> Implement a prototype, run performance tests, calculate the means and
> the standard deviations and run a t-test to understand if the perceived
> difference in means is statistically significant. It's easy and it
> helps you understand whether or not you're making real progress.
+1 for measurement and statistical significance.
> Regardless of personal preferences and outlooks for the future, I urge
> this group to not take any decision without first seeing hard perf
> data. I've seen too many times people on this project say 'I think
> this should be faster.' The only way to know if it is indeed faster is
> to have numbers.
>
> Implement a prototype, run performance tests, calculate the means and
> the standard deviations and run a t-test to understand if the perceived
> difference in means is statistically significant. It's easy and it
> helps you understand whether or not you're making real progress.
It sounds like so far we've looked at memory implications of this architecture. Thats important, but we have strong timing requirements as well. It would seem prudent to quantify the impact to timing before making a decision on project-wide direction. (Sorry if this was done and I missed it in the thread.)
Thanks!
Julien Wajsberg
Jun 13, 2013, 10:32:20 AM6/13/13
to Ben Kelly, Vivien, dev-...@lists.mozilla.org, Staś Małolepszy
Le 13/06/2013 16:26, Ben Kelly a écrit :
> On Jun 13, 2013, at 7:09 AM, Staś Małolepszy <st...@mozilla.com> wrote:
>> Regardless of personal preferences and outlooks for the future, I urge
>> this group to not take any decision without first seeing hard perf
>> data. I've seen too many times people on this project say 'I think
>> this should be faster.' The only way to know if it is indeed faster is
>> to have numbers.
>>
>> Implement a prototype, run performance tests, calculate the means and
>> the standard deviations and run a t-test to understand if the perceived
>> difference in means is statistically significant. It's easy and it
>> helps you understand whether or not you're making real progress.
> +1 for measurement and statistical significance.
>
> It sounds like so far we've looked at memory implications of this architecture. Thats important, but we have strong timing requirements as well. It would seem prudent to quantify the impact to timing before making a decision on project-wide direction. (Sorry if this was done and I missed it in the thread.)
The promise is : less dom -> faster.
> On Jun 13, 2013, at 7:09 AM, Staś Małolepszy <st...@mozilla.com> wrote:
>> Regardless of personal preferences and outlooks for the future, I urge
>> this group to not take any decision without first seeing hard perf
>> data. I've seen too many times people on this project say 'I think
>> this should be faster.' The only way to know if it is indeed faster is
>> to have numbers.
>>
>> Implement a prototype, run performance tests, calculate the means and
>> the standard deviations and run a t-test to understand if the perceived
>> difference in means is statistically significant. It's easy and it
>> helps you understand whether or not you're making real progress.
> +1 for measurement and statistical significance.
>
> It sounds like so far we've looked at memory implications of this architecture. Thats important, but we have strong timing requirements as well. It would seem prudent to quantify the impact to timing before making a decision on project-wide direction. (Sorry if this was done and I missed it in the thread.)
Let's measure :)
--
Julien
David Bolter
Jun 13, 2013, 10:41:34 AM6/13/13
to Salvador de la Puente González, Matt Claypotch, tofumatt, dev-...@lists.mozilla.org, Julien Wajsberg
Using a common js UI library/framework happens to make solving
accessibility (via WAI-ARIA for example) tractable. We can put the
attributes in once and then users of the library have accidental
accessibility, which needless to say is an important part of Mozilla's
mission.
Cheers,
David
On 2013-06-13 3:29 AM, Salvador de la Puente González wrote:
> Hello folks
>
> We should throw framework panic away once forever. Nobody is encouraging
> to use heavy overhead frameworks but gathering best practices and
> offering a model to work on. It is only another step further than the
> utilities or mock modules from shared. The framework, in addition,
> should offer a secure, fast, device-friendly way of working.
>
> On 13/06/13 02:06, tofumatt wrote:
>> Right. It should be made clear, that jQuery is not a framework. Using
>> something like Backbone.js in gaia doesn't prevent us from being close
>> to the metal (I'd know, I've wrote two apps for FxOS with that setup,
>> including a Podcasts app that extensively uses a lot of "stock" JS),
>> but simply allows common tasks to be abstracted and a design pattern
>> across apps.
>>
>> Gaia code is harder to work on and will not benefit from the help of
>> many outside web developers as long as it eschews any form of
>> abstraction, as it will simply be too much to absorb for most
>> front-end web developers, good as they may be.
>>
>> - tofumatt | http://tofumatt.com
>>
>> On 2013-06-12, at 8:02 PM, Matt Claypotch <m...@potch.me> wrote:
>>
>>>
>>>
accessibility (via WAI-ARIA for example) tractable. We can put the
attributes in once and then users of the library have accidental
accessibility, which needless to say is an important part of Mozilla's
mission.
Cheers,
David
On 2013-06-13 3:29 AM, Salvador de la Puente González wrote:
> Hello folks
>
> We should throw framework panic away once forever. Nobody is encouraging
> to use heavy overhead frameworks but gathering best practices and
> offering a model to work on. It is only another step further than the
> utilities or mock modules from shared. The framework, in addition,
> should offer a secure, fast, device-friendly way of working.
>
> On 13/06/13 02:06, tofumatt wrote:
>> Right. It should be made clear, that jQuery is not a framework. Using
>> something like Backbone.js in gaia doesn't prevent us from being close
>> to the metal (I'd know, I've wrote two apps for FxOS with that setup,
>> including a Podcasts app that extensively uses a lot of "stock" JS),
>> but simply allows common tasks to be abstracted and a design pattern
>> across apps.
>>
>> Gaia code is harder to work on and will not benefit from the help of
>> many outside web developers as long as it eschews any form of
>> abstraction, as it will simply be too much to absorb for most
>> front-end web developers, good as they may be.
>>
>> - tofumatt | http://tofumatt.com
>>
>> On 2013-06-12, at 8:02 PM, Matt Claypotch <m...@potch.me> wrote:
>>
>>>
>>>
>>> On Wed, Jun 12, 2013 at 1:30 PM, Julien Wajsberg
>>> <jwaj...@mozilla.com> wrote:
>>> Something Vivien has not insisted on, is that lots of developers are
>>> developing on these Gaia apps. In the end, ensuring scoped context is
>>> what will help having consistent and maintenable apps.
>>>
>>> Another point is to _not_ use a framework. Trying to be as close as
>>> possible to the real stuff.
>>>
>>> I'll bite. Why _not_ use a framework? Why would you not encapsulate
>>> all your repeated best practices in a place where they all don't have
>>> to be repeated by the next person to touch the code? I haven't heard
>>> a compelling reason why a framework shouldn't be used.
>>>
>>>
>>> Something Vivien has not insisted on, is that lots of developers are
>>> developing on these Gaia apps. In the end, ensuring scoped context is
>>> what will help having consistent and maintenable apps.
>>>
>>> Another point is to _not_ use a framework. Trying to be as close as
>>> possible to the real stuff.
>>>
>>> I'll bite. Why _not_ use a framework? Why would you not encapsulate
>>> all your repeated best practices in a place where they all don't have
>>> to be repeated by the next person to touch the code? I haven't heard
>>> a compelling reason why a framework shouldn't be used.
>>>
>>>
>>> About performance, the only way to know is to try it. It's quite sure
>>> that having a less deep DOM tree will help reflows and repaint, but I
>>> agree that we can have unknown penalties too. Let's try on an easy app
>>> (like Clock).
>>>
>>> Le 12/06/2013 19:18, tofumatt a écrit :
>>>> So, this flies in the face of the way most front-end developers have
>>>> been writing client-side web apps since pretty much when that whole
>>>> business started. It strikes me as very confusing, something that
>>>> will reload libraries per-"panel" and something that would get very
>>>> heavy (or be useless) when you have many subviews.
>>>>
>>>> What's the issue with using an approach similar to Backbone or
>>>> whatever that removes views from memory and templates from the DOM
>>>> when they are no longer needed? And loading them on-demand? I've
>>>> been doing that with my Podcasts app for Firefox OS and performance,
>>>> memory usage, and developer happiness have all been great.
>>>>
>>>> Is this how we want third party developers to write their apps?
>>>> Frankly, if I looked at a web app and saw code like this I'd run the
>>>> other way. At all of the hack days I've attended, developers look at
>>>> gaia on how to write apps. This method seems very odd.
>>>>
>>>> Are there measurable performance gains to this? I'm at a loss as to
>>>> why this is better than something most client-side MVC frameworks.
>>>>
>>>> - tofumatt | http://tofumatt.com
>>>>
>>> that having a less deep DOM tree will help reflows and repaint, but I
>>> agree that we can have unknown penalties too. Let's try on an easy app
>>> (like Clock).
>>>
>>> Le 12/06/2013 19:18, tofumatt a écrit :
>>>> So, this flies in the face of the way most front-end developers have
>>>> been writing client-side web apps since pretty much when that whole
>>>> business started. It strikes me as very confusing, something that
>>>> will reload libraries per-"panel" and something that would get very
>>>> heavy (or be useless) when you have many subviews.
>>>>
>>>> What's the issue with using an approach similar to Backbone or
>>>> whatever that removes views from memory and templates from the DOM
>>>> when they are no longer needed? And loading them on-demand? I've
>>>> been doing that with my Podcasts app for Firefox OS and performance,
>>>> memory usage, and developer happiness have all been great.
>>>>
>>>> Is this how we want third party developers to write their apps?
>>>> Frankly, if I looked at a web app and saw code like this I'd run the
>>>> other way. At all of the hack days I've attended, developers look at
>>>> gaia on how to write apps. This method seems very odd.
>>>>
>>>> Are there measurable performance gains to this? I'm at a loss as to
>>>> why this is better than something most client-side MVC frameworks.
>>>>
>>>> - tofumatt | http://tofumatt.com
>>>>
>>>> On 2013-06-12, at 10:06 AM, Vivien <vnic...@mozilla.com> wrote:
>>>>
>>>>> Hello folks,
>>>>>
>>>>> Last year or so many Gaia apps has been built using a
>>>>> framework-less based approach, using a combination of libraries +
>>>>> css building blocks.
>>>>> In parallel, during last year a lot of things has been learned
>>>>> about device constraints, mobile constraints, app constraints,
>>>>> cross-teams-work constraints.
>>>>>
>>>>> -----------------
>>>>> Based on this here are some of those constraints (some are already
>>>>> partially solved) I would like to reach primarily:
>>>>> 1. *Fast loading application*
>>>>> Andreas said it a few times already. Apps should load in less
>>>>> than 600ms.
>>>>>
>>>>
>>>>> Hello folks,
>>>>>
>>>>> Last year or so many Gaia apps has been built using a
>>>>> framework-less based approach, using a combination of libraries +
>>>>> css building blocks.
>>>>> In parallel, during last year a lot of things has been learned
>>>>> about device constraints, mobile constraints, app constraints,
>>>>> cross-teams-work constraints.
>>>>>
>>>>> -----------------
>>>>> Based on this here are some of those constraints (some are already
>>>>> partially solved) I would like to reach primarily:
>>>>> 1. *Fast loading application*
>>>>> Andreas said it a few times already. Apps should load in less
>>>>> than 600ms.
>>>>>
>>>>> 2. *Low memory consumption*
>>>>> The memory of the device is limited. A limited number of
>>>>> applications can run at the same time. Less memory used means more
>>>>> applications can run at the same time.
>>>>>
>>>>> The memory of the device is limited. A limited number of
>>>>> applications can run at the same time. Less memory used means more
>>>>> applications can run at the same time.
>>>>>
>>>>> 3. *Stable memory consumption*
>>>>> It is OK to consume an extra memory while making a particular
>>>>> task of an application. But this memory needs to be freed once the
>>>>> task has been finished.
>>>>>
>>>>> It is OK to consume an extra memory while making a particular
>>>>> task of an application. But this memory needs to be freed once the
>>>>> task has been finished.
>>>>>
>>>>> 4. *Smooth panel transitions*
>>>>> Transitions should happen really quick after a hit on a button.
>>>>> Ideally a panel should be fully loaded when the transition is
>>>>> complete, but it sounds OK if informations such as the list of wifi
>>>>> networks around, loads delayed.
>>>>>
>>>>> Transitions should happen really quick after a hit on a button.
>>>>> Ideally a panel should be fully loaded when the transition is
>>>>> complete, but it sounds OK if informations such as the list of wifi
>>>>> networks around, loads delayed.
>>>>>
>>>>> 5. *Inline activities friendly*
>>>>> The whole application should not be required to be loaded for
>>>>> handling a particular operation.
>>>>>
>>>>> The whole application should not be required to be loaded for
>>>>> handling a particular operation.
>>>>>
>>>>> 6. *Scoped Panels*
>>>>> Panels should be independent. So a panel is directly responsible
>>>>> of its own load time and of any JS breakage it can generate. Also,
>>>>> an individual panel should not be able to break the application.
>>>>> Different authors can work on the same application and each of them
>>>>> would be directly responsible of one or many panels.
>>>>>
>>>>> Panels should be independent. So a panel is directly responsible
>>>>> of its own load time and of any JS breakage it can generate. Also,
>>>>> an individual panel should not be able to break the application.
>>>>> Different authors can work on the same application and each of them
>>>>> would be directly responsible of one or many panels.
>>>>>
>>>>> It sounds me that is could be a good set of constraints to solve
>>>>> with a framewor-less based approach, using a combination of
>>>>> libraries + css building blocks... and html.
>>>>>
>>>>> (There are other issues obviously and some of them are already
>>>>> handled by brave folks, like Tim and others in Taipei working on
>>>>> multiple resolutions support for example. Also, I have omit
>>>>> voluntarily the specific set of issues of the System app, which is
>>>>> similar in some cases, but has some special cases too IMHO)
>>>>>
>>>>> -----------------
>>>>> The proposal:
>>>>>
>>>>> <iframe mozbrowser
>>>>> mozapp="app://myapp.gaiamobile.org/myapp.manifest"
>>>>> src="app://myapp.gaiamobile.org/index.html">
>>>>> <!doctype html>
>>>>> <html>
>>>>> <head>
>>>>> with a framewor-less based approach, using a combination of
>>>>> libraries + css building blocks... and html.
>>>>>
>>>>> (There are other issues obviously and some of them are already
>>>>> handled by brave folks, like Tim and others in Taipei working on
>>>>> multiple resolutions support for example. Also, I have omit
>>>>> voluntarily the specific set of issues of the System app, which is
>>>>> similar in some cases, but has some special cases too IMHO)
>>>>>
>>>>> -----------------
>>>>> The proposal:
>>>>>
>>>>> <iframe mozbrowser
>>>>> mozapp="app://myapp.gaiamobile.org/myapp.manifest"
>>>>> src="app://myapp.gaiamobile.org/index.html">
>>>>> <!doctype html>
>>>>> <html>
>>>>> <head>
>>>>> <!-- This is a dirty little js lib that handle navigation
>>>>> between panels with a local postMessage protocol -->
>>>>> <!-- XXX Please don't focus tptionoo much on it - there are
>>>>> some plans to get rid of it in a potential near future but this
>>>>> discussion is way out of the scope of this proposal and I
>>>>> don't want to mix both discussions -->
>>>>> <script src="shared/js/navigation.js"></script>
>>>>> between panels with a local postMessage protocol -->
>>>>> <!-- XXX Please don't focus tptionoo much on it - there are
>>>>> some plans to get rid of it in a potential near future but this
>>>>> discussion is way out of the scope of this proposal and I
>>>>> don't want to mix both discussions -->
>>>>> <script src="shared/js/navigation.js"></script>
>>>>> </head>
>>>>>
>>>>> <body>
>>>>> <!-- This panel will be created only once the application has
>>>>> loaded. Or it could be directly included in the html if the author
>>>>> wants to delay the mozbrowserloadend event for some reasons -->
>>>>> <iframe sandbox="allow-scripts allow-forms"
>>>>> src="main-panel.html"></iframe>
>>>>>
>>>>> <!-- This iframe will be created only once the user has made
>>>>> a choice in the main-panel -->
>>>>> <iframe sandbox="allow-scripts allow-forms"
>>>>> src="next-panel.html"></iframe>
>>>>>
>>>>> <!-- this iframe will be created only once the user has made
>>>>> a choice in the next panel -->
>>>>> <iframe sandbox="allow-scripts allow-forms"
>>>>> src="next-next-panel.html"></iframe>
>>>>>
>>>>> <!-- Back buttons that lives outside of the panels. A user
>>>>> will always be able to exit a panel even if this one breaks -->
>>>>> <button id="back">
>>>>> </body>
>>>>> </html>
>>>>> </iframe>
>>>>>
>>>>> This is mostly it.
>>>>>
>>>>>
>>>>> <body>
>>>>> <!-- This panel will be created only once the application has
>>>>> loaded. Or it could be directly included in the html if the author
>>>>> wants to delay the mozbrowserloadend event for some reasons -->
>>>>> <iframe sandbox="allow-scripts allow-forms"
>>>>> src="main-panel.html"></iframe>
>>>>>
>>>>> <!-- This iframe will be created only once the user has made
>>>>> a choice in the main-panel -->
>>>>> <iframe sandbox="allow-scripts allow-forms"
>>>>> src="next-panel.html"></iframe>
>>>>>
>>>>> <!-- this iframe will be created only once the user has made
>>>>> a choice in the next panel -->
>>>>> <iframe sandbox="allow-scripts allow-forms"
>>>>> src="next-next-panel.html"></iframe>
>>>>>
>>>>> <!-- Back buttons that lives outside of the panels. A user
>>>>> will always be able to exit a panel even if this one breaks -->
>>>>> <button id="back">
>>>>> </body>
>>>>> </html>
>>>>> </iframe>
>>>>>
>>>>> This is mostly it.
>>>>>
>>>>> Basically the <navigation.js> helper creates sandbox-ed <iframe>s
>>>>> on demand and handle the navigation, as well as the back button.
>>>>>
>>>>> As long the user navigates forward, new sandbox-ed <iframe>s are
>>>>> created. As soon the user hit the back button the last <iframe> is
>>>>> removed in order to free the relevant part of memory. Since
>>>>> <iframe>s are sandboxed without the allow-same-origin flag, the
>>>>> only way to communicate should be postMessage and data would be
>>>>> serialized that should prevent references to each other and
>>>>> guarantee that the memory will be freed.
>>>>>
>>>>> on demand and handle the navigation, as well as the back button.
>>>>>
>>>>> As long the user navigates forward, new sandbox-ed <iframe>s are
>>>>> created. As soon the user hit the back button the last <iframe> is
>>>>> removed in order to free the relevant part of memory. Since
>>>>> <iframe>s are sandboxed without the allow-same-origin flag, the
>>>>> only way to communicate should be postMessage and data would be
>>>>> serialized that should prevent references to each other and
>>>>> guarantee that the memory will be freed.
>>>>>
>>>>> I feel like this will address 1., 2. and 3. since the memory used
>>>>> will be directly related to the real user activity and it will be
>>>>> freed once it is done. Also, an application will be able to detach
>>>>> the previous state of the application to save some memory if
>>>>> needed. (For example the settings app would be able to detach the
>>>>> <iframe src="main-panel.html"> if the user has finished the
>>>>> activity but, instead of going back to the application starts using
>>>>> the back button, he/she hits the home button, leaving completely
>>>>> the app to do something else.
>>>>>
>>>>> will be directly related to the real user activity and it will be
>>>>> freed once it is done. Also, an application will be able to detach
>>>>> the previous state of the application to save some memory if
>>>>> needed. (For example the settings app would be able to detach the
>>>>> <iframe src="main-panel.html"> if the user has finished the
>>>>> activity but, instead of going back to the application starts using
>>>>> the back button, he/she hits the home button, leaving completely
>>>>> the app to do something else.
>>>>>
>>>>> Possible issues:
>>>>> a. Global states cannot be shared.
>>>>> b. Load time for each panels
>>>>> 1. JavaScript files / libraries needs to be replicated.
>>>>> 2. CSS files need to be replicated.
>>>>> 3. Assets needs to be replicated.
>>>>> c. Memory overhead for each compartments
>>>>>
>>>>> I have probably forgot some obvious things, please feel free to add
>>>>> to the list!
>>>>>
>>>>> a. Global states cannot be shared.
>>>>> b. Load time for each panels
>>>>> 1. JavaScript files / libraries needs to be replicated.
>>>>> 2. CSS files need to be replicated.
>>>>> 3. Assets needs to be replicated.
>>>>> c. Memory overhead for each compartments
>>>>>
>>>>> I have probably forgot some obvious things, please feel free to add
>>>>> to the list!
>>>>>
>>>>> _______________________________________________
>>>>> dev-gaia mailing list
>>>>> dev-...@lists.mozilla.org
>>>>> https://lists.mozilla.org/listinfo/dev-gaia
>>>> _______________________________________________
>>>> dev-gaia mailing list
>>>> dev-...@lists.mozilla.org
>>>> https://lists.mozilla.org/listinfo/dev-gaia
>>>
>>>
>>> _______________________________________________
>>> dev-gaia mailing list
>>> dev-...@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-gaia
>>>
>>>
>> _______________________________________________
>> dev-gaia mailing list
>> dev-...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-gaia
>>
>
>
>>>>> dev-gaia mailing list
>>>>> dev-...@lists.mozilla.org
>>>>> https://lists.mozilla.org/listinfo/dev-gaia
>>>> _______________________________________________
>>>> dev-gaia mailing list
>>>> dev-...@lists.mozilla.org
>>>> https://lists.mozilla.org/listinfo/dev-gaia
>>>
>>>
>>> _______________________________________________
>>> dev-gaia mailing list
>>> dev-...@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-gaia
>>>
>>>
>> _______________________________________________
>> dev-gaia mailing list
>> dev-...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-gaia
>>
>
>
> ________________________________
>
> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
> nuestra política de envío y recepción de correo electrónico en el enlace
> situado más abajo.
> This message is intended exclusively for its addressee. We only send and
> receive email on the basis of the terms set out at:
> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
>
> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
> nuestra política de envío y recepción de correo electrónico en el enlace
> situado más abajo.
> This message is intended exclusively for its addressee. We only send and
> receive email on the basis of the terms set out at:
> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
Vivien
Jun 13, 2013, 11:05:09 AM6/13/13
to dev-...@lists.mozilla.org
On 13/06/2013 16:41, David Bolter wrote:
> Using a common js UI library/framework happens to make solving
> accessibility (via WAI-ARIA for example) tractable. We can put the
> attributes in once and then users of the library have accidental
> accessibility, which needless to say is an important part of Mozilla's
> mission.
Thanks for putting accessibility on the table. The model does not impose
> Using a common js UI library/framework happens to make solving
> accessibility (via WAI-ARIA for example) tractable. We can put the
> attributes in once and then users of the library have accidental
> accessibility, which needless to say is an important part of Mozilla's
> mission.
any restrictions on what you can use inside an <iframe>. If third-party
developers have a UI library to use that sounds good.
It is a different thread and I don't want to pollute this one but I was
curious about how it is supposed to work on b2g right now. Can we
continue the discussion in
https://bugzilla.mozilla.org/show_bug.cgi?id=875040 ?
Jordano Francisco (UK)
Jun 13, 2013, 11:02:30 AM6/13/13
to Fabien Cazenave, Vivien, mozilla-...@lists.mozilla.org, dev-...@lists.mozilla.org
Hi all,
I have to agree with Kevin Grandon and Matt Calypotch, usually first
approach from external developers to FFOS is take a look to Gaia, and
don't think that the iframes approach looks pretty familiar to developers.
At the end of the day we want to be as web friendly as possible, and I
don't see right now web developers using that in their web apps for
desktop, webviews, webkit using backbone, angular, twitter flight or any
other fancy thing.
On 13/06/2013 10:28, "Fabien Cazenave" <fab...@cazenave.cc> wrote:
>I don¹t want to tie Gaia with any framework either, and I think our ³one
needed code (routing, temptlating, utilities Š), call it framework or not,
as long as we keep it simple. And specially something that anyone could
use outside this project, or something that is outside already and we want
to add.
Regarding the comments about checking first performance, I'm sure we are
all in the same page about this :)
Cheers!
F.
I have to agree with Kevin Grandon and Matt Calypotch, usually first
approach from external developers to FFOS is take a look to Gaia, and
don't think that the iframes approach looks pretty familiar to developers.
At the end of the day we want to be as web friendly as possible, and I
don't see right now web developers using that in their web apps for
desktop, webviews, webkit using backbone, angular, twitter flight or any
other fancy thing.
On 13/06/2013 10:28, "Fabien Cazenave" <fab...@cazenave.cc> wrote:
>I don¹t want to tie Gaia with any framework either, and I think our ³one
>lib for one need² approach makes perfect sense. I think we¹ve come to a
>point where quite a few apps would benefit from:
>
> € a shared and minimalistic routing library that helps using Gecko¹s
>fast paths and sharing a common navigation UX;
>
>point where quite a few apps would benefit from:
>
> € a shared and minimalistic routing library that helps using Gecko¹s
>fast paths and sharing a common navigation UX;
>
> € a shared and minimalistic templating library allowing to use
>readable templates, and playing nice with localization process.
>
>readable templates, and playing nice with localization process.
>
>There are a bunch of such libs on github, I¹ll trust our talented
>front-end developers to propose good candidates that we could use and
>improve. If we need to rely on <iframe> elements behind the scenes to
>achieve a good performance then it¹s fine ‹ the sandbox argument makes a
>lot of sense, imho ‹ but I¹d prefer to abstract them properly.
I like this approach, let's define a minimal set of optimised libraries or
>front-end developers to propose good candidates that we could use and
>improve. If we need to rely on <iframe> elements behind the scenes to
>achieve a good performance then it¹s fine ‹ the sandbox argument makes a
>lot of sense, imho ‹ but I¹d prefer to abstract them properly.
needed code (routing, temptlating, utilities Š), call it framework or not,
as long as we keep it simple. And specially something that anyone could
use outside this project, or something that is outside already and we want
to add.
Regarding the comments about checking first performance, I'm sure we are
all in the same page about this :)
Cheers!
F.
Jordano Francisco (UK)
Jun 13, 2013, 11:02:30 AM6/13/13
to Fabien Cazenave, Vivien, mozilla-...@lists.mozilla.org, dev-...@lists.mozilla.org
Harald Kirschner
Jun 13, 2013, 12:27:16 PM6/13/13
to Jordano Francisco (UK), Vivien, Fabien Cazenave, dev-...@lists.mozilla.org, mozilla-...@lists.mozilla.org
There seem to be several directions this discussion is going, mostly not about what challenges Vivien wanted to solve with this proposal.
I would not focus on the iframe's bringing confusion to potential developers that look for best practices. IFrames will not be front and center of the code but just an implementation detail; abstracted in a reusable component (maybe x-tags), working for you under the hood so you don't need to manage life-cycles for iframes. Abstracting this further, I could even imagine that if iframes prove to solve the targeted problems we bring out a custom Backbone extension for developers that also uses iframes to sandbox card views.
Some Gaia apps already use reusable components or even libraries (page.js in Calendar, async_storage.js all over the place), so I don't think pro/contra frameworks should be the second thread in this discussion. As long as they solve a specific problem and are not bloated, they seem to be accepted in gaia.
I definitely agree with the argument that memory use/spikes and performance, 3 of the problems Vivien wants to address, might be negatively affected by the overhead added by iframes; so some performance tests in that direction would help a lot to prove feasibility.
---
Harald Kirschner | Partner Engineer & Web Craftsman | har...@mozilla.com (mailto:hkirs...@mozilla.com)
On Thursday, June 13, 2013 at 8:02 AM, Jordano Francisco (UK) wrote:
> Hi all,
>
> I have to agree with Kevin Grandon and Matt Calypotch, usually first
> approach from external developers to FFOS is take a look to Gaia, and
> don't think that the iframes approach looks pretty familiar to developers.
> At the end of the day we want to be as web friendly as possible, and I
> don't see right now web developers using that in their web apps for
> desktop, webviews, webkit using backbone, angular, twitter flight or any
> other fancy thing.
>
> dev-gaia mailing list
> dev-...@lists.mozilla.org (mailto:dev-...@lists.mozilla.org)
> https://lists.mozilla.org/listinfo/dev-gaia
>
>
I would not focus on the iframe's bringing confusion to potential developers that look for best practices. IFrames will not be front and center of the code but just an implementation detail; abstracted in a reusable component (maybe x-tags), working for you under the hood so you don't need to manage life-cycles for iframes. Abstracting this further, I could even imagine that if iframes prove to solve the targeted problems we bring out a custom Backbone extension for developers that also uses iframes to sandbox card views.
Some Gaia apps already use reusable components or even libraries (page.js in Calendar, async_storage.js all over the place), so I don't think pro/contra frameworks should be the second thread in this discussion. As long as they solve a specific problem and are not bloated, they seem to be accepted in gaia.
I definitely agree with the argument that memory use/spikes and performance, 3 of the problems Vivien wants to address, might be negatively affected by the overhead added by iframes; so some performance tests in that direction would help a lot to prove feasibility.
---
Harald Kirschner | Partner Engineer & Web Craftsman | har...@mozilla.com (mailto:hkirs...@mozilla.com)
On Thursday, June 13, 2013 at 8:02 AM, Jordano Francisco (UK) wrote:
> Hi all,
>
> I have to agree with Kevin Grandon and Matt Calypotch, usually first
> approach from external developers to FFOS is take a look to Gaia, and
> don't think that the iframes approach looks pretty familiar to developers.
> At the end of the day we want to be as web friendly as possible, and I
> don't see right now web developers using that in their web apps for
> desktop, webviews, webkit using backbone, angular, twitter flight or any
> other fancy thing.
>
> On 13/06/2013 10:28, "Fabien Cazenave" <fab...@cazenave.cc (mailto:fab...@cazenave.cc)> wrote:
>
> > I don¹t want to tie Gaia with any framework either, and I think our ³one
> > lib for one need² approach makes perfect sense. I think we¹ve come to a
> > point where quite a few apps would benefit from:
> >
> > € a shared and minimalistic routing library that helps using Gecko¹s
> > fast paths and sharing a common navigation UX;
> >
> > € a shared and minimalistic templating library allowing to use
> > readable templates, and playing nice with localization process.
> >
> > There are a bunch of such libs on github, I¹ll trust our talented
> > front-end developers to propose good candidates that we could use and
> > improve. If we need to rely on <iframe> elements behind the scenes to
> > achieve a good performance then it¹s fine ‹ the sandbox argument makes a
> > lot of sense, imho ‹ but I¹d prefer to abstract them properly.
> >
>
>
> I like this approach, let's define a minimal set of optimised libraries or
> needed code (routing, temptlating, utilities Š), call it framework or not,
> as long as we keep it simple. And specially something that anyone could
> use outside this project, or something that is outside already and we want
> to add.
>
> Regarding the comments about checking first performance, I'm sure we are
> all in the same page about this :)
>
> Cheers!
> F.
>
> _______________________________________________
>
> > I don¹t want to tie Gaia with any framework either, and I think our ³one
> > lib for one need² approach makes perfect sense. I think we¹ve come to a
> > point where quite a few apps would benefit from:
> >
> > € a shared and minimalistic routing library that helps using Gecko¹s
> > fast paths and sharing a common navigation UX;
> >
> > € a shared and minimalistic templating library allowing to use
> > readable templates, and playing nice with localization process.
> >
> > There are a bunch of such libs on github, I¹ll trust our talented
> > front-end developers to propose good candidates that we could use and
> > improve. If we need to rely on <iframe> elements behind the scenes to
> > achieve a good performance then it¹s fine ‹ the sandbox argument makes a
> > lot of sense, imho ‹ but I¹d prefer to abstract them properly.
> >
>
>
> I like this approach, let's define a minimal set of optimised libraries or
> needed code (routing, temptlating, utilities Š), call it framework or not,
> as long as we keep it simple. And specially something that anyone could
> use outside this project, or something that is outside already and we want
> to add.
>
> Regarding the comments about checking first performance, I'm sure we are
> all in the same page about this :)
>
> Cheers!
> F.
>
> dev-gaia mailing list
> dev-...@lists.mozilla.org (mailto:dev-...@lists.mozilla.org)
> https://lists.mozilla.org/listinfo/dev-gaia
>
>
Harald Kirschner
Jun 13, 2013, 12:27:16 PM6/13/13
to Jordano Francisco (UK), Vivien, Fabien Cazenave, dev-...@lists.mozilla.org, mozilla-...@lists.mozilla.org
Vivien
Jun 13, 2013, 12:52:54 PM6/13/13
to Jordano Francisco (UK), Fabien Cazenave, mozilla-...@lists.mozilla.org, dev-...@lists.mozilla.org
On 13/06/2013 17:02, Jordano Francisco (UK) wrote:
> Hi all,
>
> I have to agree with Kevin Grandon and Matt Calypotch, usually first
> approach from external developers to FFOS is take a look to Gaia, and
> don't think that the iframes approach looks pretty familiar to developers.
I can understand that Gaia is what people look at, but it does not seems
> Hi all,
>
> I have to agree with Kevin Grandon and Matt Calypotch, usually first
> approach from external developers to FFOS is take a look to Gaia, and
> don't think that the iframes approach looks pretty familiar to developers.
a goal of the project. It seems to me it happens because of the lack of
external resources. Having somewhere a generator of manifests, simple
and easy to use templates, couple with clear mdn resources about how to
use such or such APIs should be all they need. I understand that it
takes time to do that as well.
If they are curious, or if the doc is not enough, they can look at Gaia
and I don't really see how an iframe/URLs based architecture change
anything to them versus looking at a regular webpage. There will still
be different approach in many apps to solve different problems but the
resources (scripts, css, assets, locales) will be scoped by url and
that's it.
So IMO other teams needs to create resources and evangelize around
external resources ( I was hoping that
https://developer.mozilla.org/en-US/docs/Web/Apps/Getting_Started would
have been a good resource for them).
> At the end of the day we want to be as web friendly as possible, and I
> don't see right now web developers using that in their web apps for
> desktop, webviews, webkit using backbone, angular, twitter flight or any
> other fancy thing.
want. If they don't want to use Gaia pattern, this is probably because
they have a different set of issues to resolve - I encourage them to do so.
Gaia is not and has never been a tool to promote a special way of
writing an application. At a pure Gaia level I want to make sure Gaia
applications are performant, memory aware, with clear distinction
between panels so responsibilities can be easily established. That
sounds insane to architect a software to make it looks sexier for third
party because there is a lack of external resources.
>
> On 13/06/2013 10:28, "Fabien Cazenave" <fab...@cazenave.cc> wrote:
>
>> I don¹t want to tie Gaia with any framework either, and I think our ³one
>> lib for one need² approach makes perfect sense. I think we¹ve come to a
>> point where quite a few apps would benefit from:
>>
>> € a shared and minimalistic routing library that helps using Gecko¹s
>> fast paths and sharing a common navigation UX;
>>
>> € a shared and minimalistic templating library allowing to use
>> readable templates, and playing nice with localization process.
>>
>> There are a bunch of such libs on github, I¹ll trust our talented
>> front-end developers to propose good candidates that we could use and
>> improve. If we need to rely on <iframe> elements behind the scenes to
>> achieve a good performance then it¹s fine ‹ the sandbox argument makes a
>> lot of sense, imho ‹ but I¹d prefer to abstract them properly.
> I like this approach, let's define a minimal set of optimised libraries or
> needed code (routing, temptlating, utilities Š), call it framework or not,
> as long as we keep it simple.
trickier because it enforce a way to write your html/js and force a js
pass before rendering anything when it could have been directly
outputted on the screen. This is an interesting side discussion but this
proposal won't prevent you to use the same template mechanism that is
already present in the contacts app. The discussion about the initial
problem and the proposal issues would be really hard if we diverged on
this too much and the goldwin point will be reach soon...
> And specially something that anyone could
> use outside this project, or something that is outside already and we want
> to add.
That sounds an orthogonal problem. James has already proposed to exposed
> use outside this project, or something that is outside already and we want
> to add.
some of the shared/ libs to the rest of the world. We would accept
patches but I do not believe that there are the resources to promess
anything else except that (like multi-browser supports, new features and
so on).
Again I feel like people tends to think the <iframe>s mechanism would
change anything in the libs they can / can not use inside the context of
their page. It won't. Sure it will change a few architectural things for
the internal code of each panel but it won't prevent you to use /name of
your preferred lib-utilities-framework/ here.
>
> Regarding the comments about checking first performance, I'm sure we are
> all in the same page about this :)
>
> Cheers!
> F.
>
As a summary if you want to promote some Gaia libs to the external world
> Regarding the comments about checking first performance, I'm sure we are
> all in the same page about this :)
>
> Cheers!
> F.
>
you are free to do so. James will likely be interested and some others
as well. But let's not limit Gaia changes because of how sexier/usual it
will be for third party authors if they end looking at it for a whole
set of reasons.
Vivien
Jun 13, 2013, 12:52:54 PM6/13/13
to Jordano Francisco (UK), Fabien Cazenave, mozilla-...@lists.mozilla.org, dev-...@lists.mozilla.org
Vivien
Jun 13, 2013, 1:08:39 PM6/13/13
to Harald Kirschner, Jordano Francisco (UK), Fabien Cazenave, dev-...@lists.mozilla.org, mozilla-...@lists.mozilla.org
On 13/06/2013 18:27, Harald Kirschner wrote:
> There seem to be several directions this discussion is going, mostly
> not about what challenges Vivien wanted to solve with this proposal.
>
> I would not focus on the iframe's bringing confusion to potential
> developers that look for best practices. IFrames will not be front and
> center of the code but just an implementation detail; abstracted in a
> reusable component (maybe x-tags), working for you under the hood so
> you don't need to manage life-cycles for iframes. Abstracting this
> further, I could even imagine that if iframes prove to solve the
> targeted problems we bring out a custom Backbone extension for
> developers that also uses iframes to sandbox card views.
>
> Some Gaia apps already use reusable components or
> even libraries (page.js in Calendar, async_storage.js all over the
> place), so I don't think pro/contra frameworks should be the second
> thread in this discussion. As long as they solve a specific problem
> and are not bloated, they seem to be accepted in gaia.
>
> I definitely agree with the argument that memory use/spikes and
> performance, 3 of the problems Vivien wants to address, might be
> negatively affected by the overhead added by iframes; so some
> performance tests in that direction would help a lot to prove feasibility.
Thanks for bringing the core of the proposal back on the table!
> There seem to be several directions this discussion is going, mostly
> not about what challenges Vivien wanted to solve with this proposal.
>
> I would not focus on the iframe's bringing confusion to potential
> developers that look for best practices. IFrames will not be front and
> center of the code but just an implementation detail; abstracted in a
> reusable component (maybe x-tags), working for you under the hood so
> you don't need to manage life-cycles for iframes. Abstracting this
> further, I could even imagine that if iframes prove to solve the
> targeted problems we bring out a custom Backbone extension for
> developers that also uses iframes to sandbox card views.
>
> Some Gaia apps already use reusable components or
> even libraries (page.js in Calendar, async_storage.js all over the
> place), so I don't think pro/contra frameworks should be the second
> thread in this discussion. As long as they solve a specific problem
> and are not bloated, they seem to be accepted in gaia.
>
> I definitely agree with the argument that memory use/spikes and
> performance, 3 of the problems Vivien wants to address, might be
> negatively affected by the overhead added by iframes; so some
> performance tests in that direction would help a lot to prove feasibility.
As I said in the first email it seems to be a 280k at least of overhead
per non-seamless (not implemented) sandbox-ed iframe (100k of js + 180k
of layout where 140k are the same css data recompute for every iframes).
Also I won't be confident about my measurements until some platform
folks confirms it since my about:memory skills are a mix of mxr search
and guess.
Also those measurements does not take into account scripts/css
duplication. There are also platform bugs numbers in the initial
proposal as some potential helpers for those memory overhead though.
The explicit scope for resources are expected to help on those points
though.
In any case I agree that a prototype with performance data should drive
the discussion at some point.
>
> ---
> Harald Kirschner | Partner Engineer & Web Craftsman
>
> On Thursday, June 13, 2013 at 8:02 AM, Jordano Francisco (UK) wrote:
>
>> Hi all,
>>
>> I have to agree with Kevin Grandon and Matt Calypotch, usually first
>> approach from external developers to FFOS is take a look to Gaia, and
>> don't think that the iframes approach looks pretty familiar to
>> developers.
> On Thursday, June 13, 2013 at 8:02 AM, Jordano Francisco (UK) wrote:
>
>> Hi all,
>>
>> I have to agree with Kevin Grandon and Matt Calypotch, usually first
>> approach from external developers to FFOS is take a look to Gaia, and
>> don't think that the iframes approach looks pretty familiar to
>> developers.
>> At the end of the day we want to be as web friendly as possible, and I
>> don't see right now web developers using that in their web apps for
>> desktop, webviews, webkit using backbone, angular, twitter flight or any
>> other fancy thing.
>>
>> don't see right now web developers using that in their web apps for
>> desktop, webviews, webkit using backbone, angular, twitter flight or any
>> other fancy thing.
>>
>> On 13/06/2013 10:28, "Fabien Cazenave" <fab...@cazenave.cc
>> <mailto:fab...@cazenave.cc>> wrote:
>>
>>> I don¹t want to tie Gaia with any framework either, and I think our ³one
>>> lib for one need² approach makes perfect sense. I think we¹ve come to a
>>> point where quite a few apps would benefit from:
>>>
>>> € a shared and minimalistic routing library that helps using Gecko¹s
>>> fast paths and sharing a common navigation UX;
>>>
>>> € a shared and minimalistic templating library allowing to use
>>> readable templates, and playing nice with localization process.
>>>
>>> There are a bunch of such libs on github, I¹ll trust our talented
>>> front-end developers to propose good candidates that we could use and
>>> improve. If we need to rely on <iframe> elements behind the scenes to
>>> achieve a good performance then it¹s fine ‹ the sandbox argument makes a
>>> lot of sense, imho ‹ but I¹d prefer to abstract them properly.
>>
>> I like this approach, let's define a minimal set of optimised
>> libraries or
>> needed code (routing, temptlating, utilities Š), call it framework or
>> not,
>> as long as we keep it simple. And specially something that anyone could
>>
>>> I don¹t want to tie Gaia with any framework either, and I think our ³one
>>> lib for one need² approach makes perfect sense. I think we¹ve come to a
>>> point where quite a few apps would benefit from:
>>>
>>> € a shared and minimalistic routing library that helps using Gecko¹s
>>> fast paths and sharing a common navigation UX;
>>>
>>> € a shared and minimalistic templating library allowing to use
>>> readable templates, and playing nice with localization process.
>>>
>>> There are a bunch of such libs on github, I¹ll trust our talented
>>> front-end developers to propose good candidates that we could use and
>>> improve. If we need to rely on <iframe> elements behind the scenes to
>>> achieve a good performance then it¹s fine ‹ the sandbox argument makes a
>>> lot of sense, imho ‹ but I¹d prefer to abstract them properly.
>>
>> I like this approach, let's define a minimal set of optimised
>> libraries or
>> needed code (routing, temptlating, utilities Š), call it framework or
>> not,
>> use outside this project, or something that is outside already and we
>> want
>> to add.
>>
>> want
>> to add.
>>
>> Regarding the comments about checking first performance, I'm sure we are
>> all in the same page about this :)
>>
>> Cheers!
>> F.
>>
>> _______________________________________________
>> all in the same page about this :)
>>
>> Cheers!
>> F.
>>
>> dev-gaia mailing list
>> dev-...@lists.mozilla.org <mailto:dev-...@lists.mozilla.org>
>> https://lists.mozilla.org/listinfo/dev-gaia
>
Vivien
Jun 13, 2013, 1:08:39 PM6/13/13
to Harald Kirschner, Jordano Francisco (UK), Fabien Cazenave, dev-...@lists.mozilla.org, mozilla-...@lists.mozilla.org
tofumatt
Jun 13, 2013, 1:15:36 PM6/13/13
to Vivien, Fabien Cazenave, dev-...@lists.mozilla.org, Jordano Francisco (UK), mozilla-...@lists.mozilla.org
I have heard this mantra from the Gaia team over and over again, essentially: "do as we say, not as we do".
There are other resources out there: reference apps on the Marketplace Developer Hub and buildingfirefoxos.com. Guess what? One of those is straight out of Gaia and everyone at hack days who isn't building games uses it. They want their apps for Firefox OS to look and feel like Firefox OS apps. They want them to behave the same way. They want them to be built the same way.
Like it or not, Gaia is a reference for developers. You can't ignore that, because when you do, someone else comes along and builds something like buildingfirefoxos.com anyway.
The goal of Gaia and Firefox OS is to enhance the web platform? That's great! But any large-scale coding endeavour needs best practices and sane patterns of code re-use. When you build a framework and some kind of coding pattern (MVC, data-binding, some bizarre iframe wizardry, whatever), that doesn't take away from your ability to say: "wow, we really need Bluetooth APIs in JavaScript!"
Like it or not you are a large, open-source, mobile operating system with the world's eyes on you. You can't decide that writing model code "isn't your job". You need to remember you're entering an established space, and we lose the help of a broader open source community (the multitude of developers who hack on JS frameworks and libraries in their spare time) because Gaia eschews front-end standards and best-practices every step of the way. I have met many a front-end developer who has wanted to help with Gaia, but saw the code and went running.
> I can understand that Gaia is what people look at, but it does not seems a goal of the project.
Unless the goal is not to have people look at (and contribute to) Gaia, I think the team needs to get out of the mindset that you're writing open source code that no one but you should ever gaze upon, look to, or submit patches too.
- tofumatt | http://tofumatt.com
On 2013-06-13, at 12:52 PM, Vivien <vnic...@mozilla.com> wrote:
> On 13/06/2013 17:02, Jordano Francisco (UK) wrote:
>> Hi all,
>>
>> I have to agree with Kevin Grandon and Matt Calypotch, usually first
>> approach from external developers to FFOS is take a look to Gaia, and
>> don't think that the iframes approach looks pretty familiar to developers.
>
There are other resources out there: reference apps on the Marketplace Developer Hub and buildingfirefoxos.com. Guess what? One of those is straight out of Gaia and everyone at hack days who isn't building games uses it. They want their apps for Firefox OS to look and feel like Firefox OS apps. They want them to behave the same way. They want them to be built the same way.
Like it or not, Gaia is a reference for developers. You can't ignore that, because when you do, someone else comes along and builds something like buildingfirefoxos.com anyway.
The goal of Gaia and Firefox OS is to enhance the web platform? That's great! But any large-scale coding endeavour needs best practices and sane patterns of code re-use. When you build a framework and some kind of coding pattern (MVC, data-binding, some bizarre iframe wizardry, whatever), that doesn't take away from your ability to say: "wow, we really need Bluetooth APIs in JavaScript!"
Like it or not you are a large, open-source, mobile operating system with the world's eyes on you. You can't decide that writing model code "isn't your job". You need to remember you're entering an established space, and we lose the help of a broader open source community (the multitude of developers who hack on JS frameworks and libraries in their spare time) because Gaia eschews front-end standards and best-practices every step of the way. I have met many a front-end developer who has wanted to help with Gaia, but saw the code and went running.
> I can understand that Gaia is what people look at, but it does not seems a goal of the project.
- tofumatt | http://tofumatt.com
On 2013-06-13, at 12:52 PM, Vivien <vnic...@mozilla.com> wrote:
> On 13/06/2013 17:02, Jordano Francisco (UK) wrote:
>> Hi all,
>>
>> I have to agree with Kevin Grandon and Matt Calypotch, usually first
>> approach from external developers to FFOS is take a look to Gaia, and
>> don't think that the iframes approach looks pretty familiar to developers.
>
> I can understand that Gaia is what people look at, but it does not seems a goal of the project. It seems to me it happens because of the lack of external resources. Having somewhere a generator of manifests, simple and easy to use templates, couple with clear mdn resources about how to use such or such APIs should be all they need. I understand that it takes time to do that as well.
>
> If they are curious, or if the doc is not enough, they can look at Gaia and I don't really see how an iframe/URLs based architecture change anything to them versus looking at a regular webpage. There will still be different approach in many apps to solve different problems but the resources (scripts, css, assets, locales) will be scoped by url and that's it.
>
> So IMO other teams needs to create resources and evangelize around external resources ( I was hoping that https://developer.mozilla.org/en-US/docs/Web/Apps/Getting_Started would have been a good resource for them).
>
>
> If they are curious, or if the doc is not enough, they can look at Gaia and I don't really see how an iframe/URLs based architecture change anything to them versus looking at a regular webpage. There will still be different approach in many apps to solve different problems but the resources (scripts, css, assets, locales) will be scoped by url and that's it.
>
> So IMO other teams needs to create resources and evangelize around external resources ( I was hoping that https://developer.mozilla.org/en-US/docs/Web/Apps/Getting_Started would have been a good resource for them).
>
>> At the end of the day we want to be as web friendly as possible, and I
>> don't see right now web developers using that in their web apps for
>> desktop, webviews, webkit using backbone, angular, twitter flight or any
>> other fancy thing.
>> don't see right now web developers using that in their web apps for
>> desktop, webviews, webkit using backbone, angular, twitter flight or any
>> other fancy thing.
> I agree with web friendly. Web developers will be able to do what they want. If they don't want to use Gaia pattern, this is probably because they have a different set of issues to resolve - I encourage them to do so.
>
> Gaia is not and has never been a tool to promote a special way of writing an application. At a pure Gaia level I want to make sure Gaia applications are performant, memory aware, with clear distinction between panels so responsibilities can be easily established. That sounds insane to architect a software to make it looks sexier for third party because there is a lack of external resources.
>
>>
>
> Gaia is not and has never been a tool to promote a special way of writing an application. At a pure Gaia level I want to make sure Gaia applications are performant, memory aware, with clear distinction between panels so responsibilities can be easily established. That sounds insane to architect a software to make it looks sexier for third party because there is a lack of external resources.
>
>>
>> On 13/06/2013 10:28, "Fabien Cazenave" <fab...@cazenave.cc> wrote:
>>
>>> I don¹t want to tie Gaia with any framework either, and I think our ³one
>>> lib for one need² approach makes perfect sense. I think we¹ve come to a
>>> point where quite a few apps would benefit from:
>>>
>>> € a shared and minimalistic routing library that helps using Gecko¹s
>>> fast paths and sharing a common navigation UX;
>>>
>>> € a shared and minimalistic templating library allowing to use
>>> readable templates, and playing nice with localization process.
>>>
>>> There are a bunch of such libs on github, I¹ll trust our talented
>>> front-end developers to propose good candidates that we could use and
>>> improve. If we need to rely on <iframe> elements behind the scenes to
>>> achieve a good performance then it¹s fine ‹ the sandbox argument makes a
>>> lot of sense, imho ‹ but I¹d prefer to abstract them properly.
>> I like this approach, let's define a minimal set of optimised libraries or
>> needed code (routing, temptlating, utilities Š), call it framework or not,
>> as long as we keep it simple.
>
>>
>>> I don¹t want to tie Gaia with any framework either, and I think our ³one
>>> lib for one need² approach makes perfect sense. I think we¹ve come to a
>>> point where quite a few apps would benefit from:
>>>
>>> € a shared and minimalistic routing library that helps using Gecko¹s
>>> fast paths and sharing a common navigation UX;
>>>
>>> € a shared and minimalistic templating library allowing to use
>>> readable templates, and playing nice with localization process.
>>>
>>> There are a bunch of such libs on github, I¹ll trust our talented
>>> front-end developers to propose good candidates that we could use and
>>> improve. If we need to rely on <iframe> elements behind the scenes to
>>> achieve a good performance then it¹s fine ‹ the sandbox argument makes a
>>> lot of sense, imho ‹ but I¹d prefer to abstract them properly.
>> I like this approach, let's define a minimal set of optimised libraries or
>> needed code (routing, temptlating, utilities Š), call it framework or not,
>> as long as we keep it simple.
>
> I felt like the shared/ folder was for dedicated libraries? Template is trickier because it enforce a way to write your html/js and force a js pass before rendering anything when it could have been directly outputted on the screen. This is an interesting side discussion but this proposal won't prevent you to use the same template mechanism that is already present in the contacts app. The discussion about the initial problem and the proposal issues would be really hard if we diverged on this too much and the goldwin point will be reach soon...
>> And specially something that anyone could
>> use outside this project, or something that is outside already and we want
>> to add.
>
>> use outside this project, or something that is outside already and we want
>> to add.
>
> That sounds an orthogonal problem. James has already proposed to exposed some of the shared/ libs to the rest of the world. We would accept patches but I do not believe that there are the resources to promess anything else except that (like multi-browser supports, new features and so on).
>
> Again I feel like people tends to think the <iframe>s mechanism would change anything in the libs they can / can not use inside the context of their page. It won't. Sure it will change a few architectural things for the internal code of each panel but it won't prevent you to use /name of your preferred lib-utilities-framework/ here.
>>
>
> Again I feel like people tends to think the <iframe>s mechanism would change anything in the libs they can / can not use inside the context of their page. It won't. Sure it will change a few architectural things for the internal code of each panel but it won't prevent you to use /name of your preferred lib-utilities-framework/ here.
>>
>> Regarding the comments about checking first performance, I'm sure we are
>> all in the same page about this :)
>>
>> Cheers!
>> F.
>>
>
>
>> all in the same page about this :)
>>
>> Cheers!
>> F.
>>
>
>
> As a summary if you want to promote some Gaia libs to the external world you are free to do so. James will likely be interested and some others as well. But let's not limit Gaia changes because of how sexier/usual it will be for third party authors if they end looking at it for a whole set of reasons.
> _______________________________________________
> dev-gaia mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-gaia
> dev-gaia mailing list
> dev-...@lists.mozilla.org
tofumatt
Jun 13, 2013, 1:15:36 PM6/13/13
to Vivien, Fabien Cazenave, dev-...@lists.mozilla.org, Jordano Francisco (UK), mozilla-...@lists.mozilla.org
Fabrice Desre
Jun 13, 2013, 2:32:15 PM6/13/13
to tofumatt, Vivien, Fabien Cazenave, dev-...@lists.mozilla.org, Jordano Francisco (UK), mozilla-...@lists.mozilla.org
>
> Unless the goal is not to have people look at (and contribute to) Gaia, I think the team needs to get out of the mindset that you're writing open source code that no one but you should ever gaze upon, look to, or submit patches too.
Wow. That's a so unfair and inaccurate description of Gaia's objectives
> Unless the goal is not to have people look at (and contribute to) Gaia, I think the team needs to get out of the mindset that you're writing open source code that no one but you should ever gaze upon, look to, or submit patches too.
and people's motivations that I don't know where to start.
Fabrice
--
Fabrice Desré
b2g team
Mozilla Corporation
Fabrice Desre
Jun 13, 2013, 2:32:15 PM6/13/13
to tofumatt, Vivien, Fabien Cazenave, dev-...@lists.mozilla.org, Jordano Francisco (UK), mozilla-...@lists.mozilla.org
David Bolter
Jun 13, 2013, 2:56:56 PM6/13/13
to Vivien, dev-...@lists.mozilla.org, Eitan Isaacson
Hi Vivien,
[cc+ing Eitan for good measure]
I'll answer inline:
On 2013-06-13 11:05 AM, Vivien wrote:
> On 13/06/2013 16:41, David Bolter wrote:
>> Using a common js UI library/framework happens to make solving
>> accessibility (via WAI-ARIA for example) tractable. We can put the
>> attributes in once and then users of the library have accidental
>> accessibility, which needless to say is an important part of Mozilla's
>> mission.
> Thanks for putting accessibility on the table. The model does not impose
> any restrictions on what you can use inside an <iframe>. If third-party
> developers have a UI library to use that sounds good.
OK thanks, it seems in reading the discussion I misunderstood the
intended thread scope here.
> It is a different thread and I don't want to pollute this one but I was
> curious about how it is supposed to work on b2g right now. Can we
> continue the discussion in
> https://bugzilla.mozilla.org/show_bug.cgi?id=875040 ?
Definitely but I'll defer to Eitan about where to have the discussion,
there are probably better bugs and he has patches brewing...
Cheers,
David
[cc+ing Eitan for good measure]
I'll answer inline:
On 2013-06-13 11:05 AM, Vivien wrote:
> On 13/06/2013 16:41, David Bolter wrote:
>> Using a common js UI library/framework happens to make solving
>> accessibility (via WAI-ARIA for example) tractable. We can put the
>> attributes in once and then users of the library have accidental
>> accessibility, which needless to say is an important part of Mozilla's
>> mission.
> Thanks for putting accessibility on the table. The model does not impose
> any restrictions on what you can use inside an <iframe>. If third-party
> developers have a UI library to use that sounds good.
intended thread scope here.
> It is a different thread and I don't want to pollute this one but I was
> curious about how it is supposed to work on b2g right now. Can we
> continue the discussion in
> https://bugzilla.mozilla.org/show_bug.cgi?id=875040 ?
there are probably better bugs and he has patches brewing...
Cheers,
David
James Burke
Jun 13, 2013, 3:37:56 PM6/13/13
to Vivien, dev-...@lists.mozilla.org
On Thu, Jun 13, 2013 at 2:30 AM, Vivien <vnic...@mozilla.com> wrote:
> I wrote more or less that later in my inline comments but I want to promote
> it here: Modules and <iframe>s are not two different approaches to resolve
> the same issue, there are different set of issues and possibly some overlaps
> but <iframe>s will never solve modularity of the JS code, it is a way to
> scope functionalities and responsibilities at a macro level.
Modules and iframes can be viewed separately, but I believe you are
primarily using iframes to get encapsulation. The added thing is that
perhaps iframes help then purge that encapsulation as a coarser unit,
but there are other mitigations for that concern. With the following:
* modules.
* a card controller that handle events via delegation (listen on body
for events and use HTML attribute data to route event to card module).
* card modules that just insert HTML and do not bind events.
It leads to:
* no duplicate styles or scripts loaded.
* Card modules loaded as they are approached.
* Memory purging by removing the card doms, and keeping card
controllers as stateless as needed, can have lifecycle events (like in
Web Components when notification of DOM removal can trigger purging a
model for example). Card modules are not attaching events either, but
wait to be called by the controller.
So, I believe that will give similar results for the end goals: fast
startup, pay as you go memory usage, good-enough code isolation and
cleanup, and I expect it to perform better than using iframes.
With iframes:
* higher memory cost for each card: a new browser context for each
card, and loading of duplicate JS/CSS.
* more memory thrashing due to more setup and teardown.
* more difficult to share common code logic. If just plain HTML script
tags emitting globals, it still seems like there is a possibility of a
bad change affecting more than the specific card.
I believe the main motivation for suggesting the iframe approach is:
the gaia system already does it for individual apps, and that has to
perform well.
The difference: inside an app, the app has much more shared resources
and logic that needs to coordinate across cards. There is also a
different security surface: inter-app communication should rightly be
very controlled and sandboxed, where intra-app communication has
implicit trust and benefits from lower security barriers.
As an app developer, I find the thought of duplicating all my scripts
and styles across multiple HTML pages for each frame as very much not
DRY and will lead to a different set of errors than the other errors
it tries to prevent. It will be more work for a developer to do, feels
like worse developer ergonomics.
If you want to be sure that things like iframe setup and teardown is
cheap and does well with memory, the existing gaia app management
already has an implementation that can be profiled and improved
without the distraction of trying a new app construction paradigm.
The iframe approach goes against most of what is standard practice
today for web apps and where the future of building apps is developing
towards (custom, encapsulated web components, modules, support for
better memory devices like WeakMaps). iframes are really best at
coordinating disparate pages/apps or content that needs extra security
boundaries than interior app construction.
But coding should be fun, and if this is something you want to
explore, go for it, and as you and others have said, measure along the
way. Hopefully this feedback could point to an alternative you could
try too in the interest of having multiple hypotheses to test.
James
> I wrote more or less that later in my inline comments but I want to promote
> it here: Modules and <iframe>s are not two different approaches to resolve
> the same issue, there are different set of issues and possibly some overlaps
> but <iframe>s will never solve modularity of the JS code, it is a way to
> scope functionalities and responsibilities at a macro level.
Modules and iframes can be viewed separately, but I believe you are
primarily using iframes to get encapsulation. The added thing is that
perhaps iframes help then purge that encapsulation as a coarser unit,
but there are other mitigations for that concern. With the following:
* modules.
* a card controller that handle events via delegation (listen on body
for events and use HTML attribute data to route event to card module).
* card modules that just insert HTML and do not bind events.
It leads to:
* no duplicate styles or scripts loaded.
* Card modules loaded as they are approached.
* Memory purging by removing the card doms, and keeping card
controllers as stateless as needed, can have lifecycle events (like in
Web Components when notification of DOM removal can trigger purging a
model for example). Card modules are not attaching events either, but
wait to be called by the controller.
So, I believe that will give similar results for the end goals: fast
startup, pay as you go memory usage, good-enough code isolation and
cleanup, and I expect it to perform better than using iframes.
With iframes:
* higher memory cost for each card: a new browser context for each
card, and loading of duplicate JS/CSS.
* more memory thrashing due to more setup and teardown.
* more difficult to share common code logic. If just plain HTML script
tags emitting globals, it still seems like there is a possibility of a
bad change affecting more than the specific card.
I believe the main motivation for suggesting the iframe approach is:
the gaia system already does it for individual apps, and that has to
perform well.
The difference: inside an app, the app has much more shared resources
and logic that needs to coordinate across cards. There is also a
different security surface: inter-app communication should rightly be
very controlled and sandboxed, where intra-app communication has
implicit trust and benefits from lower security barriers.
As an app developer, I find the thought of duplicating all my scripts
and styles across multiple HTML pages for each frame as very much not
DRY and will lead to a different set of errors than the other errors
it tries to prevent. It will be more work for a developer to do, feels
like worse developer ergonomics.
If you want to be sure that things like iframe setup and teardown is
cheap and does well with memory, the existing gaia app management
already has an implementation that can be profiled and improved
without the distraction of trying a new app construction paradigm.
The iframe approach goes against most of what is standard practice
today for web apps and where the future of building apps is developing
towards (custom, encapsulated web components, modules, support for
better memory devices like WeakMaps). iframes are really best at
coordinating disparate pages/apps or content that needs extra security
boundaries than interior app construction.
But coding should be fun, and if this is something you want to
explore, go for it, and as you and others have said, measure along the
way. Hopefully this feedback could point to an alternative you could
try too in the interest of having multiple hypotheses to test.
James
Fred Wenzel
Jun 13, 2013, 5:53:00 PM6/13/13
to Fabrice Desre, Jordano Francisco (UK), mozilla-...@lists.mozilla.org, Vivien, Fabien Cazenave, tofumatt, dev-...@lists.mozilla.org
On Thu Jun 13 11:32:15 2013, Fabrice Desre wrote:
>> Unless the goal is not to have people look at (and contribute to) Gaia, I think the team needs to get out of the mindset that you're writing open source code that no one but you should ever gaze upon, look to, or submit patches too.
>
> Wow. That's a so unfair and inaccurate description of Gaia's objectives
> and people's motivations that I don't know where to start.
Let me quickly jump in here, hopefully without taking the thread even
>> Unless the goal is not to have people look at (and contribute to) Gaia, I think the team needs to get out of the mindset that you're writing open source code that no one but you should ever gaze upon, look to, or submit patches too.
>
> Wow. That's a so unfair and inaccurate description of Gaia's objectives
> and people's motivations that I don't know where to start.
further off topic (the original post was about software architecture,
after all).
Make sure to understand Matt's post in context: Your point about Gaia's
objectives underscores exactly what he was saying. No one assumes or
insinuates the Gaia project doesn't intend to be a stellar open source
citizen and shining example of what the Web platform should be like.
However, every time someone says "I can understand that Gaia is what
people look at, but it does not seems a goal of the project" or
dismisses even the possibility of choosing a software architecture that
could serve as a good example of what a complex app should look like,
it speaks otherwise.
The resources (templates, docs, web components, reference apps, etc,
etc, etc) to educate developers about good app development (simple or
complex alike) are under heavy development:
https://marketplace.firefox.com/developers/ (not sure why Vivien
deep-linked into some wiki page instead). But beyond that, it would be
helpful if our answer to "let me look at what Gaia does" could be
"sure, that's *one* way of making apps, have a look" and not "please,
for the love of all that is holy, don't".
All Matt is asking is that the Gaia project even consider the first
answer, and not firmly insist on the latter.
Cheers,
Fred
Fred Wenzel
Jun 13, 2013, 5:53:00 PM6/13/13
to Fabrice Desre, Jordano Francisco (UK), mozilla-...@lists.mozilla.org, Vivien, Fabien Cazenave, tofumatt, dev-...@lists.mozilla.org
Fabrice Desre
Jun 13, 2013, 6:13:38 PM6/13/13
to Fred Wenzel, Jordano Francisco (UK), mozilla-...@lists.mozilla.org, Vivien, Fabien Cazenave, tofumatt, dev-...@lists.mozilla.org
On 06/13/2013 02:53 PM, Fred Wenzel wrote:
> Let me quickly jump in here, hopefully without taking the thread even
> further off topic (the original post was about software architecture,
> after all).
>
> Make sure to understand Matt's post in context: Your point about Gaia's
> objectives underscores exactly what he was saying. No one assumes or
> insinuates the Gaia project doesn't intend to be a stellar open source
> citizen and shining example of what the Web platform should be like.
I'm sorry but Matt just insinuated that. You can argue as much as you
> Let me quickly jump in here, hopefully without taking the thread even
> further off topic (the original post was about software architecture,
> after all).
>
> Make sure to understand Matt's post in context: Your point about Gaia's
> objectives underscores exactly what he was saying. No one assumes or
> insinuates the Gaia project doesn't intend to be a stellar open source
> citizen and shining example of what the Web platform should be like.
want, this was pretty aggressive. And he talked about *people*, not just
objectives - assume good will by default please.
> However, every time someone says "I can understand that Gaia is what
> people look at, but it does not seems a goal of the project" or
> dismisses even the possibility of choosing a software architecture that
> could serve as a good example of what a complex app should look like, it
> speaks otherwise.
argue that, please provide references. And yes, gaia apps should be good
examples, but as a goal, it's trumped by the necessity to ship.
> The resources (templates, docs, web components, reference apps, etc,
> etc, etc) to educate developers about good app development (simple or
> complex alike) are under heavy development:
> https://marketplace.firefox.com/developers/ (not sure why Vivien
> deep-linked into some wiki page instead). But beyond that, it would be
> helpful if our answer to "let me look at what Gaia does" could be "sure,
> that's *one* way of making apps, have a look" and not "please, for the
> love of all that is holy, don't".
>
> All Matt is asking is that the Gaia project even consider the first
> answer, and not firmly insist on the latter.
second answer wrong? That just look honest to me: "we did it that way
for x/y/z reasons, we have no time to make it better now but don't do
that if you can".
Fabrice Desre
Jun 13, 2013, 6:13:38 PM6/13/13
to Fred Wenzel, Jordano Francisco (UK), mozilla-...@lists.mozilla.org, Vivien, Fabien Cazenave, tofumatt, dev-...@lists.mozilla.org
Fred Wenzel
Jun 13, 2013, 7:07:45 PM6/13/13
to Fabrice Desre, Jordano Francisco (UK), mozilla-...@lists.mozilla.org, Vivien, Fabien Cazenave, tofumatt, dev-...@lists.mozilla.org
On 6/13/13 3:13 PM, Fabrice Desre wrote:
> On 06/13/2013 02:53 PM, Fred Wenzel wrote:
>> Let me quickly jump in here, hopefully without taking the thread even
>> further off topic (the original post was about software architecture,
>> after all).
>>
>> Make sure to understand Matt's post in context: Your point about Gaia's
>> objectives underscores exactly what he was saying. No one assumes or
>> insinuates the Gaia project doesn't intend to be a stellar open source
>> citizen and shining example of what the Web platform should be like.
>
> I'm sorry but Matt just insinuated that. You can argue as much as you
> want, this was pretty aggressive. And he talked about *people*, not just
> objectives - assume good will by default please.
Yup, good reminder that we're all on the same team here, thank you.
> On 06/13/2013 02:53 PM, Fred Wenzel wrote:
>> Let me quickly jump in here, hopefully without taking the thread even
>> further off topic (the original post was about software architecture,
>> after all).
>>
>> Make sure to understand Matt's post in context: Your point about Gaia's
>> objectives underscores exactly what he was saying. No one assumes or
>> insinuates the Gaia project doesn't intend to be a stellar open source
>> citizen and shining example of what the Web platform should be like.
>
> I'm sorry but Matt just insinuated that. You can argue as much as you
> want, this was pretty aggressive. And he talked about *people*, not just
> objectives - assume good will by default please.
>> However, every time someone says "I can understand that Gaia is what
>> people look at, but it does not seems a goal of the project" or
>> dismisses even the possibility of choosing a software architecture that
>> could serve as a good example of what a complex app should look like, it
>> speaks otherwise.
>
> No one dismisses architecture changes without reason. If you want to
> argue that, please provide references. And yes, gaia apps should be good
> examples, but as a goal, it's trumped by the necessity to ship.
>> The resources (templates, docs, web components, reference apps, etc,
>> etc, etc) to educate developers about good app development (simple or
>> complex alike) are under heavy development:
>> https://marketplace.firefox.com/developers/ (not sure why Vivien
>> deep-linked into some wiki page instead). But beyond that, it would be
>> helpful if our answer to "let me look at what Gaia does" could be "sure,
>> that's *one* way of making apps, have a look" and not "please, for the
>> love of all that is holy, don't".
>>
>> All Matt is asking is that the Gaia project even consider the first
>> answer, and not firmly insist on the latter.
>
> When we know that gaia's not doing what is "the right thing", why is the
> second answer wrong? That just look honest to me: "we did it that way
> for x/y/z reasons, we have no time to make it better now but don't do
> that if you can".
improvable architectural decision once for the sake of shipping and ask
people not to reproduce it, that's fine. But let's try and not do the
same thing twice.
Fred
Fred Wenzel
Jun 13, 2013, 7:07:45 PM6/13/13
to Fabrice Desre, Jordano Francisco (UK), mozilla-...@lists.mozilla.org, Vivien, Fabien Cazenave, tofumatt, dev-...@lists.mozilla.org
Jordano Francisco (UK)
Jun 13, 2013, 8:10:36 PM6/13/13
to Vivien, Fabien Cazenave, mozilla-...@lists.mozilla.org, dev-...@lists.mozilla.org
Hi folks
On 13/06/2013 17:52, "Vivien" <vnic...@mozilla.com> wrote:
>
>I can understand that Gaia is what people look at, but it does not seems
examples, and the community is doing an incredible work bringing more and
more material to support developers, my point is that gaia continues being
the big mirror where every developer looks at. So, IMHO, despite of not
being the main goal we should be aware of that.
>
>> At the end of the day we want to be as web friendly as possible, and I
>> don't see right now web developers using that in their web apps for
>> desktop, webviews, webkit using backbone, angular, twitter flight or any
>> other fancy thing.
>I agree with web friendly. Web developers will be able to do what they
>want. If they don't want to use Gaia pattern, this is probably because
>they have a different set of issues to resolve - I encourage them to do
>so.
>
>Gaia is not and has never been a tool to promote a special way of
>writing an application. At a pure Gaia level I want to make sure Gaia
>applications are performant, memory aware, with clear distinction
>between panels so responsibilities can be easily established. That
>sounds insane to architect a software to make it looks sexier for third
>party because there is a lack of external resources.
Again, agree with you, I'm not claiming for a sexy, fancy, modern way of
working, just cause of the showing our amazing codebase to devs, we did an
incredible job with things like visibility_monitor, async_storage,etc. My
point is having a couple of extra and well defined helpful libs, like
navigation or templating that works among all apps Š that, will make me
really happy.
Thanks again!
F.
On 13/06/2013 17:52, "Vivien" <vnic...@mozilla.com> wrote:
>
>I can understand that Gaia is what people look at, but it does not seems
>a goal of the project. It seems to me it happens because of the lack of
>external resources. Having somewhere a generator of manifests, simple
>and easy to use templates, couple with clear mdn resources about how to
>use such or such APIs should be all they need. I understand that it
>takes time to do that as well.
>
>If they are curious, or if the doc is not enough, they can look at Gaia
>and I don't really see how an iframe/URLs based architecture change
>anything to them versus looking at a regular webpage. There will still
>be different approach in many apps to solve different problems but the
>resources (scripts, css, assets, locales) will be scoped by url and
>that's it.
>
>So IMO other teams needs to create resources and evangelize around
>external resources ( I was hoping that
>https://developer.mozilla.org/en-US/docs/Web/Apps/Getting_Started would
>have been a good resource for them).
Totally agree, I'm with you in terms that there are better sources and
>external resources. Having somewhere a generator of manifests, simple
>and easy to use templates, couple with clear mdn resources about how to
>use such or such APIs should be all they need. I understand that it
>takes time to do that as well.
>
>If they are curious, or if the doc is not enough, they can look at Gaia
>and I don't really see how an iframe/URLs based architecture change
>anything to them versus looking at a regular webpage. There will still
>be different approach in many apps to solve different problems but the
>resources (scripts, css, assets, locales) will be scoped by url and
>that's it.
>
>So IMO other teams needs to create resources and evangelize around
>external resources ( I was hoping that
>https://developer.mozilla.org/en-US/docs/Web/Apps/Getting_Started would
>have been a good resource for them).
examples, and the community is doing an incredible work bringing more and
more material to support developers, my point is that gaia continues being
the big mirror where every developer looks at. So, IMHO, despite of not
being the main goal we should be aware of that.
>
>> At the end of the day we want to be as web friendly as possible, and I
>> don't see right now web developers using that in their web apps for
>> desktop, webviews, webkit using backbone, angular, twitter flight or any
>> other fancy thing.
>I agree with web friendly. Web developers will be able to do what they
>want. If they don't want to use Gaia pattern, this is probably because
>they have a different set of issues to resolve - I encourage them to do
>so.
>
>Gaia is not and has never been a tool to promote a special way of
>writing an application. At a pure Gaia level I want to make sure Gaia
>applications are performant, memory aware, with clear distinction
>between panels so responsibilities can be easily established. That
>sounds insane to architect a software to make it looks sexier for third
>party because there is a lack of external resources.
working, just cause of the showing our amazing codebase to devs, we did an
incredible job with things like visibility_monitor, async_storage,etc. My
point is having a couple of extra and well defined helpful libs, like
navigation or templating that works among all apps Š that, will make me
really happy.
Thanks again!
F.
Jordano Francisco (UK)
Jun 13, 2013, 8:10:36 PM6/13/13
to Vivien, Fabien Cazenave, mozilla-...@lists.mozilla.org, dev-...@lists.mozilla.org
Travis Choma
Jun 13, 2013, 8:14:12 PM6/13/13
to Jordano Francisco (UK), Vivien, Fabien Cazenave, dev-...@lists.mozilla.org, mozilla-...@lists.mozilla.org
The discussion on this thread has been great, it really gets at the heart of some of the challenges of developing performant and maintainable HTML5 apps on mobile.
>From my perspective I think 3rd party developers largely have the same concerns as Gaia developers. They want their apps to run well and make it a joy for users to use the apps they ship.
It's awesome to leverage existing frameworks but having a turn-key framework that gives you great performance on mobile is not a fully solved problem, and some apps will bump up against this more than others. Even the biggest players have struggled with it.
What Vivien proposed regarding iframe's is not without precedent on mobile HTML5 either. For different reasons Sencha realized they needed to do this for large complex views for performance reasons as well. http://www.sencha.com/blog/the-making-of-fastbook-an-html5-love-story
I think :Stas was the first to bring it up, but it'd be awesome to dig in and do a little prototyping and benchmarking on b2g to measure rendering views in isolated frames, vs swapping out views in the DOM as backbone does to better understand the implications.
And Harald raised a great point, what ever the learning is, we don't need to think of it as a hack, but something to feed back in to the community and the existing frameworks like Backbone and others, so that app development still feels webby and some of these things can be abstracted away so developers can be productive and concentrate on their app logic.
Cheers,
-Travis
>From my perspective I think 3rd party developers largely have the same concerns as Gaia developers. They want their apps to run well and make it a joy for users to use the apps they ship.
It's awesome to leverage existing frameworks but having a turn-key framework that gives you great performance on mobile is not a fully solved problem, and some apps will bump up against this more than others. Even the biggest players have struggled with it.
What Vivien proposed regarding iframe's is not without precedent on mobile HTML5 either. For different reasons Sencha realized they needed to do this for large complex views for performance reasons as well. http://www.sencha.com/blog/the-making-of-fastbook-an-html5-love-story
I think :Stas was the first to bring it up, but it'd be awesome to dig in and do a little prototyping and benchmarking on b2g to measure rendering views in isolated frames, vs swapping out views in the DOM as backbone does to better understand the implications.
And Harald raised a great point, what ever the learning is, we don't need to think of it as a hack, but something to feed back in to the community and the existing frameworks like Backbone and others, so that app development still feels webby and some of these things can be abstracted away so developers can be productive and concentrate on their app logic.
Cheers,
-Travis
Travis Choma
Jun 13, 2013, 8:14:12 PM6/13/13
to Jordano Francisco (UK), Vivien, Fabien Cazenave, dev-...@lists.mozilla.org, mozilla-...@lists.mozilla.org
Salvador de la Puente González
Jun 14, 2013, 3:33:01 AM6/14/13
to Vivien, dev-...@lists.mozilla.org, Staś Małolepszy
Hello folks.
I'm a little bit confused about this an other comments:
On 13/06/13 14:31, Vivien wrote:
>
>> * * *
>>
>> As far as my own opinion goes, I'll echo Kevin's words: do we really
>> want developers to code this way? Is this what the future of HTML
>> looks like according to Mozilla?
> I have no ideas about the future of HTML. It seems to me that there
> are a lot of confusion here.
This <iframe> proposal with the controller and so on is only an optional
pattern for a FirefoxOS developer, does not it? I mean, it is not part
of system application, nor part of the window manager... if you want to
follow's Vivien proposal, go for it. If you have a better approach, it
is good as well. It's up to you.
Or maybe I'm getting confused?
I'm a little bit confused about this an other comments:
On 13/06/13 14:31, Vivien wrote:
>
>> * * *
>>
>> As far as my own opinion goes, I'll echo Kevin's words: do we really
>> want developers to code this way? Is this what the future of HTML
>> looks like according to Mozilla?
> I have no ideas about the future of HTML. It seems to me that there
> are a lot of confusion here.
This <iframe> proposal with the controller and so on is only an optional
pattern for a FirefoxOS developer, does not it? I mean, it is not part
of system application, nor part of the window manager... if you want to
follow's Vivien proposal, go for it. If you have a better approach, it
is good as well. It's up to you.
Or maybe I'm getting confused?
Gareth Aye
Jun 14, 2013, 12:02:34 PM6/14/13
to
So I managed to read through this whole thread last night! Go me!
As someone who has worked in calendar and elsewhere in Gaia (and has also spent more time developing outside of MoCo than inside : ), I think that we should be striving to write our apps in a way that welcomes web developers. When we go against the grain of the larger web community, we make Gaia and Firefox OS less accessible to people outside of Mozilla.
James Lal has done an excellent job of incorporating third-party projects in calendar (better than the rest of Gaia at least), but my first reactions to calendar were
- Why don't we use something like goog.ui.Component or backbone to manage our views?
- Why don't we use a templating lib?
- Why do we use our own homebrewed dependency management thing?
When we go off and write our apps without any of the abstractions that the web community has built and supported, we're only open in the sense that you can (try to) read the source. One of the big selling points behind our platform for developers is that they don't have to learn another set of APIs in order to build something. Well, as things are, web developers actually do have to express themselves differently in order to build things that work for Firefox OS. That should worry us.
Also, when you convince yourself that abstractions are bad you end up with monolithic poop that nobody wants to touch. The problem isn't only that the web community won't feel welcomed. We have *massive* technical debt that follows from bad philosophy. It even slows down and alienates people inside of MoCo!
I've brought up a lot of points, but the biggest one is that we're creating our own language for how to write web apps and it isn't the same as the web community's. If we need to, let's improve the platform so that we can actually write web apps. Let's not fool ourselves into thinking that all ways that you can express yourself with open protocols are "open".
Quick sidenote:
We should keep ourselves from breaking our apps by *testing*. Not by sandboxing ourselves.
As someone who has worked in calendar and elsewhere in Gaia (and has also spent more time developing outside of MoCo than inside : ), I think that we should be striving to write our apps in a way that welcomes web developers. When we go against the grain of the larger web community, we make Gaia and Firefox OS less accessible to people outside of Mozilla.
James Lal has done an excellent job of incorporating third-party projects in calendar (better than the rest of Gaia at least), but my first reactions to calendar were
- Why don't we use something like goog.ui.Component or backbone to manage our views?
- Why don't we use a templating lib?
- Why do we use our own homebrewed dependency management thing?
When we go off and write our apps without any of the abstractions that the web community has built and supported, we're only open in the sense that you can (try to) read the source. One of the big selling points behind our platform for developers is that they don't have to learn another set of APIs in order to build something. Well, as things are, web developers actually do have to express themselves differently in order to build things that work for Firefox OS. That should worry us.
Also, when you convince yourself that abstractions are bad you end up with monolithic poop that nobody wants to touch. The problem isn't only that the web community won't feel welcomed. We have *massive* technical debt that follows from bad philosophy. It even slows down and alienates people inside of MoCo!
I've brought up a lot of points, but the biggest one is that we're creating our own language for how to write web apps and it isn't the same as the web community's. If we need to, let's improve the platform so that we can actually write web apps. Let's not fool ourselves into thinking that all ways that you can express yourself with open protocols are "open".
Quick sidenote:
We should keep ourselves from breaking our apps by *testing*. Not by sandboxing ourselves.
Luigi Tedone
Jun 16, 2013, 6:29:36 AM6/16/13
to mozilla-...@lists.mozilla.org
I really agree with you +1
Jan Jongboom
Jun 17, 2013, 5:50:57 AM6/17/13
to
In the past months I have done a lot of events, from hard core training, to app days, to conferences, etc. And buildingfirefoxos.com is by far the most useful resource that I can give to people. Writing proper interactions and user experiences for mobile is a very hard subject and having reference implementations by the vendor of an operating system that leverages these technologies on a day to day basis is extremely valuable. Whether we like it or not, the building blocks are clean, quick and don't carry a big javascript library with them; and thus it's very easy and convenient to use them in prototyping scenario's or app days.
In a way it saddens me that the same thing doesn't really (really doesn't?) apply to the javascript code in Gaia. The code at the moment is generally very procedural and has high coupling with the DOM. I'm pretty sure that when we'd have more a more building-blocks-like approach (e.g. re-usable components) we could implement a lot of performance improvements more easily. Think of the way lists are currently implemented within Gaia. Every application does it's own thing regarding caching, scrolling, rebuilding stuff on the fly. This means that; a) teams will spend time abstracting away certain issues that will be duplicated in the code base. And b) when a 3rd party wants to do proper lists, he also has to do this. When someone creates something like https://github.com/sergi/virtual-list (by our fellow FFOS contributor Sergi Mansilla); implementing this as a prototype to proof the performance increase is very cumbersome due to the high coupling and non-modularity in applications. This is holding us back.
I think we can argue that the same thing would apply to route/view/template loading. If we can abstract this away in a standard design pattern; whether it's a library, x-tags or anything, proving that Viviens solution is a better way of doing things with less memory overhead becomes a lot easier. I realise it's also a hard problem to solve. A library like AngularJS whose sole purpose is making this stuff easier and faster has a full dedicated team in Google.
Anyway, people in general like to have a library that makes things easier for them. The building blocks do it for UI, and I think it would be awesome, and also beneficial for ourselves to also have that for parts of our javascript codebase. I think you can also see it in a reference app like my https://github.com/comoyo/ffos-list-detail that makes routing / views / etc. easier by combining Angular and the building blocks and currently holds > 360 stars on Github.
Jan Jongboom
Jun 17, 2013, 5:52:37 AM6/17/13
to
TL;DR: If we make stuff easier for 3rd party developers we also make it easier for ourselves.
Corey Frang
Jun 17, 2013, 10:38:37 AM6/17/13
to
As crazy as it sounds, I like this idea. Stuffing iframes is a fairly perfect memory management model.
I've seen multiple developers use this in mobile app development because once you trash an iframe, you get rid of all its memory very easily.
Implementing page transitions feels like it would be really simple.
I feel like the tough part would be transferring bits of data between frames, though I think we have a few options available to us here. We might even be able to sneak into some tiny shared data in `window.parent` somehow with a sandbox flag.
On Wednesday, June 12, 2013 10:06:06 AM UTC-4, Vivien wrote:
> Hello folks,
>
>
>
> Last year or so many Gaia apps has been built using a framework-less
>
> based approach, using a combination of libraries + css building blocks.
>
> In parallel, during last year a lot of things has been learned about
>
> device constraints, mobile constraints, app constraints,
>
> cross-teams-work constraints.
>
>
>
> -----------------
>
> Based on this here are some of those constraints (some are already
>
> partially solved) I would like to reach primarily:
>
> 1. *Fast loading application*
>
> Andreas said it a few times already. Apps should load in less than 600ms.
>
>
>
> 2. *Low memory consumption*
>
> The memory of the device is limited. A limited number of applications
>
> can run at the same time. Less memory used means more applications can
>
> run at the same time.
>
>
>
> 3. *Stable memory consumption*
>
> It is OK to consume an extra memory while making a particular task of
>
> an application. But this memory needs to be freed once the task has been
>
> finished.
>
>
>
> 4. *Smooth panel transitions*
>
> Transitions should happen really quick after a hit on a button.
>
> Ideally a panel should be fully loaded when the transition is complete,
>
> but it sounds OK if informations such as the list of wifi networks
>
> around, loads delayed.
>
>
>
> 5. *Inline activities friendly*
>
> The whole application should not be required to be loaded for
>
> handling a particular operation.
>
>
>
> 6. *Scoped Panels*
>
> Panels should be independent. So a panel is directly responsible of
>
> its own load time and of any JS breakage it can generate. Also, an
>
> individual panel should not be able to break the application. Different
>
> authors can work on the same application and each of them would be
>
> directly responsible of one or many panels.
>
>
>
> It sounds me that is could be a good set of constraints to solve with a
>
> framewor-less based approach, using a combination of libraries + css
>
> building blocks... and html.
>
>
>
> (There are other issues obviously and some of them are already handled
>
> by brave folks, like Tim and others in Taipei working on multiple
>
> resolutions support for example. Also, I have omit voluntarily the
>
> specific set of issues of the System app, which is similar in some
>
> cases, but has some special cases too IMHO)
>
>
>
> -----------------
>
> The proposal:
>
>
>
> <iframe mozbrowser mozapp="app://myapp.gaiamobile.org/myapp.manifest"
>
> src="app://myapp.gaiamobile.org/index.html">
>
> <!doctype html>
>
> <html>
>
> <head>
>
> <!-- This is a dirty little js lib that handle navigation between
>
> panels with a local postMessage protocol -->
>
> <!-- XXX Please don't focus tptionoo much on it - there are some
>
> plans to get rid of it in a potential near future but this
>
> discussion is way out of the scope of this proposal and I
>
> don't want to mix both discussions -->
>
> <script src="shared/js/navigation.js"></script>
>
> </head>
>
>
>
> <body>
>
> <!-- This panel will be created only once the application has
>
> loaded. Or it could be directly included in the html if the author wants
>
> to delay the mozbrowserloadend event for some reasons -->
>
> <iframe sandbox="allow-scripts allow-forms"
>
> src="main-panel.html"></iframe>
>
>
>
> <!-- This iframe will be created only once the user has made a
>
> choice in the main-panel -->
>
> <iframe sandbox="allow-scripts allow-forms"
>
> src="next-panel.html"></iframe>
>
>
>
> <!-- this iframe will be created only once the user has made a
>
> choice in the next panel -->
>
> <iframe sandbox="allow-scripts allow-forms"
>
> src="next-next-panel.html"></iframe>
>
>
>
> <!-- Back buttons that lives outside of the panels. A user will
>
> always be able to exit a panel even if this one breaks -->
>
> <button id="back">
>
> </body>
>
> </html>
>
> </iframe>
>
>
>
> This is mostly it.
>
>
>
> Basically the <navigation.js> helper creates sandbox-ed <iframe>s on
>
> demand and handle the navigation, as well as the back button.
>
>
>
> As long the user navigates forward, new sandbox-ed <iframe>s are
>
> created. As soon the user hit the back button the last <iframe> is
>
> removed in order to free the relevant part of memory. Since <iframe>s
>
> are sandboxed without the allow-same-origin flag, the only way to
>
> communicate should be postMessage and data would be serialized that
>
> should prevent references to each other and guarantee that the memory
>
> will be freed.
>
>
>
> I feel like this will address 1., 2. and 3. since the memory used will
>
> be directly related to the real user activity and it will be freed once
>
> it is done. Also, an application will be able to detach the previous
>
> state of the application to save some memory if needed. (For example the
>
> settings app would be able to detach the <iframe src="main-panel.html">
>
> if the user has finished the activity but, instead of going back to the
>
> application starts using the back button, he/she hits the home button,
>
> leaving completely the app to do something else.
>
>
>
> 1. Will be addressed because nothing else than the main code would be
>
> loaded on cold launch. If the app is slow it will be trivial to identify
>
> the responsible panel and to fix it.
>
>
>
> 5. Will be addressed since it will be easy to declare in the manifest
>
> which urls correlate with a particular inline activity.
>
> 6. Will be addressed since each panels will not be able to access others
>
> because of the sandbox. Also, the back button being part of the main app
>
> container will ensure the user will always be able to go back and reload
>
> the panel to see if it works finally (poor's man solution to race
>
> condition, bugs that appear only if your follow a specific code path).
>
>
>
> About 4. This model will let us get rid of the <!-- html comment -->
>
> hack used in different applications as well as a big part of
>
> <lazy_loader.js> since only the necessary part of a panel should be
>
> loaded with it. Everything that is not vital and can be delayed like
>
> getting the list of wifi networks can be loaded using <script async>.
>
> As a result Gaia apps will be split in many html files. The directory
>
> organization may reflect it.
>
>
>
> How much is it going to impatc load time of a specific panel? I feel
>
> like it should be fast since this is not the equivalent of opening a new
>
> process (it has already been opened), but just spawning a new
>
> compartment and parse js/css file again (see next paragraph about that).
>
>
>
> -----------------
>
> Possible issues:
>
> a. Global states cannot be shared.
>
> b. Load time for each panels
>
> 1. JavaScript files / libraries needs to be replicated.
>
> 2. CSS files need to be replicated.
>
> 3. Assets needs to be replicated.
>
> c. Memory overhead for each compartments
>
>
>
> I have probably forgot some obvious things, please feel free to add to
>
> the list!
>
>
>
> -----------------
>
> Possible answers:
>
> For *a* and *b1*.
>
> Four things comes to my mind.
>
> - Shared Workers - https://bugzilla.mozilla.org/show_bug.cgi?id=643325
>
> - IndexedDB support in Workers -
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=701634
>
> - Lazy bytecode generation -
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=678037
>
> - JSScript sharing - https://bugzilla.mozilla.org/show_bug.cgi?id=679940
>
>
>
> First I feel like states should not be shared between panels, but data
>
> should be. I can imagine that there are some cases where some kind of
>
> state needs to be shared, but I'm not convinced this is the most common
>
> case. Shared worker and indexedDB support in workers should solve many
>
> issues and help a lot here. Many different panels would be able to
>
> access the worker that will have been loaded once. I cannot tell how
>
> glad I am to have seen a recent path on the SharedWorker implementation.
>
> bent++.
>
>
>
> Lazy bytecode generation will help save some startup time / memory. If a
>
> utility library is replicated, but some part are not used, that will be
>
> less an issue.
>
>
>
> JSScript sharing. As far as I have understood those sharing of JSScript
>
> data is mostly for the self-hosted methods, like Array.map and so on. I
>
> wonder if some JSScript data can be shared for scripts with the same
>
> mozapp context, same origin as long as they come from offline cache /
>
> packaged content.
>
>
>
> For *b2*, *b3*.
>
> Two things come to my mind:
>
> - Seamless iframe - https://bugzilla.mozilla.org/show_bug.cgi?id=631218
>
> - Similarly to JSScript sharing I wonder if some data can be shared as
>
> well for offline cache/packaged same origin css files ? (obviously I
>
> don't know much about layout/ and it this is possible).
>
>
>
> As far as I understand the specification of the 'seamless' attribute,
>
> the sub-iframes will inherit the parent rule. If that means the
>
> style-set rules are shared that would be a good fit to avoid extra load
>
> time and fit our memory constraints.
>
>
>
> For c. I made a little measurement and found an extra JS overhead of
>
> 100k per compartment on my laptop using about:memory. It is not always
>
> easy to read it so I could have made a mistake. Layout data were adding
>
> an overhead of ~180k per iframes. (140k on the 180k seems to be
>
> html.css/forms.css/... recomputed for each iframes. If seamless is what
>
> I think I wonder it this could be solved in the same bucket partially).
>
>
>
>
>
> -----------------
>
> Possible Implementation plan
>
>
>
> Obviously some part of Gecko are not ready, Shared Worker has only
>
> started the review process, IndexedDB is not accessible from worker,
>
> seamless is not implemented, there is no lazy bytecode evaluation yet,
>
> ... But that should not prevent to implement the model for many parts in
>
> many apps.
>
>
>
> In the first time of the implementation the sandbox attribute can be
>
> added only based on a whitelist in <navigation.js> in order to allow a
>
> smooth transition. Then, some apps should be able to load some custom
>
> scripts in the main context of their applications until SharedWorker lands.
>
>
>
> -----------------
>
>
>
> I have more details in my head, but I want to dump this somewhere while
>
> the roadmap for the next version is not final in order to include this
>
> engineering works to the workload for the next coming months if that
>
> makes sense.
>
>
>
> Feel free to comments / criticize / etc.
>
>
>
> Vivien.
I've seen multiple developers use this in mobile app development because once you trash an iframe, you get rid of all its memory very easily.
Implementing page transitions feels like it would be really simple.
I feel like the tough part would be transferring bits of data between frames, though I think we have a few options available to us here. We might even be able to sneak into some tiny shared data in `window.parent` somehow with a sandbox flag.
On Wednesday, June 12, 2013 10:06:06 AM UTC-4, Vivien wrote:
> Hello folks,
>
>
>
> Last year or so many Gaia apps has been built using a framework-less
>
> based approach, using a combination of libraries + css building blocks.
>
> In parallel, during last year a lot of things has been learned about
>
> device constraints, mobile constraints, app constraints,
>
> cross-teams-work constraints.
>
>
>
> -----------------
>
> Based on this here are some of those constraints (some are already
>
> partially solved) I would like to reach primarily:
>
> 1. *Fast loading application*
>
> Andreas said it a few times already. Apps should load in less than 600ms.
>
>
>
> 2. *Low memory consumption*
>
> The memory of the device is limited. A limited number of applications
>
> can run at the same time. Less memory used means more applications can
>
> run at the same time.
>
>
>
> 3. *Stable memory consumption*
>
> It is OK to consume an extra memory while making a particular task of
>
> an application. But this memory needs to be freed once the task has been
>
> finished.
>
>
>
> 4. *Smooth panel transitions*
>
> Transitions should happen really quick after a hit on a button.
>
> Ideally a panel should be fully loaded when the transition is complete,
>
> but it sounds OK if informations such as the list of wifi networks
>
> around, loads delayed.
>
>
>
> 5. *Inline activities friendly*
>
> The whole application should not be required to be loaded for
>
> handling a particular operation.
>
>
>
> 6. *Scoped Panels*
>
> Panels should be independent. So a panel is directly responsible of
>
> its own load time and of any JS breakage it can generate. Also, an
>
> individual panel should not be able to break the application. Different
>
> authors can work on the same application and each of them would be
>
> directly responsible of one or many panels.
>
>
>
> It sounds me that is could be a good set of constraints to solve with a
>
> framewor-less based approach, using a combination of libraries + css
>
> building blocks... and html.
>
>
>
> (There are other issues obviously and some of them are already handled
>
> by brave folks, like Tim and others in Taipei working on multiple
>
> resolutions support for example. Also, I have omit voluntarily the
>
> specific set of issues of the System app, which is similar in some
>
> cases, but has some special cases too IMHO)
>
>
>
> -----------------
>
> The proposal:
>
>
>
> <iframe mozbrowser mozapp="app://myapp.gaiamobile.org/myapp.manifest"
>
> src="app://myapp.gaiamobile.org/index.html">
>
> <!doctype html>
>
> <html>
>
> <head>
>
> <!-- This is a dirty little js lib that handle navigation between
>
> panels with a local postMessage protocol -->
>
> <!-- XXX Please don't focus tptionoo much on it - there are some
>
> plans to get rid of it in a potential near future but this
>
> discussion is way out of the scope of this proposal and I
>
> don't want to mix both discussions -->
>
> <script src="shared/js/navigation.js"></script>
>
> </head>
>
>
>
> <body>
>
> <!-- This panel will be created only once the application has
>
> loaded. Or it could be directly included in the html if the author wants
>
> to delay the mozbrowserloadend event for some reasons -->
>
> <iframe sandbox="allow-scripts allow-forms"
>
> src="main-panel.html"></iframe>
>
>
>
> <!-- This iframe will be created only once the user has made a
>
> choice in the main-panel -->
>
> <iframe sandbox="allow-scripts allow-forms"
>
> src="next-panel.html"></iframe>
>
>
>
> <!-- this iframe will be created only once the user has made a
>
> choice in the next panel -->
>
> <iframe sandbox="allow-scripts allow-forms"
>
> src="next-next-panel.html"></iframe>
>
>
>
> <!-- Back buttons that lives outside of the panels. A user will
>
> always be able to exit a panel even if this one breaks -->
>
> <button id="back">
>
> </body>
>
> </html>
>
> </iframe>
>
>
>
> This is mostly it.
>
>
>
> Basically the <navigation.js> helper creates sandbox-ed <iframe>s on
>
> demand and handle the navigation, as well as the back button.
>
>
>
> As long the user navigates forward, new sandbox-ed <iframe>s are
>
> created. As soon the user hit the back button the last <iframe> is
>
> removed in order to free the relevant part of memory. Since <iframe>s
>
> are sandboxed without the allow-same-origin flag, the only way to
>
> communicate should be postMessage and data would be serialized that
>
> should prevent references to each other and guarantee that the memory
>
> will be freed.
>
>
>
> I feel like this will address 1., 2. and 3. since the memory used will
>
> be directly related to the real user activity and it will be freed once
>
> it is done. Also, an application will be able to detach the previous
>
> state of the application to save some memory if needed. (For example the
>
> settings app would be able to detach the <iframe src="main-panel.html">
>
> if the user has finished the activity but, instead of going back to the
>
> application starts using the back button, he/she hits the home button,
>
> leaving completely the app to do something else.
>
>
>
> 1. Will be addressed because nothing else than the main code would be
>
> loaded on cold launch. If the app is slow it will be trivial to identify
>
> the responsible panel and to fix it.
>
>
>
> 5. Will be addressed since it will be easy to declare in the manifest
>
> which urls correlate with a particular inline activity.
>
> 6. Will be addressed since each panels will not be able to access others
>
> because of the sandbox. Also, the back button being part of the main app
>
> container will ensure the user will always be able to go back and reload
>
> the panel to see if it works finally (poor's man solution to race
>
> condition, bugs that appear only if your follow a specific code path).
>
>
>
> About 4. This model will let us get rid of the <!-- html comment -->
>
> hack used in different applications as well as a big part of
>
> <lazy_loader.js> since only the necessary part of a panel should be
>
> loaded with it. Everything that is not vital and can be delayed like
>
> getting the list of wifi networks can be loaded using <script async>.
>
> As a result Gaia apps will be split in many html files. The directory
>
> organization may reflect it.
>
>
>
> How much is it going to impatc load time of a specific panel? I feel
>
> like it should be fast since this is not the equivalent of opening a new
>
> process (it has already been opened), but just spawning a new
>
> compartment and parse js/css file again (see next paragraph about that).
>
>
>
> -----------------
>
> Possible issues:
>
> a. Global states cannot be shared.
>
> b. Load time for each panels
>
> 1. JavaScript files / libraries needs to be replicated.
>
> 2. CSS files need to be replicated.
>
> 3. Assets needs to be replicated.
>
> c. Memory overhead for each compartments
>
>
>
> I have probably forgot some obvious things, please feel free to add to
>
> the list!
>
>
>
> -----------------
>
> Possible answers:
>
> For *a* and *b1*.
>
> Four things comes to my mind.
>
> - Shared Workers - https://bugzilla.mozilla.org/show_bug.cgi?id=643325
>
> - IndexedDB support in Workers -
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=701634
>
> - Lazy bytecode generation -
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=678037
>
> - JSScript sharing - https://bugzilla.mozilla.org/show_bug.cgi?id=679940
>
>
>
> First I feel like states should not be shared between panels, but data
>
> should be. I can imagine that there are some cases where some kind of
>
> state needs to be shared, but I'm not convinced this is the most common
>
> case. Shared worker and indexedDB support in workers should solve many
>
> issues and help a lot here. Many different panels would be able to
>
> access the worker that will have been loaded once. I cannot tell how
>
> glad I am to have seen a recent path on the SharedWorker implementation.
>
> bent++.
>
>
>
> Lazy bytecode generation will help save some startup time / memory. If a
>
> utility library is replicated, but some part are not used, that will be
>
> less an issue.
>
>
>
> JSScript sharing. As far as I have understood those sharing of JSScript
>
> data is mostly for the self-hosted methods, like Array.map and so on. I
>
> wonder if some JSScript data can be shared for scripts with the same
>
> mozapp context, same origin as long as they come from offline cache /
>
> packaged content.
>
>
>
> For *b2*, *b3*.
>
> Two things come to my mind:
>
> - Seamless iframe - https://bugzilla.mozilla.org/show_bug.cgi?id=631218
>
> - Similarly to JSScript sharing I wonder if some data can be shared as
>
> well for offline cache/packaged same origin css files ? (obviously I
>
> don't know much about layout/ and it this is possible).
>
>
>
> As far as I understand the specification of the 'seamless' attribute,
>
> the sub-iframes will inherit the parent rule. If that means the
>
> style-set rules are shared that would be a good fit to avoid extra load
>
> time and fit our memory constraints.
>
>
>
> For c. I made a little measurement and found an extra JS overhead of
>
> 100k per compartment on my laptop using about:memory. It is not always
>
> easy to read it so I could have made a mistake. Layout data were adding
>
> an overhead of ~180k per iframes. (140k on the 180k seems to be
>
> html.css/forms.css/... recomputed for each iframes. If seamless is what
>
> I think I wonder it this could be solved in the same bucket partially).
>
>
>
>
>
> -----------------
>
> Possible Implementation plan
>
>
>
> Obviously some part of Gecko are not ready, Shared Worker has only
>
> started the review process, IndexedDB is not accessible from worker,
>
> seamless is not implemented, there is no lazy bytecode evaluation yet,
>
> ... But that should not prevent to implement the model for many parts in
>
> many apps.
>
>
>
> In the first time of the implementation the sandbox attribute can be
>
> added only based on a whitelist in <navigation.js> in order to allow a
>
> smooth transition. Then, some apps should be able to load some custom
>
> scripts in the main context of their applications until SharedWorker lands.
>
>
>
> -----------------
>
>
>
> I have more details in my head, but I want to dump this somewhere while
>
> the roadmap for the next version is not final in order to include this
>
> engineering works to the workload for the next coming months if that
>
> makes sense.
>
>
>
> Feel free to comments / criticize / etc.
>
>
>
> Vivien.
Vivien
Jun 17, 2013, 1:14:01 PM6/17/13
to Salvador de la Puente González, dev-...@lists.mozilla.org, Staś Małolepszy
On 14/06/2013 09:33, Salvador de la Puente González wrote:
> Hello folks.
>
> I'm a little bit confused about this an other comments:
>
> On 13/06/13 14:31, Vivien wrote:
>>
>>> * * *
>>>
>>> As far as my own opinion goes, I'll echo Kevin's words: do we really
>>> want developers to code this way? Is this what the future of HTML
>>> looks like according to Mozilla?
>> I have no ideas about the future of HTML. It seems to me that there
>> are a lot of confusion here.
>
> This <iframe> proposal with the controller and so on is only an optional
> pattern for a FirefoxOS developer, does not it? I mean, it is not part
> of system application, nor part of the window manager... if you want to
> follow's Vivien proposal, go for it. If you have a better approach, it
> is good as well. It's up to you.
>
> Or maybe I'm getting confused?
You're not confused. But if Gaia follows this pattern it would be good
> Hello folks.
>
> I'm a little bit confused about this an other comments:
>
> On 13/06/13 14:31, Vivien wrote:
>>
>>> * * *
>>>
>>> As far as my own opinion goes, I'll echo Kevin's words: do we really
>>> want developers to code this way? Is this what the future of HTML
>>> looks like according to Mozilla?
>> I have no ideas about the future of HTML. It seems to me that there
>> are a lot of confusion here.
>
> This <iframe> proposal with the controller and so on is only an optional
> pattern for a FirefoxOS developer, does not it? I mean, it is not part
> of system application, nor part of the window manager... if you want to
> follow's Vivien proposal, go for it. If you have a better approach, it
> is good as well. It's up to you.
>
> Or maybe I'm getting confused?
to have as much developers on board as possible.
Gareth Aye
Jun 17, 2013, 8:02:27 PM6/17/13
to Vivien, dev-...@lists.mozilla.org, Staś Małolepszy, Salvador de la Puente González
I posted this on the google group last week, but someone brought up that
they hadn't received it in email form... sorry if this is a repost for
anyone!
>>
>
> ______________________________**_________________
> dev-gaia mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/**listinfo/dev-gaia<https://lists.mozilla.org/listinfo/dev-gaia>
>
--
Best,
Gareth
they hadn't received it in email form... sorry if this is a repost for
anyone!
On Mon, Jun 17, 2013 at 10:14 AM, Vivien <vnic...@mozilla.com> wrote:
> On 14/06/2013 09:33, Salvador de la Puente González wrote:
>
>> Hello folks.
>>
>> I'm a little bit confused about this an other comments:
>>
>> On 13/06/13 14:31, Vivien wrote:
>>
>>>
>>> * * *
>>>>
>>>> As far as my own opinion goes, I'll echo Kevin's words: do we really
>>>> want developers to code this way? Is this what the future of HTML
>>>> looks like according to Mozilla?
>>>>
>>> I have no ideas about the future of HTML. It seems to me that there
>>> are a lot of confusion here.
>>>
>>
>> This <iframe> proposal with the controller and so on is only an optional
>> pattern for a FirefoxOS developer, does not it? I mean, it is not part
>> of system application, nor part of the window manager... if you want to
>> follow's Vivien proposal, go for it. If you have a better approach, it
>> is good as well. It's up to you.
>>
>> Or maybe I'm getting confused?
>>
> You're not confused. But if Gaia follows this pattern it would be good to
> have as much developers on board as possible.
>
>
>> ______________________________**__
> On 14/06/2013 09:33, Salvador de la Puente González wrote:
>
>> Hello folks.
>>
>> I'm a little bit confused about this an other comments:
>>
>> On 13/06/13 14:31, Vivien wrote:
>>
>>>
>>> * * *
>>>>
>>>> As far as my own opinion goes, I'll echo Kevin's words: do we really
>>>> want developers to code this way? Is this what the future of HTML
>>>> looks like according to Mozilla?
>>>>
>>> I have no ideas about the future of HTML. It seems to me that there
>>> are a lot of confusion here.
>>>
>>
>> This <iframe> proposal with the controller and so on is only an optional
>> pattern for a FirefoxOS developer, does not it? I mean, it is not part
>> of system application, nor part of the window manager... if you want to
>> follow's Vivien proposal, go for it. If you have a better approach, it
>> is good as well. It's up to you.
>>
>> Or maybe I'm getting confused?
>>
> You're not confused. But if Gaia follows this pattern it would be good to
> have as much developers on board as possible.
>
>
>>
>> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
>> nuestra política de envío y recepción de correo electrónico en el enlace
>> situado más abajo.
>> This message is intended exclusively for its addressee. We only send and
>> receive email on the basis of the terms set out at:
>> http://www.tid.es/ES/PAGINAS/**disclaimer.aspx<http://www.tid.es/ES/PAGINAS/disclaimer.aspx>
>> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
>> nuestra política de envío y recepción de correo electrónico en el enlace
>> situado más abajo.
>> This message is intended exclusively for its addressee. We only send and
>> receive email on the basis of the terms set out at:
>>
>
> ______________________________**_________________
> dev-gaia mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/**listinfo/dev-gaia<https://lists.mozilla.org/listinfo/dev-gaia>
>
--
Best,
Gareth
Gareth Aye
Jun 17, 2013, 8:38:22 PM6/17/13
to Vivien, dev-...@lists.mozilla.org, Staś Małolepszy, Salvador de la Puente González
As a followup, I just talked to lightsofapollo, jrburke, and asuth about
things like moving ui components, templating, and dependency management
into the platform which might have been assumed knowledge. I feel a bit
torn between the two ideas that we want to be moving abstractions into the
platform and we want people to feel comfortable writing web apps in the way
they're used to. Maybe there's a way that we can gradually accomplish both
goals (both in the platform and by example in Gaia).
--
Best,
Gareth
things like moving ui components, templating, and dependency management
into the platform which might have been assumed knowledge. I feel a bit
torn between the two ideas that we want to be moving abstractions into the
platform and we want people to feel comfortable writing web apps in the way
they're used to. Maybe there's a way that we can gradually accomplish both
goals (both in the platform and by example in Gaia).
Best,
Gareth
0 new messages