Logo JavaScript

Pensez asynchrone

Flattr this!

Il y a peu, j'ai réalisé que certains de mes collègues ou autres camarades développeurs ne maîtrisent pas voire carrément ne comprennent pas la simple notion d'asynchrone.

Asynchrone, c'est quoi ?

Commençons par comprendre le terme lui-même.

C'est très simple puisque c'est quelque chose qui n'est pas synchrone. C'est à dire quelque chose dont on sait à quel moment on lui demande de démarrer. Par contre, on ne sait pas quand ça démarrera vraiment et seul lui sait quand il aura fini. En gros, vous vous ne savez rien et allez devoir faire avec.

Ça fait partie de la philosophie du JavaScript. Pouvoir lancer des choses sans avoir à se préoccuper de quand ça finira et que ça ne bloquera pas l'utilisateur dans son usage de votre application.

Je ne maîtrise rien ?!

Effectivement, vous ne pouvez pas savoir à l'avance ce qu'il va se passer, ni si les traitements que vous avez demandé vont finir et comment ils vont finir. J'en vois déjà qui commencent à pleurer.

Mais c'est le principe de l'événementiel. Vous ne savez pas quelle fonctionnalité de votre application le visiteur veut et/ou va utiliser. Ni quand.

Par contre, il y a quand même un truc que vous maîtrisez : dans la plupart des cas, vous pouvez demander aux fonctions asynchrones de JavaScript d'exécuter des callbacks.

Un callback est une fonction qui sera exécutée à la fin du traitement asynchrone. Et là vous savez forcément quand le traitement est fini. C'est donc là que vous devez faire ce qui est censé se faire obligatoirement après la fin d'exécution.

Rien de compliqué finalement, non ? Surtout que...

Vous savez déjà penser et faire de l'asynchrone

Quand vous codez un site web tout ce qu'il y a de plus banal, sans aucun JS, ou en tout cas sans Ajax. Vous définissez une sorte de liste des réponses à toutes les requêtes que pourrait émettre le client. Vous supposez d'un parcours "standard". Mais quoi qu'il arrive, vous êtes obligés par la nature même de la navigation Web de prévoir tout changement d'URL et d'être capable d'y répondre. A tout moment.

Quand votre visiteur demande une page, le serveur est contacté, répondra (peut être) quelque chose mais le navigateur ne sait pas quand, il attend bêtement la réponse du serveur. Et quand il l'a reçoit, il ne sait qu'à ce moment là ce qu'est devenu sa demande, jamais avant. Sauf timeout bien sûr. Pourtant pendant ce temps là, le visiteur peut continuer sa lecture, faire d'autres requêtes... Ceci est de l'asynchrone.

On va prendre un exemple de la vie courante et je vais en prendre un peu glamour, attention les yeux ! Quand vous allez aux toilettes, vous donnez plus ou moins l'ordre d'évacuer le nécessaire. Pour autant, rien ne vous empêche de faire autre chose en même temps pendant que votre corps s'exécute. Et l'exemple le plus parlant du callback, c'est que même si vous savez que vous allez devoir vous essuyer et vous rhabiller après, vous ne saurez que vous pouvez le faire et quand le faire que lorsque votre corps aura fini sa petite affaire. Jamais avant. Vous ne savez jamais si vous en avez pour 5,10,20 secondes ou dix minutes. Et vous pouvez difficilement définir un temps arbitraire systématique pour passer à l'action d'après. Ou alors votre hygiène doit être déplorable 😉

Voilà, vous savez faire de l'asynchrone. Vous saviez déjà.

Ps : J'ai presque même tendance à croire que c'est la pensée synchrone qui ne devrait pas être naturel. Mais si vous vous essuyez après vous être rhabillé, vous êtes mal aussi. Les deux modes de pensée sont donc totalement naturel chez n'importe quel être humain.

Flattr this!

A propos de Mathieu

Ingénieur développeur web dans la vente par correspondance B2B, adepte de nouvelles technologies et d'innovation. Vous pouvez aussi me retrouver sur Twitter @mathrobin
Cette entrée a été publiée dans JavaScript, avec comme mot(s)-clef(s) , , , . Vous pouvez la mettre en favoris avec ce permalien.
  • http://www.yves-astier.com/ Yves Astier

    Je te rejoins totalement dans le fait que peu de développeurs sont au point la dessus par contre je m’attendais à un article plus complet sur le sujet.
    Ce serait intéressant que tu fasses un exemple/tuto pour montrer l’usage des méthodes permettant dans jQuery de gérer l’asynchrone (je pense notamment à cette partie de la doc. http://api.jquery.com/category/deferred-object/ ).

    • http://www.mathieurobin.com/ Mathieu

      Merci de confirmer mon point de vue, je me sens moins seul 😉
      Pour ce qui est de la profondeur d’article, elle est voulue. Je songe à faire justement d’autres articles sur le sujet (quand j’aurai le temps, la difficulté est là), et chacun centré sur une techno ou une idée pour aller plus loin sur ce thème. Là ce n’est qu’une approche générale que je voulais simple justement pour éviter de perdre les gens. Et au passage, que ce soit de mon oeuvre ou pas, je déteste les articles longs qui nécessitent une demie-heure de lecture. Ce n’est pas comme ça que je vois le fait de bloguer. Deferred fera partie des premiers (si ce n’est le premier) articles « spécialisés ».

  • http://www.tintworld.org Tintwo

    J’dois pas croiser les mêmes devs que vous, ou alors j’suis bien entouré, ou alors ils cachent bien leur jeu ^^

    • http://www.mathieurobin.com/ Mathieu

      On s’est croisés à l’eXia donc effectivement, là bas on a appris quelques trucs sur le multi-taches. Mais en BTS… Après oui, les devs finissent par le découvrir et apprendre

Articles liés