Catégories
Astuces et Design

La promesse ratée des composants Web – Lea Verou

Les composants Web avaient tellement de potentiel pour permettre à HTML de faire plus, et rendre le développement Web plus accessible aux non-programmeurs et plus facile pour les programmeurs. Rappelez-vous à quel point c'était passionnant à chaque fois que nous recevions de nouveaux éléments HTML brillants qui faire des trucs? Vous vous souvenez à quel point c'était passionnant de pouvoir faire des curseurs, des sélecteurs de couleurs, des dialogues, des widgets de divulgation directement dans le HTML, sans avoir à inclure de bibliothèques de widgets?

La promesse des composants Web était que nous obtiendrions cette commodité, mais pour une gamme beaucoup plus large d'éléments HTML, développés beaucoup plus rapidement, car personne n'a besoin d'attendre le processus d'implémentation complet des spécifications +. Nous allons simplement inclure un script, et boum, nous avons plus d'éléments à notre disposition!

Ou, c'était l'idée. Quelque part en cours de route, l'espace a été inondé par les aficionados des frameworks JS, qui se délectent des API complexes, des processus de construction sur-conçus et des graphiques de dépendances qui ressemblent aux racines d'un arbre de banian.

Voici à quoi ressemblent les racines d'un banian. Photo de David Stanley sur Flickr (CC-BY).

La lecture des composants sur webcomponents.org me remplit d’anxiété, et je suis parfaitement à l’aise pour écrire JS – j’écris JS pour gagner ma vie! Quel espoir ont ceux qui ne peuvent pas écrire JS? Utiliser un élément personnalisé du répertoire doit souvent être précédé d'un rituel de bugle npm, importer des clownshoes, construire quux, le tout sans aucune excuse car «voici mon camion de dépendances, ouais, quoi». De nombreuses étapes sont même omises, probablement parce qu'elles sont «évidentes». Souvent, vous parcourez le labyrinthe pour découvrir que le composant ne fonctionne plus ou n’est pas adapté à votre objectif.

Outre la configuration, le principal problème est que HTML n'est pas traité avec le respect approprié dans la conception de ces composants. Ils ne sont pas conçus aussi étroitement que possible aux éléments HTML standard, mais attendre JS doit être écrit pour qu'ils fassent n'importe quoi. HTML est simplement traité comme un raccourci, ou pire, comme simplement un marqueur pour indiquer où l'élément va dans le DOM, avec tous les paramètres transmis via JS. Je me souviens d'une merveilleuse conférence de Jeremy Keith il y a quelques années à propos de ce phénomène même, où il a évoqué cette démo de composants Web de boutique en ligne de Google, qui est l'enfant de l'affiche de cette pratique. Voici tout le contenu de son élément:


	BOUTIQUE
	
	
	

Si c'est ainsi que Google montre la voie, comment pouvons-nous espérer que les contributeurs conçoivent des composants qui respectent les conventions HTML établies?

Jeremy a critiqué cette pratique du point de vue de la compatibilité descendante: lorsque JS est cassé ou non activé, ou que le navigateur ne prend pas en charge les composants Web, le site Web entier est vide. Bien qu'il s'agisse effectivement d'une préoccupation sérieuse, ma principale préoccupation est l'une des convivialité: HTML est une barrière inférieure à la langue d'entrée. Beaucoup plus de personnes peuvent écrire du HTML que du JS. Même pour ceux qui finissent par écrire JS, cela vient souvent après avoir passé des années à écrire du HTML et du CSS.

Si les composants sont conçus d'une manière qui nécessite JS, cela exclut des milliers de personnes de les utiliser. Et même pour ceux qui pouvez écrire JS, HTML est souvent plus facile: vous ne voyez pas beaucoup de gens rouler leurs propres curseurs ou utiliser des curseurs basés sur JS une seule fois est devenu largement soutenu, non?

Même lorsque JS est inévitable, ce n’est pas en noir et blanc. Un élément HTML bien conçu peut réduire au minimum la quantité et la complexité de JS nécessaires. Pensez au

élément: il nécessite généralement * un * JS, mais c'est généralement un JS plutôt simple. De même, le element est parfaitement utilisable simplement en écrivant du HTML et dispose d'une API JS complète pour tous ceux qui veulent faire des choses personnalisées sophistiquées.

L'autre jour, je cherchais un composant d'onglets simple et sans dépendance. Vous savez, l'exemple canonique de quelque chose de facile à faire avec les composants Web, l'exemple que 50% des tutoriels mentionnent. Je ne me souciais même pas de ce à quoi cela ressemblait, c'était pour une interface de test. Je voulais juste quelque chose de petit et qui fonctionne comme un élément HTML normal. Pourtant, cela s'est avéré si difficile que j'ai fini par écrire le mien!

Pouvons-nous résoudre ce problème?

Je ne sais pas s'il s'agit d'un problème de conception ou de documentation. Peut-être que pour bon nombre de ces composants Web, il existe des moyens plus simples de les utiliser. Il existe peut-être des composants Web vanille que je ne trouve tout simplement pas. Peut-être que je regarde au mauvais endroit et qu'il existe un autre répertoire quelque part avec des objectifs différents et un public cible différent.

Mais sinon, et si je ne suis pas le seul à avoir ce sentiment, nous avons besoin d'un répertoire de composants Web avec des critères d'inclusion stricts:

  • Brancher et utiliser. Pas de dépendances, pas de configuration au-delà d'en inclure une

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *