Créé en 1995, JavaScript est aujourd'hui le langage le plus populaire selon de nombreux baromètres. C'est également l'écosystème dans lequel on voit le plus de technologies naitre tous les jours. Comme conséquence, il est parfois très difficile de faire des choix ou de voir une technologie s'imposer comme la norme à moins d'avoir de puissants sponsors pour la propulser. Selon les catégories, certaines technologies arrivent toutefois à se distinguer. C'est dans le but d'identifier clairement ces dernières qu'entre en jeu le State of JavaScript, une enquête annuelle internationale sur l'écosystème JavaScript.Les résultats de l'édition 2021 sont disponibles et nous présentons ici les points saillants.
L'enquête State of JavaScript de 2020 est issu d'une enquête auprès de 23 000 développeurs. 2021 était le résultat d'un peu plus de 16 000. Et bien que les États-Unis soient en tête, leur part de répondants au sondage est tombée à 14 % et la Russie a grimpé à la troisième place derrière l'Allemagne avec 4 %. La France a produit 4,2 % des réponses de l'enquête, ce qui correspond à 668 développeurs JavaScript. D'ailleurs, les langues dans lesquelles les développeurs JavaScript ont répondu sont :
- l'anglais avec 70,1 % ;
- l'espagnol avec 5,4 % ;
- le russe avec 5 % ;
- le français avec 3,3 % ;
- l'allemand avec 2,3 %.
Aperçu des utilisations
Ce graphique présente les différents taux d'adoption pour chaque fonctionnalité, groupé par catégorie. La taille du cercle externe correspond au nombre total d'utilisateurs qui connaissent une fonctionnalité, alors que le celui interne représente ceux qui l'utilisent actuellement.
Langage
Quel niveau de compétence dans le vocabulaire de JavaScript ?
Les proxy : l'objet Proxy est utilisé afin de définir un comportement sur mesure pour certaines opérations fondamentales (par exemple, l'accès aux propriétés, les affectations, les énumérations, les appels de fonctions, etc.). En 2021, 26,1 % du panel a déclaré les avoir déjà utilisés, contre 22,4 % en 2020 et 17,4 % en 2019. 43,5 % du panel en a déjà entendu parler, contre 39,1 % en 2020 et 39,8 % en 2019.
Promise.allSettled() : La méthode Promise.allSettled() renvoie une promesse qui est résolue une fois que l'ensemble des promesses de l'itérable passée en argument sont réussies ou rejetées. La valeur de résolution de cette promesse est un tableau d'objets dont chacun est le résultat de chaque promesse de l'itérable.
| Code JavaScript : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 | const promise1 = Promise.resolve(3); const promise2 = new Promise((resolve, reject) => setTimeout(reject, 100, 'foo')); const promises = [promise1, promise2]; Promise.allSettled(promises). then((results) => results.forEach((result) => console.log(result.status))); // expected output: // "fulfilled" // "rejected" |
En 2021, 19 % du panel l'a déjà utilisé (contre 14 % en 2020) et 46,4 % du panel le connaît (contre 42,3 % en 2020).
Fonctionnalités fournies par le navigateur
Service workers : Les service workers jouent essentiellement le rôle de serveurs proxy placés entre une application web, et le navigateur ou le réseau (lorsque disponible.) Ils sont destinés (entre autres choses) à permettre la création d'expériences de navigation déconnectée efficaces, en interceptant les requêtes réseau et en effectuant des actions appropriées selon que le réseau est disponible et que des ressources mises à jour sont à disposition sur le serveur. Ils permettront aussi d'accéder aux APIs de notifications du serveur (push) et de synchronisation en arrière-plan.
Un service worker est un worker événementiel enregistré auprès d'une origine et d'un chemin. Il prend la forme d'un fichier JavaScript qui peut contrôler la page ou le site web auquel il est associé, en interceptant et en modifiant la navigation et les requêtes de ressources, et en mettant en cache les ressources selon une granularité très fine pour vous donner une maîtrise complète de la manière dont doit se comporter votre application dans certaines situations (l'une des plus évidentes étant l'indisponibilité du réseau.)
Un service worker fonctionne dans le contexte d'un worker : il n'a donc pas d'accès au DOM, et s'exécute dans une tâche différente de celle du script principal de votre application, ainsi il est non-bloquant. Il est conçu pour être totalement asynchrone ; en conséquence, des APIs telles que XHR en synchrone et localStorage ne peuvent pas être utilisées au sein d'un service worker.
Les service workers fonctionnent uniquement sur HTTPS, pour des raisons de sécurité. Laisser des requêtes réseau modifiées sans défense face aux attaques de l'homme du milieu est une bien mauvaise chose.
En 2021, 45,7 % du panel les ont déjà utilisés...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.
Envoyé par Shynryu
