car cela implique de creer/detruire pas mal d'objet.
Non justement. C'est le boulot de React de ne pas le faire.
Ainsi une API dans laquel on va juste rendre invisible explicitement le button sera plus efficace qu'une dans laquelle on va soit traverser un arbre ou parser une commande pour decider de rendre invisible ou detruire un button.
Oui, cela sera plus efficace, mais 90% du temps, tu veux surtout un code de GUI léger.
J'ai très bien compris le concept de retained, ce n'est pas le sujet. Dans une interface, tu n'as pas seulement le champs string qui bouge, tu as possiblement la création/destruction d'un ensemble de widget eux-même.
Si tu fonctionnes par modification de l'existant, cela donne du code touffu et plein de bug. Si tu fais (semblant) de tout recréer à chaque fois, c'est mille fois plus simple.
function Example() {
// Declare a new state variable, which we'll call "count"
const [count, setCount] = useState(0);
if (count === 10) {
return (<p> Ten time !<p>)
} else {
return (
<div>
<p>You clicked {count} times</p>
<button onClick={() => setCount(count + 1)}>
Click me
</button>
</div>
);
}
}
"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?"
Je ne vois pas de quoi tu parles.
"Il est donc necessaire pour un framework JS d'implementer une technique "retained" en interne pour avoir de bonne performance."
Oui, c'est la téchnique du shadow DOM. Mais tu veux dire que tu peux recréer complètement tout tes widgets à la volé à chaque modification du modèle applicatif sans perte de performance ? J'ai un gros doute.
Ce n'est même pas la technique de redux, c'est du pure reactjs. Essayes un hello-wold si tu as du mal à comprendre.
Le problème ne situe pas du tout au niveau dont tu parles.
Le problème concerne l'état réel de l'application vs ce que l'on peut afficher.
Avoir un objet "field" en cache ne t'aide en rien. Redessiner est bien plus simple au niveau de l'API, l’intérêt de react ou vue est de détecter les changements au niveau état de l'application, pas au niveau des widgets.
Oui, c'est ça qui est génial. Et je trouve dommage de ne pas avoir ce genre de puissance dans un langage compilé.
Je n'ai pas non plus parlé des Hooks que je trouve totalement génial car on remplace des classes et des High Order composant illisible par… des appels de fonctions tout simple !
Vu que tout ça est implémenté en Javascript, cela doit pouvoir se faire en autre chose.
C'est l'api qui te fait croire cela et qui simplifie tout.
Par contre, en vrai, il utilise la techno du "shadow DOM", ou il reconstruit un DOM, fait un "diff" et ne met à jour que les parties intéressantes. Je pense aussi qu'il fait une liaison entre l'object graphique généré et ses entrées, si l'entrée bouge, la fonction est relancé.
L'appli maintenable par un stagiaire, je n'y crois pas trop. L'avantage est justement de ne pas avoir le bordel de dépendance dans tous les sens. Cela ne se voit que sur des applis un peu grosses et/ou dynamiques.
La lourdeur de react&Co, c'est la techno web derrière, pas le concept de programmation.
Est-ce que ce genre de lib 2d peut servir de fondation à une structure imitant react ou vue ? en gros, les widgets seraient vue comme le DOM du navigateur web.
L'idée est vraiment de coder des appels de fonctions avec des entrées, et le framework appel la fonction à la demande, pas en passant par en dessous, avec tous les effets de bord de la terre imaginable.
Redux rajoute un cycle d’événement qui modifie l'état global qui ensuite modifie le rendu complet (le tout optimisé par le framework en dessous).
J'ai l'impression qu'il sont parti sur des interfaces "à l'ancienne" avec les call-back back de l'enfer.
Depuis que j'ai développé avec React (mais Vu.js, ELM, angular, sont pareil), c'est difficile de revenir en arrière.
Le principe de ces toolkit est d'avoir des fonctions qui retournent des éléments graphiques selon des entrées (que l'on peut cascader). Des setters sont transmis en profondeur pour modifier l'état global de l'application (ce qui génère un événement pour redessiner la partie concerné automagiquement). C'est beaucoup plus simple à écrire que de savoir quoi modifier selon l'action.
Dans les toolkit graphique, tout redessiner est très couteux, on gère donc des modifications qui deviennent un enfer à tenir cohérent.
J'ai eu une stagiaire, que je devais limite engueulé pour la pousser à ne pas se dévaloriser ("Si je n'étais pas meilleur que toi, à quoi bon avoir 20 ans d'expérience" "Tu apprends, là")
C'est moi où les filles sont souvent victime du syndrome de l'imposteur ? Je me rappelle d'une amie qui se sentaient toujours non pertinente pour devenir leader technique sur le sujet dans son domaine pointu qu'elle pratique depuis 10 ans…
"Tout d’abord, la consommation électrique n’est pas égale à la consommation énergétique. "
25% de l'énergie est électrique, le reste c'est le pétrole des véhicules et du chauffage.
"Aux Etats-Unis, les postes électriques ont un rendement moyen d’environ 30 pourcents. "
euh… J'imagine qu'il est question du rendement de centrale thermique 30% à 50% de l'énergie primaire convertie en électricitié.
"Ainsi, en multipliant dans un premier temps tous les chiffres par 3, on obtient une représentation un peu plus réaliste de la consommation d’énergie réelle de nos équipements électroniques."
oui mais on s'en fout.
"Ensuite, un autre point, trop souvent négligé, concerne la consommation d’énergie de l’infrastructure sous-jacente à de nombreuses technologies"
Ce n'est pas oublié, c'est juste négligeable devant les terminaux.
"L’énergie utilisée pour produire tous ces gadgets électroniques est considérablement plus élevée que l’énergie consommée pendant leur fonctionnement."
50 / 50 % pour la production de CO2 en France, pour un produit en chine, cela fait moins d'énergie pour la prod que pour la vie.
" Ceci était, pendant la majeure partie du 20ème siècle, assez différent ; les processus de fabrication n’étaient alors pas aussi énergivores. "
Justement non, un ordinateur prend toujours à peu pret la même quantité à être produite quelques soit sa puissance.
"L’énergie utilisée pour produire tous ces gadgets électroniques est considérablement plus élevée que l’énergie consommée pendant leur fonctionnement."
"l’énergie nécessaire … – est dérisoire comparée à l’énergie consommée durant son fonctionnement, en phase d’utilisation."
"Les voitures actuelles sont désormais bardées de circuits intégrés, de même que plein d’objets qui existaient depuis longtemps sous une forme analogique."
euh… une voiture actuelle consomme 3 ou 4 fois moins de pétrole qu'avant. Une puce c'est en gros un kilo de CO2.
"L’énergie grise d’une puce mémoire excède à elle seule la consommation énergétique d’un ordinateur portable sur les 3 ans de sa durée de vie prévisionnelle. "
Un disque dure était donné pour 45 kg de CO2 d’après greenit, l'équivalent de sa vie.
"Les économies d’énergie réalisées par le numérique seront largement absorbées par sa propre empreinte croissante. "
La VM ne cassera pas. Mais le code aura plus de droit pour faire tourner un code injecté. De plus, c est openbar sur les ressources de l application elle meme.
C'est pas faux. Mais j'ai l'impression que compromettre le service a bien plus d'impact si il est kernel, même en mono-application. L'application peut avoir un nombre de capacité réduite, qui limiterait beaucoup l'effet d'injection de code.
[^] # Re: Sur quelle planète ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Écrire directement aux Russes. Évalué à -2.
dis toi que dans le tas, il y a quelques trolls russes…
"La première sécurité est la liberté"
[^] # Re: Trop simple ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Interface graphique en Go!. Évalué à 3.
Non justement. C'est le boulot de React de ne pas le faire.
Oui, cela sera plus efficace, mais 90% du temps, tu veux surtout un code de GUI léger.
"La première sécurité est la liberté"
[^] # Re: Trop simple ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Interface graphique en Go!. Évalué à 3.
J'ai très bien compris le concept de retained, ce n'est pas le sujet. Dans une interface, tu n'as pas seulement le champs string qui bouge, tu as possiblement la création/destruction d'un ensemble de widget eux-même.
Si tu fonctionnes par modification de l'existant, cela donne du code touffu et plein de bug. Si tu fais (semblant) de tout recréer à chaque fois, c'est mille fois plus simple.
"La première sécurité est la liberté"
[^] # Re: Belle liste
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Des faits saillants pour une plus que centenaire. Évalué à 3. Dernière modification le 08 mars 2022 à 18:11.
.
"La première sécurité est la liberté"
[^] # Re: Trop simple ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Interface graphique en Go!. Évalué à 2.
Je ne vois pas de quoi tu parles.
Oui, c'est la téchnique du shadow DOM. Mais tu veux dire que tu peux recréer complètement tout tes widgets à la volé à chaque modification du modèle applicatif sans perte de performance ? J'ai un gros doute.
Ce n'est même pas la technique de redux, c'est du pure reactjs. Essayes un hello-wold si tu as du mal à comprendre.
"La première sécurité est la liberté"
[^] # Re: Trop simple ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Interface graphique en Go!. Évalué à 3.
Le problème ne situe pas du tout au niveau dont tu parles.
Le problème concerne l'état réel de l'application vs ce que l'on peut afficher.
Avoir un objet "field" en cache ne t'aide en rien. Redessiner est bien plus simple au niveau de l'API, l’intérêt de react ou vue est de détecter les changements au niveau état de l'application, pas au niveau des widgets.
"La première sécurité est la liberté"
[^] # Re: Trop simple ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Interface graphique en Go!. Évalué à 3.
Sauf si cela a fondamentalement changé depuis 10 ans, non pas du tout.
"La première sécurité est la liberté"
[^] # Re: Noms de domaines
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Quand la DGFiP (les impôts) donne des conseils de sécurité.... Évalué à 4.
Au pire, il devrait y avoir une redirection depuis un gouv.fr pour valider qu'un site est bien un site officiel.
"La première sécurité est la liberté"
[^] # Re: Trop simple ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Interface graphique en Go!. Évalué à 3.
Oui, c'est ça qui est génial. Et je trouve dommage de ne pas avoir ce genre de puissance dans un langage compilé.
Je n'ai pas non plus parlé des Hooks que je trouve totalement génial car on remplace des classes et des High Order composant illisible par… des appels de fonctions tout simple !
Vu que tout ça est implémenté en Javascript, cela doit pouvoir se faire en autre chose.
"La première sécurité est la liberté"
[^] # Re: Trop simple ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Interface graphique en Go!. Évalué à 6.
C'est l'api qui te fait croire cela et qui simplifie tout.
Par contre, en vrai, il utilise la techno du "shadow DOM", ou il reconstruit un DOM, fait un "diff" et ne met à jour que les parties intéressantes. Je pense aussi qu'il fait une liaison entre l'object graphique généré et ses entrées, si l'entrée bouge, la fonction est relancé.
"La première sécurité est la liberté"
[^] # Re: Trop simple ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Interface graphique en Go!. Évalué à 4.
L'appli maintenable par un stagiaire, je n'y crois pas trop. L'avantage est justement de ne pas avoir le bordel de dépendance dans tous les sens. Cela ne se voit que sur des applis un peu grosses et/ou dynamiques.
La lourdeur de react&Co, c'est la techno web derrière, pas le concept de programmation.
"La première sécurité est la liberté"
[^] # Re: Trop simple ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Interface graphique en Go!. Évalué à 3.
Est-ce que ce genre de lib 2d peut servir de fondation à une structure imitant react ou vue ? en gros, les widgets seraient vue comme le DOM du navigateur web.
"La première sécurité est la liberté"
[^] # Re: Trop simple ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Interface graphique en Go!. Évalué à 6.
C'est comme les slot de Qt ? On est loin de redux (https://redux.js.org/) ou de l'architecture d'ELM (https://guide.elm-lang.org/architecture/).
L'idée est vraiment de coder des appels de fonctions avec des entrées, et le framework appel la fonction à la demande, pas en passant par en dessous, avec tous les effets de bord de la terre imaginable.
Redux rajoute un cycle d’événement qui modifie l'état global qui ensuite modifie le rendu complet (le tout optimisé par le framework en dessous).
"La première sécurité est la liberté"
# Trop simple ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Interface graphique en Go!. Évalué à 7.
J'ai l'impression qu'il sont parti sur des interfaces "à l'ancienne" avec les call-back back de l'enfer.
Depuis que j'ai développé avec React (mais Vu.js, ELM, angular, sont pareil), c'est difficile de revenir en arrière.
Le principe de ces toolkit est d'avoir des fonctions qui retournent des éléments graphiques selon des entrées (que l'on peut cascader). Des setters sont transmis en profondeur pour modifier l'état global de l'application (ce qui génère un événement pour redessiner la partie concerné automagiquement). C'est beaucoup plus simple à écrire que de savoir quoi modifier selon l'action.
Dans les toolkit graphique, tout redessiner est très couteux, on gère donc des modifications qui deviennent un enfer à tenir cohérent.
"La première sécurité est la liberté"
[^] # Re: Go with C
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Interface graphique en Go!. Évalué à 4.
C'est uniquement un problème de LGPL, licence qui n'est plus si commune.
"La première sécurité est la liberté"
[^] # Re: Ça m'énerve
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Différences de genres dans la contribution au code libre. Évalué à 4.
J'ai eu une stagiaire, que je devais limite engueulé pour la pousser à ne pas se dévaloriser ("Si je n'étais pas meilleur que toi, à quoi bon avoir 20 ans d'expérience" "Tu apprends, là")
"La première sécurité est la liberté"
[^] # Re: Ça m'énerve
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Différences de genres dans la contribution au code libre. Évalué à 6.
C'est moi où les filles sont souvent victime du syndrome de l'imposteur ? Je me rappelle d'une amie qui se sentaient toujours non pertinente pour devenir leader technique sur le sujet dans son domaine pointu qu'elle pratique depuis 10 ans…
"La première sécurité est la liberté"
[^] # Re: Ça m'énerve
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Différences de genres dans la contribution au code libre. Évalué à 5.
Je me suis dit que l'année suivante, on allait tenter un singe.
"La première sécurité est la liberté"
[^] # Re: Ça m'énerve
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Différences de genres dans la contribution au code libre. Évalué à 4.
un expert il y a quelques années :
"vous vouliez une stagiaire, elle a été nulle : on arrête les frais, l"année prochaine on prend un mec."…
"La première sécurité est la liberté"
[^] # Re: fake news
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Greycess Knight RPG : de la 1.0.0 à la 1.0.1. Évalué à 1.
Parce que c'est un tissu de n'importe quoi : de la bouillie.
C'est long de décortiqué chaque ligne.
"Combien d’énergie nos gadgets high-tech consomment-ils réellement ? "
C'est en gros 50/50 pour les ordinateurs entre production et vie (en France, cf greenit).
"doublé d’ici 2022 et triplé à l’horizon 2030"
2 à 4%, mais 50% pour le chauffage, 20% pour le transport, etc…
https://www.statistiques.developpement-durable.gouv.fr/edition-numerique/chiffres-cles-energie-2021/image/conso-finale-energ-secteur-CGDD.svg
"Tout d’abord, la consommation électrique n’est pas égale à la consommation énergétique. "
25% de l'énergie est électrique, le reste c'est le pétrole des véhicules et du chauffage.
"Aux Etats-Unis, les postes électriques ont un rendement moyen d’environ 30 pourcents. "
euh… J'imagine qu'il est question du rendement de centrale thermique 30% à 50% de l'énergie primaire convertie en électricitié.
"Ainsi, en multipliant dans un premier temps tous les chiffres par 3, on obtient une représentation un peu plus réaliste de la consommation d’énergie réelle de nos équipements électroniques."
oui mais on s'en fout.
"Ensuite, un autre point, trop souvent négligé, concerne la consommation d’énergie de l’infrastructure sous-jacente à de nombreuses technologies"
Ce n'est pas oublié, c'est juste négligeable devant les terminaux.
"L’énergie utilisée pour produire tous ces gadgets électroniques est considérablement plus élevée que l’énergie consommée pendant leur fonctionnement."
50 / 50 % pour la production de CO2 en France, pour un produit en chine, cela fait moins d'énergie pour la prod que pour la vie.
" Ceci était, pendant la majeure partie du 20ème siècle, assez différent ; les processus de fabrication n’étaient alors pas aussi énergivores. "
Justement non, un ordinateur prend toujours à peu pret la même quantité à être produite quelques soit sa puissance.
"L’énergie utilisée pour produire tous ces gadgets électroniques est considérablement plus élevée que l’énergie consommée pendant leur fonctionnement."
"l’énergie nécessaire … – est dérisoire comparée à l’énergie consommée durant son fonctionnement, en phase d’utilisation."
"Les voitures actuelles sont désormais bardées de circuits intégrés, de même que plein d’objets qui existaient depuis longtemps sous une forme analogique."
euh… une voiture actuelle consomme 3 ou 4 fois moins de pétrole qu'avant. Une puce c'est en gros un kilo de CO2.
"L’énergie grise d’une puce mémoire excède à elle seule la consommation énergétique d’un ordinateur portable sur les 3 ans de sa durée de vie prévisionnelle. "
Un disque dure était donné pour 45 kg de CO2 d’après greenit, l'équivalent de sa vie.
"Les économies d’énergie réalisées par le numérique seront largement absorbées par sa propre empreinte croissante. "
cf la voiture…
"La première sécurité est la liberté"
# fake news
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Greycess Knight RPG : de la 1.0.0 à la 1.0.1. Évalué à 3.
https://solar.lowtechmagazine.com/fr/2009/06/embodied-energy-of-digital-technology.html est un ramassis de n'importe quoi, qui mélange énergie primaire, rendement et CO2 !
"La première sécurité est la liberté"
[^] # Re: Ça va faire mal aux boutons...
Posté par Nicolas Boulay (site web personnel) . En réponse au lien Bientôt la fin des CDN ?. Évalué à 3.
On dirait que le partage de font n est pas suffisant pour justifier de données les fonts. Un cache de tout le serait, je pense.
"La première sécurité est la liberté"
[^] # Re: Très intéressant !
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Compter automatiquement les mots prononcés sur les chaînes d'information continue. Évalué à 3.
Au niveau moteur de recherche https://quickwit.io/ semble bien indiqué pour chercher des mots dans des To de données.
"La première sécurité est la liberté"
[^] # Re: Besoin d'expliciter le init ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Linux et BusyBox, un duo parfait pour s'amuser. Évalué à 4.
La VM ne cassera pas. Mais le code aura plus de droit pour faire tourner un code injecté. De plus, c est openbar sur les ressources de l application elle meme.
"La première sécurité est la liberté"
[^] # Re: Besoin d'expliciter le init ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Linux et BusyBox, un duo parfait pour s'amuser. Évalué à 4.
C'est pas faux. Mais j'ai l'impression que compromettre le service a bien plus d'impact si il est kernel, même en mono-application. L'application peut avoir un nombre de capacité réduite, qui limiterait beaucoup l'effet d'injection de code.
"La première sécurité est la liberté"