j'en reviens donc à la connaissance des outils et donc aux mauvais dev
le vrai test est ===, ne pas lire la doc ne rend pas l'outil "mauvais" ou non "fiable"
(mais perso je serait d'accord pour supprimer "=="
> Quand a cette volonté de tout faire en asynchrone.... A part des maux de tète inutiles, et plein de complications pour rien...
pour rien ? mdr tu devrais le tester pour de vrai à l'occasion alors
edit >
exemple de log de sortie d'un de mes soft, ça tape en // une multitude d'apis différentes, traite les données, les exportes et les sauves soit en local soit sur du distant, moins de deux minutes pour gérer l'ensemble (sans cache une des api met deux heures à être interrogé totalement, grâce à l'async toutes les autres sont dispo dans les deux minutes plutôt que les deux heures) et faire de l'up et du down au même moment ça rulez
autre délire node possède des pipes natifs avec de beau callbacks, lire un fichier de 4Gb le compresser et le sauver est possible en moins de 10 lignes sans bouffer ta mémoire et en laissant toute la réactivité à ton soft pour foutre autre chose, est ce possible ailleurs ?
> qui travaillent en monothread
ton programme taffe en mono thread, pas tout ce que tu lance en fond (pour bosser vraiment), tout fonctionne en event et callback, c'est ce qui rend les softs écrits avec si réactifs et justement non bloquant
> donc un JS qui ne s'arrête jamais == le navigateur bloqué, et rien d'autre.
=> mauvais dev
> L'asynchrone n'est vraiment de plus qu'un potentiel nid a problèmes et tends a rendre les choses largement plus complexes qu'elle ne devrait être dans la majorité des cas.
encore une fois, rigueur ! un débutant va forcément écrire du code super imbriqué ou spaghetti oui, mais une fois bien géré ça rulez