Intro

Le web n'a jamais été aussi chouette que depuis que IE 6 est officiellement mort pour toujours.

Mais du coup... On en veut encore plus maintenant.

Faut avouer que moins de 2.8% c'est pas beaucoup de pourcents

Il semblerait qu'un grand nombre de sites (ça s'appelle des APPS maintenant, joie) ait commencé à officiellement ne plus supporter Internet Explorer 11 (abbrévié affectueusement ci-après IE 11 comme les jeunes disent). Même que carrément le présent site qui est écrit en ES5 sans transpilonnage pour des raisons non-exclusivement neurotiques (je l'ai déjà faite celle-là non?), he ben... Il est un peu foireux sur IE 11.

Bon c'est pas tout à fait ma faute, c'est MaterializeCSS qui a laché le support IE 11 et le projet de me passer totalement de framework CSS sera pour plus tard parce que j'ai des millions d'autres projets et ça commence à faire comme si j'avais 30 onglets ouverts dans mon cerveau (qui ressemble sûrement davantage à la version Wii d'Opera qu'à IE 11 d'ailleurs (???)).

La question qu'on se pose aujourd'hui: Est-ce qu'il reste une bonne raison d'essayer d'avoir un support IE 11?

La réponse pourrait vous étonner. Promis que c'est vrai.

Petite histoire inutile

Je passe ma vie sur caniuse.com et la base de connaissance Mozilla pour voir quel navigateur supporte tel ou tel truc.

Récemment je découvrais qu'il était possible d'utiliser addEventListener avec une option once, qui a pour effet d'ajouter un listener normalement, mais en le retirant automatiquement la première fois qu'il est appelé.

En quoi c'est intéressant ce truc? Admettons que vous vouliez fermer un menu mobile qui apparaît supperposé à votre site avec un clic en dehors du menu.

Il va nous falloir un Event Listener de clic sur un élément accessible en dehors du menu (un overlay ou bien carrément body) ; une fois qu'il est appelé on ferme le menu.

Cet Event Listener n'est plus nécessaire du tout une fois que le menu est fermé. Ici on pourrait le déclencher une fois, puis le rajouter à chaque ouverture du menu.

Bon OK, cet exemple est probablement tout pourri. Mais pour les évènements liés aux tags Audio ça m'aurait été bien utile de n'appeler l'évènement de quand l'audio est disponible une seule fois (parce qu'il est appelé à nouveau chaque fois que l'audio est mis en pause).

Je vérifie immédiatement sur caniuse.com, et surprise, ce truc n'est pas supporté par IE 11 (en fait c'était pas du tout une surprise mais je dramatise pour rendre plus intéressant).

Je m'égare, au départ c'était censé être une brève cet article puis c'est un peu parti en baton de berger.

Qu'est-ce qui manque sur IE 11?

• Fetch. Il suffit d'utiliser Axios ou un polyfill foireux. Je vous laisse deviner lequel je préconise ;
• CSS Grid. En pratique c'est un petit peu supporté en utilisant le préfixe -ms, et euh... Il y a certaines choses qui ne fonctionnent pas (je n'ai pas vraiment étudié la question scusez moi). Je parle de CSS grid plus loin normalement ;
• Anecdote cocasse: il semblerait que ça soit Microsoft qui ait inventé CSS Grid en fait, et pas l'équipe Mozilla dont un des membres passe ses journées à parler de CSS grid non-stop pour toujours, et qu'il a fallu attendre Edge pour avoir un support CSS Grid complet de la part de Microsoft.
• La norme ES6 de JavaScript, en entier ;
• Quelques trucs JavaScript utiles mais pas [vraiment] indispensables (les gens seront pas tous d'accord avec moi je pense) ;
• Pas de promesses (window.Promise) ;
• Pas de web components (LOL tout le monde s'en fout).

La vraie motivation de support de IE 11

Si vous avez l'habitude de faire entièrement confiance aux paramètres Babel de votre framework préféré, vous ignorez peut-être que IE 11 ne supporte aucunes des nouveautés d'ES6, promesses comprises.

Même pour utiliser certains trucs pas très très modernes (comme les promesses, quoi), il vous faut non seulement compiler votre JavaScript en ES5, mais il faut aussi sans doute, si vous voulez bien excuser mon langage d'ordinaire si chaste, une chiée de polyfills, sans compter tous les problèmes possibles de présentation dûs au support semi-foireux de Flexbox, mais ça c'est une autre histoire puis les utilisateurs IE 11 doivent être habitués à voir des choses étranges de toutes manières.

Je parle depuis IE 11 depuis bien trop de lignes, mon but était d'évoquer un autre navigateur qui ne supporte que très partiellement ES6 (pas de fonctions fléchées par exemple) et dont le support par votre site est extrêmement important: le ROBOT GOOGLE.

Il utilise en effet le moteur de rendu d'une version de Chrome de 2015 (Chrome 41).

2015 ça vous paraît peut être récent, mais n'oublions pas qu'on parle d'années de l'ère JavaScript post-décès d'Internet Explorer 6 (en 2014 seulement!) en concordance avec une perte vertigineuse de parts de marché de toutes les versions d'IE au profit de Chrome et Firefox. C'est un peu comme débrider une mobilette mais avec un moteur de tracteur nucléaire.

Je viens de vérifier avec create-react-app et la config Babel par défaut consiste à explicitement ne pas tenter de supporter IE 11 mais la compilation finale implique tout de même de retirer toutes les traces d'ES6. Même pas de let ou const.

Selon moi c'est principalement pour le robot Google qu'on se tape une syntaxe qui sent le moisi et pourrait dans certains cas augmenter significativement la taille du code final.

A trois versions prêt c'était bon...

Ce que je me dis moi tout seul dans mon coin, c'est que s'il faut supporter ce vieux Chrome 41, autant aussi supporter IE 11. Surtout si vous aviez l'intention de nier les Promises.

Je veux dire quite à devoir boire de la bière dégeu, autant qu'elle aussi soit chaude et périmée. C'est peut-être juste moi qui suis amateur de l'extrême. Je vous épate, hein.

A savoir que le lazy loading dans Webpack ("dynamic imports") utilise des promesses.

Vous pouvez toujours les Polyfill en détectant si les promesses sont disponibles avec Modernizr (ou on vérifiant si window.Promise est undefined). En même temps je pourrais tout autant vous dire, vous pouvez toujours utiliser jQuery aussi. Ou un porte-manteau rouillé enduit de beurre.

Le vieux GoogleBot

Merci BEAUCOUP Google, d'avoir de l'argent infini et de la bouffe gratuite qui finance d'énormes équipes de développeurs d'élite qui jouent avec des costumes de tête de cheval et créent des vidéos non-listées où on comprends pas tout à fait la blague et poussent le futur de la plateforme Web avec force et vigueur.

Sauf qu'à côté de ça, Gmail est toujours un peu pourri en terme de performances, n'utilise ni Polymer ni Angular (d'ailleurs pourquoi vous n'utilisez jamais Angular, hein M. Mme Google? Pourquoi? - Non dites rien en fait je sais pourquoi je suis très intelligent) et traine des vieux machins comme le robot Google et son moteur de rendu qui a la même odeur que le sachet de dragées de votre baptèmes retrouvé dans un vieux sac sous le rack d'affinage de votre Munster à la cave.

J'ai trouvé ce Tweet dans un article. Cool, hein.

Je me trompe peut-être, mais selon moi la raison pour laquelle tout le monde transpile en ES5 (enfin sauf moi parfois mais je conseille pas), c'est uniquement à cause du Google Bot. Parce que tout le monde s'en bat le slip de IE 11.

Est-ce qu'ils ont l'intention de mettre à jour le moteur de rendu du robot? Oui. Enfin je crois. Il paraît que c'est compliqué à faire, ce qui est tout à fait plausible pour une boite qui emploie des miliers de développeurs parmis les meilleurs et les nourris gratuitement (rappelons-le, hein).

Si cet article n'est plus d'actualité dans un mois je serai super content.

Conséquences sur les FRAMEWORKS

C'est la merde. Pour bien faire il faudrait sortir deux cibles de compilation: une ES5 pour Google Bot (et IE 11 :D) et une soit totalement non compilée (donc un truc du futur) soit pseudo-transpilée pour retirer certains éléments de langage encore moyennement supportés.

Mention spéciale à React qui utilise des trucs qui ne sont pas du tout supportés du tout par personne comme le spread operator sur un objet ou les fonctions fléchées comme membre de classes. Là il faut obligatoirement passer par Babel de toutes façons.

L'approche multi-cibles est utilisée par Polymer. Pour React, on compile en une seule cible ES5 et c'est tout bonsoir.

Voici leur config Babel:

"browserslist": [
    ">0.2%",
    "not dead",
    "not ie <= 11",
    "not op_mini all"
  ]

Donc euh... NOT DEAD, et euh... On balance IE 11 et inférieurs. Okay.

Qu'est-ce qu'on ferait-y pas sans Babel, hein, mes amis?

Moi j'utilise ça quand je peux, je le mets parce que c'est très très drôle et lié au titre de l'article:

"targets": {
  "browsers": [
    "ie 11"
  ]
}

Au moins c'est un peu plus clair je trouve. Je me passe du NOT DEAD. Si vous n'utilisez pas de polyfills, pour moi c'est exactement la même chose.

Avoir deux cibles de compilation n'est pas aussi simple que de juste coller Babel avec un joli preset, que l'on comprenne le preset ou pas.

Effectivement, Chrome 41 ne supporte pas tout un tas d'autres trucs dont les Web Components (LOL), ce qui implique d'ajouter quelques polyfills. Si on veut supporter IE 11 et n'utiliser que deux cibles de compilation et pas une spéciale pour les navigateurs des enfers, il faudra ajouter la coulée de polyfills pour utilisation par Chrome 41 aussi.

Je ne sais pas si vous avez déjà utilisé babel-polyfill mais ça peut représenter plus de 200Kb de de JavaScript en plus.

Pour Polymer 3, ils parlent de support IE 11 et Chrome 41 avec polyfills et compilation ES5, mais ils ne vous disent pas à quel point ça devient moche et gras et gros et sale et brun dans ces cas-là.

Conclusion: avoir deux cibles de compilation c'est bien mais s'il faut des polyfills en plus, la cible ES5 peut vite devenir vraiment très moche.

Si vous utilisez React tranquilou vous pourriez être concernés aussi si vous utilisez des éléments de langage qui ne sont pas supportés par Chrome 41. Babel ne vous préviendra pas si c'est le cas.

Quelque soit la solution utilisée je pense qu'il est très indiqué de vérifier au moins l'apparence générale de vos applications et sites depuis les outils de Google (le mobile et le pas mobile) - On y vient très vite.

Inspecter la purée que voit le GoogleBot

A savoir déjà, il y a deux GoogleBots: un qui se fait passer pour un mobile et un qui se fait passer pour un ordi de bureau (un **PéCé**).

Il existe un outil appelé la Google Search Console qui est quelque part dans leurs Developper tools ou la Google Marketing Platform, je sais pas trop où on en est.

Ils ont récemment sorti de nouvelles versions de ces sites (y compris Google Analytics) en material design assez sympa. Sauf que tout a changé de place et que je trouve même plus où on peut utiliser la fonction "Voir comme le robot Google", du coup j'utiliser la vieille interface moisie.

EPIC WeB DEsIGN

Vous devez vérifier la propriété de votre site et l'associer à votre compte Google pour pouvoir utiliser cet outil. L'outil mobile n'a pas cette restriction (que je sache?).

De plus, l'outil mobile est plus complet puisqu'on peut carrément inspecter le DOM de la page demandée.

Vous trouverez l'outil mobile ici: https://search.google.com/test/mobile-friendly

Récemment j'ai lancé une app entièrement en ES6 (sauf certains trucs comme les string literals) et il a look intéressant sur Fetch-as-Google:

Rien d'anormal ici

Le plan server-side rendering

Je ne sais pas si quelqu'un se souviens de comment on faisait un site web à l'époque de PHP NUKE.

Sans JavaScript. Ou alors éventuellement pour afficher un bidule pour sélectionner une date.

Il est possible de détecter les User Agent utilisés par les deux robots Google et leur envoyer une version de vos pages où le JavaScript qui était supposé charger du contenu supplémentaire n'est plus nécessaire (parce qu'on a déjà ajouté ce qu'il était censé ajouter - J'explique, hein).

C'est de base quelque chose d'intéressant à implémenter, parce que les robots des réseaux sociaux n'interprêtent pas du tout le JavaScript. Eux ils sont encore loin de Chrome 41.

Je parle dans cet aricle d'une solution que j'utilise pour leur servir un contenu différent de sorte qu'ils repèrent mes tags de réseau sociaux. Ceci dit, je prends bien soin de ne pas cibler les robots de Google avec cet artifice.

Pourquoi pas? Déjà le résultat est une infâme page dégeulasse et je place certains espoirs dans l'idée que Google utilise des techniques d'analyse pour tenter de deviner si un site est plus ou moins agréable à regarder ou juste entièrement en Comic Sans sur fond fusch.. Fuch.. FUschia (on en parle plus loin).

D'autres vous diront qu'il est surtout important de respecter leur règle de bonne conduite qui consiste à ne jamais servir quelque chose de différent au robot Google en détectant son User Agent.

Mmmh... Ce n'est pas un problème si nous produisons de toutes manières une version ES5 de l'application, et il est possible de faire une réconcilation sauvage entre server-side rendering et une application JavaScript simple-page un peu à la manière de NextJS: Fournir une version "préremplie" d'une page quand elle est demandée directement, sinon utiliser le routage JavaScript pour tout faire.

Dans ce cas, le robot Google et les robots des media sociaux reçoivent une page pré-rendue. Ce qui n'empêche pas qu'il puisse rester du JavaScript incompréhensible pour le robot sur la page.

Est-ce que ça pourrait poser problème? Une erreur JavaScript peut dans certains cas interrompre le rendu ou créer une boucle infinie. Et là je dirais que c'est un problème.

Le plan B consiste dès lors à créer un rendu total de vos pages en retirant tout le JavaScript et servir ce plat uniquement au robot Google (et aux robots sociaux aussi, tant qu'on y est). Du coup il n'a plus de JavaScript a exécuter du tout.

Mais attend... C'est pas contraire à leurs bonnes pratiques ça? Effectivement. Cela dit il semblerait qu'ils aient annoncé que c'était désormais considéré comme "pas trop grave" (lol) dans cette vidéo:

A savoir que le robot mobile s'attend à voir une vraie version mobile, pas un truc moche. Si vous utilisez de toutes façons des media queries pour tout ça, tout va bien. Qui n'utilise pas de media queries? Ceux qui veulent supporter IE<9, ce qui est encore un tout autre combat et là je ne peux que tirer tous mes chapeaux et participerais volontiers à leurs frais médicaux de santé mentale.

Pour réaliser le genre de server-side rendering évoqué dans la vidéo, le plus évident serait de tout faire en JavaScript, mais c'est un piège! Vous n'êtes pas obligés.

Avec des templates un peu standards et une app pas trop compliquée, c'est possible de réutiliser les mêmes templates pour créer ce que le JavaScript aurait affiché chez le client final.

La "solution" qu'ils évoquent dans leur vidéo est la plus... Simple je suppose? C'est aussi la plus "Wow, sériously?".

J'explique: On se tape Chrome partout et en plusieurs copies actives en même temps sur nos ordis, à cause des clients "natifs" (HAHA) de Discord, Slack et autres Skype, et également avec Spotify et un bon nombre de clients pour lanceurs de jeux vidéo. Alors, je vous le demande, pourquoi pas aussi mettre Chrome côté serveur? Chrome PARTOUT! Qu'est-ce que ça pourrait faire de mal? Un énorme programme qui fait 70 MB en compilé optimisé à utiliser absolument partout pour faire n'importe quoi? OU EST-CE QU'ON SIGNE???

Dans l'éconsystème NodeJS il existe un nombre relativement inquiétant de "headless browsers" ou simplement de scripts qui exécutent un navigateur sans l'afficher à l'écran, mais peuvent réaliser des opérations sur le DOM, prendre des screenshots (parfois), etc.

Le super plan que nous propose Google pour passer outre le moteur de rendu de leur robot tout moisi, c'est d'utiliser Chrome pour créer entièrement les rendus de page, et envoyer ça au client (il faut tout faire en JavaScript ici, par contre). Joie.

Je rigole (non en fait je rigole nerveusement de tristesse nerveuse) mais j'ai l'intention de mettre en place ce type de rendu pour exercice, et aussi parce que ça peut servir pour les tests et je suis très connu pour penser toujours en premier aux tests quand je développe quelque chose (**LE DETECTEUR DE SARCASME S'AFFOLE**).

Etant donné que c'est Google qui réalise la vidéo, ils nous parlent de leur version de Chrome "headless", puppeteer.

Je n'ai rien d'autre à dire à part bonne chance.

Est-ce que c'est vraiment grave si le robot Google voit un truc moche?

Personne ne sait. L'algorithme règne.

Ce serait logique qu'il y ait une certaine vérification pseudo-esthétique. Peut-être uniquement liée à la manière dont les données sont disposées, les tags utilisés, la norme HTML, etc.

Dans cet article et sous le titre "Issues related to viewports", l'auteur évoque un problème d'affichage sur le rendu du robot Google qui fait qu'un morceau du text n'est pas visible. Il dit (je traduis):

Autant que je sache, ça n'a aucun effet sur l'indexation.
Cependant, la question est: est-ce que ça affecte le classement? Ou est-ce que ça affecte uniquement la façon dont l'outil Fetch and Render voit le contenu? Pour le moment, je n'ai pas la réponse exacte.

J'aime beaucoup cet article qui, dans les grandes lignes, explique que le robot Google est tout à fait en mesure de lire une page qui utilise CSS grid même s'il ne capte rien à CSS grid. Ce serait-y pas comme dire que le robot est en mesure de lire mon site moche en times new roman couleur DEEPPINk, le tout dans un tableau qui est dans une balise marquee?

Ce serait-y pas aussi comme dire "oui le robot peut lire le text même si on place normalement une énorme photo de slip en jute en avant plan en utilisant un artifice JavaScript que Chrome 41 n'exécutera pas" ?

Est-ce que vous voyez où je veux en venir? Parce que moi je sais plus trop. Mais je vais me retenir d'utiliser CSS Grid pour tout ce qui doit être indexé.

Conclusion

Ce qui est le plus problématique, ce n'est pas Internet Explorer 11, mais les GoogleBots et leur moteur de rendu préhistorique qui nous oblige à passer par Babel si on veut écrire du code au moins un petit peu moderne.

Cependant, je ne peux pas sérieusement recommander d'essayer activement d'avoir l'air digne sur IE 11. On parle de 2.5% d'Internet qui sont probablement déjà au courant de leur situation de souffrance et/ou (plutôt et que ou) précarité extrême.

Il faut bien avouer qu'avec le plan rendu-complet-sans-JavaScript que même Google propose d'utiliser, il suffit de mettre les User Agent de IE 11 dans la détection et vous l'avez votre support IE 11.

Je me limiterais à créer deux cibles de compilation: ES5 pour Chrome 41, avec le moins possible de polyfills et ES6 pour tout le reste. La question sera davantage comment intelligemment router de l'un vers l'autre. Un sujet pour une prochaine fois.