La création de sites Web qui fonctionnent correctement sur tous les principaux navigateurs est un principe fondamental d'un écosystème Web ouvert. Toutefois, cela implique un travail supplémentaire pour s'assurer que tout le code que vous écrivez est compatible avec chaque navigateur que vous prévoyez de cibler. Si vous souhaitez utiliser de nouvelles fonctionnalités du langage JavaScript, vous devez les transcompiler dans des formats rétrocompatibles pour les navigateurs qui ne les prennent pas en charge.
Babel est l'outil le plus utilisé pour compiler du code
contenant une syntaxe plus récente dans un code que différents navigateurs et environnements
(tels que Node) peuvent comprendre. Ce guide suppose que vous utilisez Babel. Vous
devez donc suivre les instructions de configuration pour
l'inclure dans votre application si ce n'est pas déjà fait. Sélectionnez webpack dans Build Systems si vous utilisez webpack comme bundler de modules dans votre application.
Pour utiliser Babel afin de ne transcompiler que ce qui est nécessaire à vos utilisateurs, procédez comme suit :
- Identifiez les navigateurs que vous souhaitez cibler.
- Utilisez
@babel/preset-envavec les cibles de navigateur appropriées. - Utilisez
<script type="module">pour arrêter d'envoyer du code transcompilé aux navigateurs qui n'en ont pas besoin.
Identifiez les navigateurs que vous souhaitez cibler
Avant de commencer à modifier la façon dont le code de votre application est transcompilé, vous devez identifier les navigateurs qui accèdent à votre application. Analysez les navigateurs utilisés par vos utilisateurs et ceux que vous prévoyez de cibler pour prendre une décision éclairée.
Utiliser @babel/preset-env
La transpilation de code génère généralement un fichier dont la taille est supérieure à celle de sa forme d'origine. En minimisant la quantité de compilation que vous effectuez, vous pouvez réduire la taille de vos bundles pour améliorer les performances d'une page Web.
Au lieu d'inclure des plug-ins spécifiques pour compiler de manière sélective certaines fonctionnalités de langage que vous utilisez, Babel fournit un certain nombre de préréglages qui regroupent les plug-ins. Utilisez @babel/preset-env pour n'inclure que les transformations et les polyfills nécessaires aux navigateurs que vous prévoyez de cibler.
Incluez @babel/preset-env dans le tableau presets de votre fichier de configuration Babel, .babelrc :
{
"presets": [
[
"@babel/preset-env",
{
"targets": ">0.25%"
}
]
]
}
Utilisez le champ targets pour spécifier les versions de navigateur que vous souhaitez inclure en ajoutant une requête appropriée au champ browsers. @babel/preset-env
s'intègre à browserslist, une configuration Open Source partagée entre différents outils pour cibler les navigateurs. Vous trouverez la liste complète des requêtes compatibles dans la
documentation de browserslist.
Vous pouvez également utiliser un fichier .browserslistrc pour lister les environnements
que vous souhaitez cibler.
La valeur ">0.25%" indique à Babel de n'inclure que les transformations
nécessaires pour prendre en charge les navigateurs qui représentent plus de 0,25% de l'utilisation mondiale
. Cela garantit que votre bundle ne contient pas de code transcompilé inutile pour les navigateurs utilisés par un très faible pourcentage d'utilisateurs.
Dans la plupart des cas, cette approche est préférable à l'utilisation de la configuration suivante :
"targets": "last 2 versions"
La valeur "last 2 versions" transcompile votre code pour les
deux dernières versions de chaque navigateur,
ce qui signifie que la prise en charge est fournie pour les navigateurs abandonnés tels qu'Internet Explorer.
Cela peut augmenter inutilement la taille de votre bundle si vous ne vous attendez pas à ce que ces navigateurs soient utilisés pour accéder à votre application.
En fin de compte, vous devez sélectionner la combinaison de requêtes appropriée pour ne cibler que les navigateurs qui répondent à vos besoins.
Activer les corrections de bugs modernes
@babel/preset-env regroupe plusieurs fonctionnalités de syntaxe JavaScript dans des collections, puis les active et les désactive en fonction des navigateurs cibles spécifiés. Bien que cela fonctionne correctement, une collection entière de fonctionnalités de syntaxe est transformée lorsqu'un navigateur ciblé contient un bug avec une seule fonctionnalité.
Cela génère souvent plus de code transformé que nécessaire.
Développée à l'origine comme préréglage distinct, l'
option de correction de bugs dans @babel/preset-env
résout ce problème en convertissant la syntaxe moderne qui est défectueuse dans certains navigateurs en syntaxe équivalente la plus proche qui n'est pas défectueuse dans ces navigateurs. Le résultat est un code moderne presque identique avec quelques petites modifications de syntaxe qui garantissent la compatibilité dans tous les navigateurs cibles. Pour utiliser cette
optimisation, assurez-vous que la version 7.10 ou ultérieure de @babel/preset-env est installée, puis définissez la
bugfixes propriété sur true :
{
"presets": [
[
"@babel/preset-env",
{
"bugfixes": true
}
]
]
}
Dans Babel 8, l'option bugfixes sera activée par défaut.
Utiliser <script type="module">
Les modules JavaScript, ou modules ES, sont une fonctionnalité relativement récente compatible avec
tous les principaux navigateurs. Vous pouvez utiliser des modules pour créer des scripts qui peuvent importer et exporter à partir d'autres modules, mais vous pouvez également les utiliser avec @babel/preset-env pour ne cibler que les navigateurs qui les prennent en charge.
Au lieu d'interroger des versions de navigateur ou des parts de marché spécifiques, envisagez
de spécifier "esmodules" : true dans le champ targets de votre fichier .babelrc.
{
"presets":[
[
"@babel/preset-env",
{
"targets":{
"esmodules": true
}
}
]
]
}
De nombreuses fonctionnalités ECMAScript plus récentes compilées avec Babel sont déjà compatibles avec les environnements qui prennent en charge les modules JavaScript. Ainsi, vous simplifiez le processus qui consiste à vous assurer que seul le code transcompilé est utilisé pour les navigateurs qui en ont réellement besoin.
Les navigateurs compatibles avec les modules ignorent les scripts avec un attribut nomodule.
À l'inverse, les navigateurs qui ne sont pas compatibles avec les modules ignorent les éléments de script avec
type="module". Cela signifie que vous pouvez inclure un module ainsi qu'un remplacement compilé.
Idéalement, les deux scripts de version d'une application sont inclus comme suit :
<script type="module" src="main.mjs"></script>
<script nomodule src="compiled.js" defer></script>
Les navigateurs compatibles avec les modules récupèrent et exécutent main.mjs, puis ignorent compiled.js. Les navigateurs qui ne sont pas compatibles avec les modules font le contraire.
Si vous utilisez webpack, vous pouvez définir différentes cibles dans vos configurations pour deux versions distinctes de votre application :
- Une version uniquement pour les navigateurs compatibles avec les modules.
- Une version qui inclut un script compilé fonctionnant dans n'importe quel ancien navigateur. La taille du fichier est plus importante, car la transpilation doit être compatible avec un plus grand nombre de navigateurs.
Merci à Connor Clark et Jason Miller pour leurs commentaires.