Gaia/Architecture Proposal: Difference between revisions

Gaia/Architecture Proposal (view source)

Revision as of 15:42, 6 March 2015

20 bytes removed , 6 March 2015

m

→‎Front-End

Etienne s

Confirmed users

51

edits

@@ Line 197: / Line 197: @@
 [[File:Gaia Architecture Proposal FrontEnd Overview.png]]
-The frond-end is the part responsible for perceived performance.<br />
+'''The frond-end is the part responsible for perceived performance.'''<br />
 As mentioned in the introduction, every view is an independent capsule, living in its own compartment.
-''Note: As fairly common mistake is to try to compare this high-level decoupling with existing framework. Those are solving orthogonal problems, and face-to-face comparison does not really makes 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 beeing able to get low level informations for the exposed part of the application. <br /> Also the model is not about using x, y or z. It is technology agnostic and use very basic primitives of the Web, and so various technologies can be put on top of that (module UI, React, Web Components, etc.) and can be compared 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.
 ''
 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.''
-''Note: It seems to be a common negative feeling about <iframe>s. Please note that <iframe>s are not the goal, but a tool to achieve this compartment splitting which results into exposing the app internals to the Web Browser. So does <iframe>s are the future of the Web. Probably not, but a high level encapsulation seems definitively needed, and the only thing that provide this level of encapsulation for 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: