Chaque semaine, un nouveau générateur d'ID, un polyfill de base64 ou une mini-lib d'itérateurs paresseux atterrit dans ton package.json. Deux ajouts récents à JavaScript rendent une partie de ces dépendances inutiles : les iterator helpers, désormais disponibles partout depuis 2025, et les méthodes natives base64/hex sur Uint8Array, arrivées juste après.

Ce ne sont pas des nouveautés exotiques réservées à un futur lointain : les deux sont marquées Baseline (disponibles nativement dans Chrome, Firefox et Safari en même temps, sans flag) et supportées par Node.js récent, Deno et Bun. Autrement dit, tu peux les utiliser en production dès aujourd'hui sur la plupart des projets.

Voici ce qu'elles changent concrètement, avec du code, et jusqu'où tu peux réellement te passer de tes dépendances actuelles.

Le problème que ces deux API viennent résoudre

JavaScript a longtemps eu deux angles morts frustrants. D'abord, les itérateurs et générateurs (function*) n'avaient aucune méthode de confort : pas de .map(), pas de .filter(), rien. Pour chaîner des transformations, il fallait soit tout convertir en tableau avec [...iterateur] (ce qui charge tout en mémoire, y compris sur une séquence infinie), soit importer une librairie comme itertools ou réécrire sa propre boucle à la main.

Ensuite, encoder des octets en base64 était un vieux piège : btoa() et atob() datent du web des années 2000, ne comprennent pas l'UTF-8 et plantent dès qu'un caractère accentué ou un emoji traîne dans la chaîne. Résultat : tout le monde finissait par installer js-base64 ou par bricoler un passage par Buffer côté Node, avec un comportement différent côté navigateur.

Iterator helpers : chaîner des générateurs sans tout charger en mémoire

Depuis leur passage en Baseline "Newly available" fin mars 2025, tout objet qui implémente le protocole d'itération hérite de méthodes directement utilisables : map, filter, take, drop, flatMap, reduce, forEach, some, every, find et toArray. Elles se comportent comme leurs équivalents sur Array, à un détail près qui change tout : elles sont paresseuses.

Chaque valeur traverse toute la chaîne une par une, sans tableau intermédiaire créé à chaque étape. Ça permet, entre autres, de travailler avec des séquences infinies sans jamais faire exploser la mémoire :

function* entiers() {
  let n = 0;
  while (true) yield n++;
}

// Rien n'est calculé tant que .toArray() n'est pas appelé :
// la boucle s'arrête dès que .take(5) est satisfait.
const resultat = entiers()
  .filter(n => n % 2 === 0)
  .map(n => n * n)
  .take(5)
  .toArray();

console.log(resultat); // [0, 4, 16, 36, 64]

Ça marche aussi sur un tableau classique, en appelant .values() pour récupérer son itérateur :

const pairsAuCarre = [1, 2, 3, 4, 5, 6, 7, 8]
  .values()
  .filter(n => n % 2 === 0)
  .map(n => n * n)
  .toArray();

L'intérêt pratique dépasse le style : sur un flux de données volumineux (lignes d'un fichier de logs, résultats d'une requête paginée déjà chargés en mémoire génération par génération, événements d'un flux), tu peux arrêter le traitement dès la première correspondance sans tout parcourir :

function* lignes(texte) {
  yield* texte.split('\n');
}

// find() court-circuite la boucle dès qu'une ligne correspond,
// sans avoir à filtrer puis chercher dans deux passes séparées.
const premiereErreurTimeout = lignes(logVolumineux)
  .filter(l => l.includes('ERROR'))
  .find(l => l.includes('timeout'));

Autre ajout arrivé cette année : Iterator.prototype.concat(), qui enchaîne plusieurs itérateurs à la suite sans matérialiser leurs valeurs dans des tableaux intermédiaires — pratique pour fusionner plusieurs sources de données paresseuses en une seule chaîne.

Où c'est disponible

Les iterator helpers tournent nativement dans les versions actuelles de Chrome, Firefox et Safari, ainsi que dans Node.js, Deno et Bun. Si tu dois encore couvrir de vieux navigateurs, un polyfill existe via core-js, mais sur un projet ciblant des runtimes récents (backend Node, extension, app Electron, PWA moderne), tu peux les utiliser directement.

Une limite à garder en tête : ces méthodes s'appliquent aux itérateurs synchrones. Un générateur asynchrone (async function*) ou un flux basé sur des promesses ne les hérite pas automatiquement de la même façon — vérifie le support de l'API avant de l'appliquer telle quelle à du code qui fait des appels réseau page par page.

Uint8Array.toBase64() / fromBase64() : la fin du bricolage atob/btoa

Uint8Array embarque désormais nativement toBase64(), fromBase64(), toHex(), fromHex(), ainsi que les variantes setFromBase64() et setFromHex() qui écrivent directement dans un buffer existant sans en allouer un nouveau. Ces méthodes ont atteint le statut Baseline en septembre 2025 et sont disponibles dans Chrome, Firefox, Safari et Node.js 22+.

Contrairement à btoa()/atob(), elles travaillent directement sur des octets et gèrent nativement l'UTF-8 dès lors que tu passes par TextEncoder/TextDecoder :

// Avant : btoa('Café ☕') lève une exception (caractères hors Latin1).
// Maintenant : on encode en octets d'abord, puis en base64.
const octets = new TextEncoder().encode('Café ☕');

const base64 = octets.toBase64();
// 'Q2Fmw6kg4piV'

const octetsDecodes = Uint8Array.fromBase64(base64);
console.log(new TextDecoder().decode(octetsDecodes)); // 'Café ☕'

Deux options utiles à connaître, passées en objet :

alphabet : 'base64' (par défaut) ou 'base64url', pour générer directement une chaîne utilisable dans une URL ou un JWT sans post-traitement.
lastChunkHandling (pour fromBase64) : contrôle comment gérer un padding incomplet en fin de chaîne ('loose', 'strict' ou 'stop-before-partial'), utile quand tu parses un flux base64 reçu par morceaux.

const tokenUrlSafe = octets.toBase64({ alphabet: 'base64url' });

const hex = octets.toHex();
const depuisHex = Uint8Array.fromHex(hex);

Côté Node.js, ça ne remplace pas Buffer — toujours très utilisé et optimisé pour l'écosystème serveur — mais ça donne enfin une API commune entre navigateur et serveur pour ce genre de conversion, sans avoir à écrire deux chemins de code différents selon l'environnement d'exécution. Et pour un script partagé entre un Worker, une Edge Function et le navigateur, c'est justement ce genre de petite divergence qui fait gagner du temps de debug.

Un exemple concret : décoder un fichier reçu en base64 sans dépendance

Cas courant : une API renvoie une pièce jointe encodée en base64, et tu veux la reconstituer en Blob téléchargeable côté navigateur. Avant, ça passait presque toujours par une librairie ou un bricolage avec atob + boucle de conversion caractère par caractère :

async function telechargerPieceJointe(base64, typeMime, nomFichier) {
  const octets = Uint8Array.fromBase64(base64);
  const blob = new Blob([octets], { type: typeMime });

  const lien = document.createElement('a');
  lien.href = URL.createObjectURL(blob);
  lien.download = nomFichier;
  lien.click();
  URL.revokeObjectURL(lien.href);
}

Zéro dépendance, zéro conversion manuelle octet par octet, et un comportement identique entre navigateur et Node.js.

Faut-il retirer tes dépendances dès maintenant ?

Pas systématiquement, et certainement pas d'un coup. Avant de remplacer quoi que ce soit dans un projet existant, vérifie trois choses :

Les cibles de ton projet. Si tu dois supporter des navigateurs plus anciens que ceux couverts par Baseline, garde le polyfill ou la lib pour l'instant — ou charge-le conditionnellement.
Ce que fait vraiment ta dépendance. Une lib comme lodash ou RxJS fait souvent bien plus que du simple chaînage paresseux (opérateurs de flux, gestion d'erreurs, scheduling) : les iterator helpers ne remplacent que la partie "chaîner des transformations sur une séquence", pas un vrai framework réactif.
La taille réelle du gain. Retirer js-base64 (quelques ko) sur un projet qui charge déjà 300 ko de JS n'a pas le même impact que sur une extension navigateur ou un module edge où chaque kilo-octet compte.

En revanche, pour du code neuf ciblant des runtimes récents, il n'y a plus vraiment de raison d'installer une dépendance pour du base64 ou pour chaîner des générateurs : c'est maintenant dans le langage, sans configuration, sans bundle supplémentaire. La prochaine fois que tu tapes npm install par réflexe pour l'une de ces deux tâches, vérifie d'abord si l'API native suffit déjà — il y a de bonnes chances que oui.

Adieu lodash et atob : 2 API JS natives à adopter maintenant