Aller au contenu

CODE et autres trucs d'informatiques incompehenssibles


L'affreux

Messages recommandés

Il est mal foutu, mais au moins ça fonctionne déjà sur des sites à fort trafic. Et Facebook utilisait déjà React longtemps avant sa publication, donc avec ou sans React c'est un clairement un site très gourmand en ressources. Il y a aussi une part de réaction (ahah) à l'encontre d'Angular, mais il y a un phénomène intéressant qui est que React pollinise d'autres frameworks avec les idées de vDOM, styling en JavaScript, Flux, etc.  J'ai déjà repéré 3-4 frameworks qui se basent sur vDOM et se disent meilleurs que React. Ember.js commence à incorporer des idées aussi. Donc ça me paraît parti pour durer.

À propos de React : Is ReactJS really fast?

Hé hé.

Lien vers le commentaire

À propos de React : Is ReactJS really fast?

Hé hé.

;)

 

J'ai vu ça en effet. J'aime beaucoup le "track by key", c'est bien dans l'esprit Angular: impossible à deviner, tout le monde va se planter et utiliser la version non optimisée. Et c'est bien dans la veine des meilleures critiques d'Angular que j'ai vues: le soucis c'est que le framework ne guide pas l'utilisateur vers la bonne solution, mais plutôt dans pas mal d'impasses dont il faut apprendre à se sortir. Un gars parlait du "pit of despair" vs "pit of success".

 

Lien vers le commentaire

Si le vdom est plus performant, c'est parce qu'il ne franchis pas la frontière entre la VM et le renderer, par conséquent c'est un simple probleme technique à regler par les éditeurs de browsers, et je n'ai aucun doute sur le fait qu'ils vont le regler, ce n'est pas atrocement difficile de déplacer ou de facader le dom.

 

De fait, il n'est pas très difficile de brancher AngularJS à un vdom si on le souhaite, et de génerer un diffset à appliquer sur le RequestAnimationFrame.

 

Rien n'interdit de fait de se limiter à manipuler des layers avec AngularJS et d'avoir toute l'acceleration GPU aux fesses dans 95% des frames et d'avoir un worker qui prépare de façon asynchrone le diffset et remplis lentement un hidden layer avec le nouveau sous-dom pour pouvoir ensuite swapper le contenu d'une layer en nettement moins de 15ms.

 

Aka: if your code is slowass, you are doing it WRONG, the very abstract Angular framework is not the culprit, your directives are shit, the domain model granularity is bad and you are just bad at programming.

 

Edit: et oui, les exemples Angular par défaut sont relativement shitty, parce que 99% des utilisateurs n'ont pas besoin de viser les 60FPS avec des milliers d'objects complexes, ils veulent juste afficher une pauvre liste de 15 elements avec trois actions à la noix, parce que le business need n'est pas plus exigeant que ça.

 

Edit2: Tl;Dr, le browser c'est une plateforme comme les autres, pour la majorité des applications un singe qui n'a pas la moindre idée du fonctionnement du système peut sortir une appli fonctionnelle qui réponds de façon satisfaisante au besoin du client, pour la minorité des cas, il faut un vrai développeur, pas un code monkey.

 

Lien vers le commentaire

J'ai a plusieurs reprises explosé du code soit disant "natif" et écrit en C++ "parce que ça va vite" avec le moteur JS préhistorique d'internet exploder 6, alors avec V8 ou Spidermonkey, c'est easy money.

 

Edit (encore un): Apple Webkit c'est un cas particulier, il est volontairement bridé pour forcer les devs à faire du "natif" et en faire des esclaves de l'écosystème apple, Pankakke avait en partie raison, si les utilisateurs d'Apple n'ont pas nécéssairement une mentalité d'esclave, Apple à une mentalité d'esclavagiste.

 

Lien vers le commentaire

Si le vdom est plus performant, c'est parce qu'il ne franchis pas la frontière entre la VM et le renderer, par conséquent c'est un simple probleme technique à regler par les éditeurs de browsers, et je n'ai aucun doute sur le fait qu'ils vont le regler, ce n'est pas atrocement difficile de déplacer ou de facader le dom.

Merci. Et en plus il n'est plus performant qu'en théorie, en attendant une démonstration par la pratique, car pour le moment tout ce qu'on sait c'est que Angular vaut React.

Lien vers le commentaire

Si le vdom est plus performant, c'est parce qu'il ne franchis pas la frontière entre la VM et le renderer, par conséquent c'est un simple probleme technique à regler par les éditeurs de browsers, et je n'ai aucun doute sur le fait qu'ils vont le regler, ce n'est pas atrocement difficile de déplacer ou de facader le dom.

Pas seulement: c'est aussi parce que ça permet de ne mettre à jour que la portion du DOM qui à changé réellement. Et aussi parce que le DOM virtuel n'a pas besoin d'implémenter tous les attributs du DOM (c'est un subset). Et je ne crois pas que le problème technique soit si simple que ça à régler dans les browsers (sinon ça serait déjà en cours d'implémentation).

 

De fait, il n'est pas très difficile de brancher AngularJS à un vdom si on le souhaite, et de génerer un diffset à appliquer sur le RequestAnimationFrame.

 

Rien n'interdit de fait de se limiter à manipuler des layers avec AngularJS et d'avoir toute l'acceleration GPU aux fesses dans 95% des frames et d'avoir un worker qui prépare de façon asynchrone le diffset et remplis lentement un hidden layer avec le nouveau sous-dom pour pouvoir ensuite swapper le contenu d'une layer en nettement moins de 15ms.

 

Aka: if your code is slowass, you are doing it WRONG, the very abstract Angular framework is not the culprit, your directives are shit, the domain model granularity is bad and you are just bad at programming.

 

Edit: et oui, les exemples Angular par défaut sont relativement shitty, parce que 99% des utilisateurs n'ont pas besoin de viser les 60FPS avec des milliers d'objects complexes, ils veulent juste afficher une pauvre liste de 15 elements avec trois actions à la noix, parce que le business need n'est pas plus exigeant que ça.

 

Edit2: Tl;Dr, le browser c'est une plateforme comme les autres, pour la majorité des applications un singe qui n'a pas la moindre idée du fonctionnement du système peut sortir une appli fonctionnelle qui réponds de façon satisfaisante au besoin du client, pour la minorité des cas, il faut un vrai développeur, pas un code monkey.

Y'a juste un gros problème avec Angular, toujours le même depuis le début: c'est très facile de faire de la merde avec Angular vu que le framework n'incite pas vraiment à développer le meilleur code possible. Exemple éclatant avec des gens pourtant expérimentés qui soumettent des exemples non optimaux pour des benchmarks.

Lien vers le commentaire

Pas seulement: c'est aussi parce que ça permet de ne mettre à jour que la portion du DOM qui à changé réellement. Et aussi parce que le DOM virtuel n'a pas besoin d'implémenter tous les attributs du DOM (c'est un subset). Et je ne crois pas que le problème technique soit si simple que ça à régler dans les browsers (sinon ça serait déjà en cours d'implémentation).

Mais le DOM est virtuel, c'est une représentation en mémoire sous la forme d'objets JS des éléments affichés à l'écran. Ce mécanisme est déjà implémenté par les navigateurs. Et cela explique sûrement pourquoi on n'a pas encore vu un benchmark d'une surcouche vDOM qui doublerait l'utilisation directe du DOM.

Sinon effectivement Angular est mal foutu. Tellement que son équipe a décidé de tout remettre à plat sans s'embarrasser de la compatibilité. Angular 1 était une plateforme innovante qui a apporté une vraie rupture dans les frameworks JS : un moteur de templates avec double binding. Je pense que les frameworks du futur auront tous cette fonctionnalité.

Lien vers le commentaire

Angular n'est pas si mal foutu que ça franchement, ils ont voulu faire trop de choses (en particulier l'injection de dépendences, la couche de services, et toute la complexité et la rigidité qui vont avec, ils auraient juste fait les controlleurs et les directives, en laissant les devs faire les cablages avec le framework d'injection de dépendence qu'ils voulaient, ça aurai été plus simple pour tout le monde), mais pour l'instant, ce que je vois de la V2 ne me convainc pas des masses, wait & see, mais on peut prendre les concepts d'angular et en faire un système plus simple au lieu d'en faire un systeme plus complexe mais avec plein de syntaxic sugar pour planquer la complexité.

 

Globalement, moi je garderait le systeme de scopes et le systeme de directives custom (donc avec un moteur de template et des watchers), et je jetterai tout le reste en disant "tu a browserify, juste require ce que tu veux, et fait pas chier"

 

Lien vers le commentaire

Mais le DOM est virtuel, c'est une représentation en mémoire sous la forme d'objets JS des éléments affichés à l'écran. Ce mécanisme est déjà implémenté par les navigateurs. Et cela explique sûrement pourquoi on n'a pas encore vu un benchmark d'une surcouche vDOM qui doublerait l'utilisation directe du DOM.

Faudrait vraiment que je retrouve cet article qui parlait natif vs vDOM :P

 

Mais oui, mais non: la différence c'est que le vDOM ne met à jour que les éléments qui ont changé et fait du multiplexage des mise-à-jour. Et aussi le DOM virtuel n'est pas une copie à 100% mais juste un subset du DOM, ou des tas d'attributs ne sont pas gérés, et en particulier les CSS. C'est juste monstrueux le nombre d'attributs possibles sur un élément, et le DOM natif doit obligatoirement tout implémenter, même si ce n'est pas utilisé.

 

https://stackoverflow.com/questions/21109361/why-is-reacts-concept-of-virtual-dom-said-to-be-more-performant-than-dirty-mode

 

 

 

  1. DOM updating: DOM operations are very expensive because modifying the DOM will also apply and calculate CSS styles, layouts. The saved time from unnecessary DOM modification can be longer than the time spent diffing the virtual DOM.

 

Lien vers le commentaire

 

Mettre à jour le DOM ne crée pas systématiquement des repaint event, et encore moins des reflow events, faut pas faire n'importe quoi évidemment, mais mettre à jour un shadow dom et ensuite swapper en garentissant que le repaint ne touche q'une layer (donc une seule texture pour le GPU), ça va bien plus vite que le temps que tes pauvres petites LEDS ne finissent de changer d'intensité.

 

Le probleme, ce n'est pas que les modifications du DOM causent des repaint (ça tu peux avoir tous les VDom de la terre, si le résultat final crée un reflow et des repaint de partout, il crée un reflow et des repaints de partout, tu est bien obligé un jour ou l'autre de le mettre à jour le vrai DOM), mais le context switch entre la VM et le DOM qui est une représentation mémoire en C++ de l'autre coté de la barrière de la VM (et qui est défini en IDL bien dégeu, venu de nulle-part, c'est CORBA !), donc si tu fait des centaines d'appels au DOM, tu paye des centaines de context switch.

 

La solution à terme, c'est clairement au niveau des browser vendors de mettre à disposition un dom coté VM, et un "dom switch" au requestAnimationFrame, une forme de buffering du scene graph quoi... En attendant, y'a plein de solutions, et le plus drole c'est q'une des plus efficace fait hurler tout le monde: innerHTML (un seul changement de contexte, tu touche pas au DOM, tu à un cout de parsing, mais qui est assez vite inférieur à la manipulation à travers la barrière VM/Scene Graph de centaines de noeuds et d'attributs).

 

Evidemment, comme jquery à appris à tout le monde à faire exactement tout ce qu'il ne faut pas faire, ça n'aide pas, mais bon, les gens ils ont un truc entre les oreilles, ils ont qu'a s'en servir hein.

Lien vers le commentaire

Mais oui, mais non: la différence c'est que le vDOM ne met à jour que les éléments qui ont changé et fait du multiplexage des mise-à-jour. Et aussi le DOM virtuel n'est pas une copie à 100% mais juste un subset du DOM, ou des tas d'attributs ne sont pas gérés, et en particulier les CSS. C'est juste monstrueux le nombre d'attributs possibles sur un élément, et le DOM natif doit obligatoirement tout implémenter, même si ce n'est pas utilisé.

 

Oui, oui, j'ai lu l'article, faut arreter avec les horribles attributs surnuméraires, si on n'y touche pas, ils ont un cout nul, faut juste jamais énumérer les attributs.

 

Et regrouper les updates du dom, c'est un peu la base à partir du moment ou tu isole ta vue de ton modèle, y'a que les jqueryeux qui ne savent pas qu'il y à une différence entre la vue et le modèle...

 

Justement, angularJS ne déclanche les watchers "finaux" qu'a l'équilibre, donc de fait fait déjà tout le boulot nécéssaire pour que tes directives ne doivent faire leurs modifs q'une seule et unique fois par évenement métier, et pas à chaque itération de la propagation des valeurs, y'a plus qu'a écrire les directives pas comme un tocard (première regle, toute librairie de composents qui à  besoin de jquery en plus d'angular est à jeter, par construction c'est des gens qui n'ont rien pigé à angular qui l'ont fait).

 

Je ne dis pas que le vDOM n'aide pas à faire les choses proprement, il aide le developpeur à faire du code qui va limiter les changements de contexte, donc oui, si le dev est incompétent, pour une application simple, il fera plus facilement ses 60 FPS avec react, mais à partir du moment ou il va y avoir des composents un peu complexes, des hierarchies de composents avec des machines à état un peu plus lourde qu'une todolist, leur modèle ne scale pas bien du tout par ailleurs.

 

Donc tu sacrifie énormément de scalabilité du code pour ne pas avoir à etre tenté de faire de la merde avec jquery, et au final, le dev qui fait du reflow, il fera du reflow en vdom autant qu'avec des accès dom normaux, et ça sera pourri parce qu'au lieu d'utiliser le compositeur, il va forcer le browser à faire du bon vieux dirty region repaint en masse, et la, tu peux le faire avec un seul accès DOM, ça sera lent pareil, ta frame sera trop longue de toute façon.

Lien vers le commentaire

Mais oui, mais non: la différence c'est que le vDOM ne met à jour que les éléments qui ont changé et fait du multiplexage des mise-à-jour.

Lors de l'exécution du code JS synchrone, les reflows n'ont pas lieu systématiquement. Il est possible de faire de multiples opérations sur le DOM sans perte de performance. Par exemple tant qu'on ne lit pas dans le DOM des propriétés de taille ou de positionnement, il n'y a aucune raison pour que le moteur de rendu les calcule.

http://stackoverflow.com/questions/510213/when-does-reflow-happen-in-a-dom-environment

http://www.stubbornella.org/content/2009/03/27/reflows-repaints-css-performance-making-your-javascript-slow/

Maintenant c'est vrai que si tu supprimes un élément puis que tu en recrées un, identique à l'ancien et au même endroit, le vDOM saura ne rien faire alors que le DOM exécutera la double opération. Mais bon. En pratique, lorsqu'on sait ce qu'on fait, cet avantage du vDOM ne se traduit pas en avantage sensible.

Lien vers le commentaire

L'Église catholique nous a gratifié de controverses assez intéressantes du genre :" les femmes ont-elles une âme ?", etc

À présent, afin de créer le buzz, ils devraient tenter ; "les geeks informatiques sont-ils une engeance diabolique ?"

En tout cas, je me pose cette question à chaque fois que je viens sur ce fil.

Lien vers le commentaire

Créer un compte ou se connecter pour commenter

Vous devez être membre afin de pouvoir déposer un commentaire

Créer un compte

Créez un compte sur notre communauté. C’est facile !

Créer un nouveau compte

Se connecter

Vous avez déjà un compte ? Connectez-vous ici.

Connectez-vous maintenant
×
×
  • Créer...