Quel est l'interet de dupliquer en memoire une information qui ne sera pas utiliser pour realiser le contenu de l'application a l'ecran? Quel est l'interet de calculer le delta de quelques choses qui sera ignore au final?
React et vue existe et on du sens dans le monde du DOM et du web. Car dans cette univers, tu as un document dont il est couteux de faire une modification et la barriere DOM / JS est lente. Le cout de modification d'une entree du DOM en JS n'est pas juste l'assignation d'une valeur et generalement pas en O(1). Dans cette univers, il est necessaire d'eviter de modifier la representation de ce qui doit etre redessiner pour des questions de performance. Il est donc necessaire pour un framework JS d'implementer une technique "retained" en interne pour avoir de bonne performance.
Dans le cas du natif, ce probleme de barriere DOM/JS et de performance de rendu n'est plus. Une API efficace native peut exposer que des operations qui sont relatif au rendu de la fenetre (Il n'est pas necessaire de maintenir l'etat de ce qui n'est pas l'ecran). Les acces a toutes les fonctions qui modifie le rendu peuvent etre en O(1) et negligeable en terme de cout d'utilisation (plusieur millier d'appel par frame, ne doivent declencher que un seul calcul par frame et idealement sans jamais bloquer un seul de ces appel).
Ceux sont des differences fondamentales entre les contraintes web et les contraintes natives.
[^] # Re: Trop simple ?
Posté par cedric . En réponse au journal Interface graphique en Go!. Évalué à 4.
Quel est l'interet de dupliquer en memoire une information qui ne sera pas utiliser pour realiser le contenu de l'application a l'ecran? Quel est l'interet de calculer le delta de quelques choses qui sera ignore au final?
React et vue existe et on du sens dans le monde du DOM et du web. Car dans cette univers, tu as un document dont il est couteux de faire une modification et la barriere DOM / JS est lente. Le cout de modification d'une entree du DOM en JS n'est pas juste l'assignation d'une valeur et generalement pas en O(1). Dans cette univers, il est necessaire d'eviter de modifier la representation de ce qui doit etre redessiner pour des questions de performance. Il est donc necessaire pour un framework JS d'implementer une technique "retained" en interne pour avoir de bonne performance.
Dans le cas du natif, ce probleme de barriere DOM/JS et de performance de rendu n'est plus. Une API efficace native peut exposer que des operations qui sont relatif au rendu de la fenetre (Il n'est pas necessaire de maintenir l'etat de ce qui n'est pas l'ecran). Les acces a toutes les fonctions qui modifie le rendu peuvent etre en O(1) et negligeable en terme de cout d'utilisation (plusieur millier d'appel par frame, ne doivent declencher que un seul calcul par frame et idealement sans jamais bloquer un seul de ces appel).
Ceux sont des differences fondamentales entre les contraintes web et les contraintes natives.