Confirmed users
51
edits
Gaia/Architecture Proposal: Difference between revisions
→Front-End: optimizing for readability
(→Front-End: optimizing for readability) |
|||
| Line 208: | Line 208: | ||
[[File:Gaia Architecture Proposal FrontEnd Overview.png]] | [[File:Gaia Architecture Proposal FrontEnd Overview.png]] | ||
As mentioned in the introduction, every view is an independent capsule, living in its own compartment. | |||
Technically the compartment split is implemented using a separated <iframe> for each view. Those views are wrapped into a container responsible for the application navigation as well as transitions. | |||
'''The frond-end is the part responsible for perceived performance, the main thread should be handled with care.'''<br /> | |||
=== Disclaimers === | |||
''Note: A fairly common mistake is to try to compare this high-level decoupling with existing framework. Those are solving orthogonal problems, and a direct comparison does not really make sense. <br /> The main idea here is to expose some of the application logic to the web browser in order to benefits from the browser internal machinery as well as being able to get low level monitoring for the exposed part of the application. <br /> This model is not about using x, y or z. It is technology agnostic and uses very basic primitives of the Web. Various technologies can be put on top of that (module UI, React, Web Components, etc.) and can actually be benchmarked with real data from users using Telemetry. | ''Note: A fairly common mistake is to try to compare this high-level decoupling with existing framework. Those are solving orthogonal problems, and a direct comparison does not really make sense. <br /> The main idea here is to expose some of the application logic to the web browser in order to benefits from the browser internal machinery as well as being able to get low level monitoring for the exposed part of the application. <br /> This model is not about using x, y or z. It is technology agnostic and uses very basic primitives of the Web. Various technologies can be put on top of that (module UI, React, Web Components, etc.) and can actually be benchmarked with real data from users using Telemetry. | ||
'' | '' | ||
''Note: There seems to be a common negative feeling about <iframe>s. Please note that <iframe>s are just a tool to achieve this compartment isolation which results into exposing the app internals to the Web Browser. So are <iframe>s the future of the Web? Probably not, but a high level encapsulation is definitively needed, and the only thing that provide this level of encapsulation at the moment is an <iframe>.'' | ''Note: There seems to be a common negative feeling about <iframe>s. Please note that <iframe>s are just a tool to achieve this compartment isolation which results into exposing the app internals to the Web Browser. So are <iframe>s the future of the Web? Probably not, but a high level encapsulation is definitively needed, and the only thing that provide this level of encapsulation at the moment is an <iframe>.'' | ||
Features | === Features === | ||
* High-Level Content encapsulation aka no | * High-Level Content encapsulation aka no collisions between views for: | ||
** DOM | ** DOM | ||
*** DOM per view. When the DOM needs to be traversed for any restyle/reflow/repaint operations, it makes it cheaper. | *** DOM per view. When the DOM needs to be traversed for any restyle/reflow/repaint operations, it makes it cheaper. | ||
| Line 229: | Line 230: | ||
*** Smaller JS Heap Size. When the mark-and-sweep algorithm used for GC has to run, it does not need to iterate over the whole Object tree. | *** Smaller JS Heap Size. When the mark-and-sweep algorithm used for GC has to run, it does not need to iterate over the whole Object tree. | ||
** Locales | ** Locales | ||
* | * Contained regressions. A change in a view should not affect other views. | ||
* Per-View | * Fully [https://developer.mozilla.org/en-US/Apps/Build/Performance/UI_Synchronicity async UI] | ||
* Per-View instrumentation | |||
** Performance API | ** Performance API | ||
** Visibility State (visible, hidden, prerendered) | ** Visibility State (visible, hidden, prerendered) | ||
** about:memory | ** about:memory | ||
** Telemetry reports | ** Telemetry reports | ||
* Prioritization/ | * Prioritization/De-prioritization of views on the event loop. (Since they all run on the UI thread). | ||
* Safe load/unload mechanism for views | * Safe load/unload mechanism for views | ||