Retours sur [JavaScript Promises are equivalent to Python's asyncio]

JulienPradet commented 6 years ago

Je vais faire mes retours en français si ça ne te dérange pas :)

Retours points par points

Le code snippet avec les Promesses

Pour faire plus idiomatique, voici une alternative :

downloadData(url)
  .catch(e => downloadFallbackData(url))
  .then(data => processDataInWorker(data))

(Et c'est une des raisons pour laquelle j'ai du mal avec async/await : je trouve ça hyper clean avec les promesses déjà.)

A vérifier pour le catch. Et si c'est bien ça, go PR sur MDN \o

Je trouve que ça manque de transitions

En terme de style d'écriture je trouve que ça manque légèrement de transitions entre les parties. On ne comprend pas bien où tu veux en venir. Les liens de causalités sont souvent omis. C'est peut être juste une question de style.

Par exemple : Le paragraphe qui parle de ce que cherche à résoudre les promesses/async await. Juste avant le titre (ou juste après), j'aurais bien mis quelque chose du style : First thing first, in order to understand how they are similar, we need to understand what they are trying to solve.

Pour moi, là où ça manque, c'est :

The goal: not waiting for I/O
Le passage des threads à l'event loop. Plutôt que de commencer en disant ce qu'est une Event Loop, j'aurais plutôt commencé par expliquer ce qui manque (pas de thread en js, difficultés de partage de mémoire) pour ensuite introduire la solution alternative qui essaye de répondre à ces problèmes.
Level of abstraction : quand tu parles de callbacks ici, on a presque déjà oublié que le premier mécanisme pour l'event loop sont des callbacks. Peut être le répéter juste avant de parler du callback hell ?

Qu'est ce que I/O ?

Je ne crois pas avoir vu passer de définition de ce que c'est qu'une I/O. A une époque, je pensais qu'une I/O c'était juste une lecture de fichier. Du coup si j'étais tombé sur ce billet, je n'aurais pas bien compris le rapport entre I/O et requête http.

De plus, dans l'exemple que tu présentes côté browser, tu parles de requêtes à nouveau. Si c'est pas trop compliqué, je pense qu'un exemple qui parlera plus à des gens qui viennent du JS, ce sera plutôt de parler du fait qu'un utilisateur peut toujours cliquer sur un bouton/scroller, même quand une requête Ajax vient juste d'être lancée.

Description de l'Event loop

It will give work to the various functions that are running.

Je ne suis pas tout à fait d'accord avec cette description. Pour moi, c'est plutôt que la loop permet décaler dans le temps le retour d'une fonction et ainsi permet de faire passer une autre fonction avant si cette dernière est prête. Ca ne donne pas du travail vu que c'est juste une pile d’exécution.

Autre chose, j'aurais mis le lien sur event loop plutôt que sur a loop. J'ai pas cliqué la première fois en me disant que ça allait parler d'un while (true) de manière humouristique plutôt que de l'event loop en elle même.

Level of abstraction

J'aurais bien aimé un lien pour savoir ce que c'est que mio in Rust.

coming in browsers -> A ce stade d'adoption, c'est plutôt is pretty well supported by major browsers et c'est compilable pour les anciens.

Moving from Promises to async/await in JavaScript

This is much clearer.

La première fois que j'ai vu du async/await, j'ai trouvé ça beaucoup moins clair/abordable que des promesses qui sont l'outil que j'utilise depuis longtemps. Juste une question de formulation donc, parce que la suite à propos des familiar tools est très juste.

Idem sur you can simply await. J'évite le plus possible ce genre d'adjectifs. Ca aurait pu être : you can await on a promise in the exact same way as you would on an async function.

The only difference is that you still to await => The only difference is that you still need to await Et en vrai, si j'écris du JS, je vais mettre un await à la fin (même s'il n'est pas obligatoire) pour faciliter la lecture et bien montrer que c'est une promesse asynchrone.

Ressenti général

En vrai, c'est vraiment chouette comme article. J'ai fait pas mal de petits commentaires, mais ce sont plus des questions que des affirmations (c'est comme ça qu'il faut les lire en tout cas :D).

Je me rends moi aussi compte que async/await permet de faire venir plus de gens même si ça peut être perturbant pour les habitués de javascript/des promesses. Et c'est ce genre d'articles qui me permettent de le ressentir de plus en plus.

En tout cas, je ne sais pas si l'article était destiné aux gens de JavaScript autant que ceux de Python, mais c'est très orienté Python actuellement (ce qui est certainement mieux que de brouiller les pistes en voulant faire les deux).

Pouce bleu, comme disent les jeunes !

pquentin commented 6 years ago

Merci pour tes remarques qui sont très justes. Qu'entends-tu par "A vérifier pour le catch." ? C'est pas moi qui vait pouvoir vérifier quoi que ce soit en tout cas :D

JulienPradet commented 6 years ago

catch

Je voulais vérifier qu'il n'y ait pas besoin du then à l'intérieur du catch. C'est bien ça. Je vais faire un PR :)

pquentin / blog