Librairie Almost Vanilla Javascript

L’origine ( utilitaires.js )

Il était parti à l’origine de l’idée de remettre au goût du jour et assez au propre pour la diffuser une grosse librairie de fonctions utilitaires rédigée au fil de mes projets, datant pour la plupart de la première moitié des années 2010 (dont on peut encore retrouver une petite partie, utilisée sur ma page personnelle). Fonctions visant surtout à faciliter la génération de blocs de HTML tels que des menus ou tableaux en Javascript  (si on trouvait un peu de tout dans ce fichier utilitaires.js).

J’utilisais en effet beaucoup des architectures du style page unique, dont tous les changements étaient gérés en Js. Et la forme la plus « vanilla »Pure. Se dit d'un langage informatique utilisé tel quel, sans l'enrichir de dépendances, librairies déjà existantes ou frameworks. de ce langage, ce qui rendait un peu fastidieux de produire tout élément html un peu complexe. Si je connaissais un peu JQuery, le framework le plus populaireReact devait venir de sortir sa toute première version, Angular et Vue n'existaient pas encore sauf erreur de ma part, les principales autres options devaient être Spry, un machin au code plutôt horrible développé par Adobe et déjà en voie d'abandon, Backbone, bien plus élégant mais pas évident à utiliser, et le déjà passé de mode Dojo. Quant au Js pur, il avait (et a toujours) quelques raisons objectives d'être préféré à l'usage de frameworks comme d'être de 1,5 à une dizaine de fois plus rapide à s'exécuter typiquement, et d'avoir évidemment la plus large documentation. de l’époque, je n’aimais pas utiliser quelque chose d’aussi lourd dans mes projets, me faisant préférer les plus longues formulations du Js standard -« document.getElementById« , etc.- à ce qu’il avait déjà remplacé par des raccourcis comme « $ », ce qui rendait d’autant plus impératif pour la survie de mon clavier, que j’en développe d’autres.

J’en étais donc arrivé à des fonctions comme : 

Ici pour générer le code html d’un menu de type select appelant une fonction quand l’utilisateur interagit avec lui, et pouvant avoir une infobulleAu HTML généré par une autre fonction, genHelpText, que je ne détaillerai pas ici, et qui nécessitait aussi d'inclure le nécessaire à ces tooltips dans le css des pages l'utilisant. expliquant la question posée, en ayant juste besoin de renseigner les paramètres nécessaires.

Le tout à l’époque mélangé avec toutes sortes d’autres fonctions diverses (dont certaines largement obsolètes, comme la forme d’AjaxExploitation en Javascript de sources de données, comme les APIs de bases de données, ou des fichiers xml ou json. que j’utilisais à l’époque, non basée sur les promesses, et d’autres, sur les tirages pseudo aléatoires par exemple, qui auraient plus eu leur place dans une librairie spécifiquement destinée au jeu.

Extensions du domaine de la librairie

Au moment de remettre mes utilitaires au gout du jour (presque une décennie s’étant écoulée entre temps), j’ai donc commencé par trier tout ça, et en éliminer tout ce qui n’était pas de la génération de HTML (que ce soit à jeter ou diffuser séparément). Puis je me suis dit, tant qu’à avoir une librairie destinée à en produire, autant que ses fonctions aboutissent carrément à faire apparaitre ce HTML plutôt qu’à juste le générer (qu’elles prennent le container HTML, une div par exemple, qu’elles serviront à renseigner en paramètre et le remplissent elles mêmes).  Et rapidement à, pourquoi pas, permettre à ma librairie de générer ce container lui même à la volée (en lui attribuant automatiquement un id permettant  d’interagir avec lui, et en retournant cet id à la création de l’élément).

J’en suis donc venu à des fonctions de génération automatique d’id. Puis, que l’utilisateur n’ait pas à s’embêter à systématiquement stocker les id retournés dans une table, et à lui permettre d’accéder aux éléments correspondants d’autant de manières que possible (et aussi à développer une fonction permettant d’inclure ceux du DOM en provenance du fichier HTML utilisé à cette liste, si l’utilisateur le souhaitait).

Le charme d’un langage non-typé

Petite parenthèse sur une petite motivation annexe que je pouvais avoir en développant cette librairie. Alors que j’étais en formation avec des gens d’une génération n’ayant jamais utilisé de javascript « vanilla » (uniquement du javascript enrichi de frameworks qui s’apprend de nos jours, et encore plus souvent du Typescript), qui dénigraient souvent ce langage pour être non typé, je pouvais avoir aussi objectif d’illustrer que ça peut être vu comme un de ses grands atouts plutôt qu’un inconvénient. C’est ce qui doit aussi expliquer le choix du nom que j’ai fini par lui donner, Almost Vanilla Javascript (ou AVJS), c’est à dire du Javascript presque pur (si elle allait de plus en plus largement diverger de celui ci).

Il y a en effet pas mal de choses bien plus pratiques à faire en exploitant le non typage des données. Imaginons par exemple que vous ayez un tableau (array, ou autre objet d’ailleurs), contenant disons le profil d’un utilisateur, qui puisse soit être déjà renseigné, soit avoir à l’être depuis un formulaire (si il crée son compte), soit avoir à être récupéré depuis une base de données (il s’est enregistré). Dans la plupart des langages vous aurez à utiliser une variable d’état séparée pour savoir dans quel cas de figure on se trouve. En Javascript vous pouvez juste initialiser la variable associée à ce tableau avec une valeur numérique par exemple (par un exemple un 0 signifiant le tableau n’est pas chargé et je ne sais pas non plus comment il doit être renseigné), qui variera selon ce que fait l’utilisateur (1 = il crée un compte, 2 = il s’est enregistré par exemple et enfin, une fois le tableau renseigné d’une des deux manières, remplacer la variable par celui ci). Puis, au moment où vous voudriez utiliser le tableau (pour l’afficher par exemple), vous n’avez plus qu’à utiliser un switch (0-> lui proposer de créer un compte ou s’enregistrer, 1 -> lui proposer d’accéder au formulaire permettant de le remplir et enregistrer, 2-> aller chercher ces infos dans la base de données, avec enfin comme default-> afficher les données du tableau).

Ce n’est pas forcement un excellent exemple, car il n’y a rien de terriblement lourd à avoir une variable d’état séparée pour un seul utilisateur, mais dans des cas où il y aurait beaucoup de variables pouvant avoir de multiples méthodes de renseignement et états le plus facilement représentés par des variables de types différents, c’est un petit truc très pratique (qui évite de multiplier des variables devenant inutiles une fois que l’objet est sous sa forme finale -ici le tableau disponible). Ce que permet le non-typage c’est quelque part ce que promettent les ordinateurs quantiques : pouvoir traiter des variables ne se résumant pas à un 0 ou 1 à la question « a été renseignée avec le type de données attendu ? » mais pouvant être des espèces de chats de Shrödinger qu’on passera à des méthodes sans en connaître l’état et le type qui en découle, qui n’ouvriront leur boîte qu’au moment voulu.

Toujours est-il, en développant ce qui allait devenir AVJS, j’avais décidé d’exploiter autant que possible les possibilités qu’un langage non typé offre. Par exemple de faire en sorte que toutes mes fonctions permettant d’altérer un élément puissent prendre comme paramètre le désignant, non seulement son id, mais aussi son index dans le tableau des éléments, des mots clefs comme « last » pour désigner le dernier utilisé ou « gen » pour en générer un nouveau, ou encore l’objet correspondant que l’utilisateur aurait déjà récupéré via un document.getElement…. Pour les listes la variable permettant de leur associer des infobulles peut être soit une chaine de caractères soit un tableau de celles ci (ou encore le booléen false pour ne pas en utiliser), et seront traitées différemment selon ce type (aide globale sur toute la liste ou aide différente au survol de chaque élément), etc.. Le petit inconvénient de tout ça étant bien entendu la nécessité que ces fonctions vérifient ce que l’utilisateur leur transmettait (pour les id en en appelant une autre qui leur retourne l’élément désigné quel que soit la manière dont il était renseigné).

La Gestion d’Erreurs

Un point où je reconnais par contre que le Javascript pur n’a pas que des avantages, est sa gestion des erreurs. M’était donc venu l’idée de l’améliorer aussi avec l’enregistrement d’un log répertoriant chaque fonction d’AVJS utilisée, une présentation sous forme de fenêtre se superposant à la page plutôt qu’uniquement en console quand des erreurs sont détectées, la possibilité de renseigner une fonction de récupération à déclencher automatiquement pour essayer de reprendre l’exécution, etc.

Le tout nécessitant évidemment d’enrober toutes les fonctions dans des try… catch répercutant leurs erreurs à une fonction finale, et de les faire renseigner le log.

Soit quelque chose alourdissant largement le code, en plus de s’avérer au final ne pas apporter grand chose. Une fois les bugs directement liés à AVJS fixés, il y avait assez peu de cas de figures où cette gestion d’erreurs pouvait être utile, à moins que l’utilisateur enrobe aussi les siennes de try catch, et y ajoute un renseignement du log, tout en laissant AVJS gérer leur résolution finale et lui fournissant éventuellement une fonction de récupération adaptée à son programme. Le tout demeurant de toutes manières limité par le peu de précision des messages d’erreur que fournit le Javascript, à moins qu’il aille en créer de nouveaux types (en dehors de celles spécifiques à AVJS, où j’offrais l’option d’un log étendu avec leurs paramètres, je ne faisais jamais que donner une meilleure présentation aux descriptions d’erreurs et stack traces que javascript fournit normalement). En gros quelque chose qui aurait compliqué le travail de toute personne qui aurait voulu exploiter cet aspect de la librairie.

Je l’appelais encore librairie et n’avait pas l’idée de faire autre chose, mais, justement, à partir du moment où pour exploiter ses fonctionnalités une librairie nécessite qu’un utilisateur change la manière de rédiger le reste de son code, plutôt que de ne faire qu’offrir des éléments indépendants, le terme framework devient plus approprié.

La multiplication des paramètres

Autre indice que je m’éloignais de plus en plus d’une simple librairie, le nombre de variables globales et constantes destinées à offrir différentes possibilités de réglages à l’utilisateur ne cessait de se multiplier. Rien que la gestion d’erreurs par exemple, utilisait 11 constantes pour ses différents réglages et 3 variables globales.

Et le nombre de paramètres de mes fonctions ne cessait aussi d’augmenter, au fur et à mesure que je leur ajoutais des possibilités optionnelles (comme associer un style ou des infobulles aux éléments html générés) et la prise en compte de celles ci nécessitait la multiplication de vérification que tel ou tel était défini ou pas (et encore d’autres de la manière dont la donnée était entrée vu que j’en autorisais typiquement plusieurs).

Ce qui aurait pu rendre écrire les appel à ces fonctions presque aussi long que le code qu’elles visaient à remplacer, si je n’avais pas songé à les documenter aussi bien que possible, rédigeant un jsdoc pour chacune décrivant leurs paramètres (permettant de les voir apparaitre au survol dans des éditeurs comme visual studio code). Rédigé en anglais, comme je comptais à l’origine mettre le tout en public sur un répertoire git.

Pour les éléments les plus complexes, j’avais aussi prévu sur la fin un système de builders, permettant de renseigner leurs paramètres sous forme de map (je ne sais plus pourquoi j’avais préféré les maps aux JSON) pour encore plus de clarté (en fait j’en étais venu à la solution qu’utilisent des frameworks comme React pour leurs props : à partir d’un certain nombre de paramètres, autant prévoir que l’utilisateur écrive leurs noms plutôt que d’avoir à les lister dans d’interminables appels de fonctions).

Même si c’est plus long à écrire,

 x=new InputNumBuilder( ).fromMap({ « id »: »inputX21″, « txt »: »texte », « min »:0, « max »:5, « step »:1, « selected »:0, « onCFunction » : « maFonction », « onButton »: »Envoyer », « ttipText »: »mon texte d’aide », « ttipStyle »: »fontSize:11px ; color:blue; »}). write ( )

… est finalement plus pratique à utiliser sans erreurs dans le renseignement des paramètres que :

 hWrite (codeInputNum (« inputX21 », « texte », 0, 5, 1, 0, « maFonction », « Envoyer », « mon texte d’aide », « 11px; color:blue »))

Surtout que construire un objet à partir d’une map ne force pas à respecter l’ordre des paramètres, ni à rien spécifier pour ceux optionnels que l’on souhaiterait sauter au lieu d’avoir des appels de fonction du style maFonction(« paramètre obligatoire », undefined, « le paramètre optionnel qui m’intéresse »).

Mais au niveau de ma librairie ça me conduisait aussi à ajouter à chaque fonction de ce genre un objet Builder implémentant les méthodes correspondantesDes méthodes write et add transmettant les paramètres voulus à hWrite ou hAdd, et parfois certaines supplémentaires visant à pouvoir modifier et réutiliser un builder. Quant à fromMap() c'est juste la fonctionnalité de base de la classe Object que j'avais transformée en méthode associée à chacun (en js on peut faire new UnObjet()=Object.assign(map) ; j'avais ajouté au prototype des objets une méthode .fromMap(map) utilisant cette fonction de leur classe, avec une petite vérification d'erreur en prime.). Soit à l’alourdir encore.

Impressionnante liste de paramètres d’une fonction générant des listes.

La prise en charge des styles

Tout le principe de ma librairie/framework étant de permettre de partir d’une page HTML vide (enfin n’ayant à contenir que <body></body>) et de complètement la remplir en javascript, en utilisant le moins de HTML possible, j’en étais vite venu à me dire aussi, qu’il était triste pour le coup que l’utilisateur ait besoin par contre de rédiger du CSS pour ces éléments.

J’en étais donc arrivé, en plus de permettre systématiquement d’ajouter des styles au complet aux éléments, à rédiger un paquet de fonction raccourcis ne faisant qu’altérer celui ci. Par exemple on pouvait après créé un élément utiliser une fonction hColor pour changer sa couleur de texte et de fond, hDim pour changer ses dimensions, et un paquet d’autres choses du style. J’avais même le projet d’y inclure aussi de la génération d’animations css, si je ne suis jamais allé aussi loin.

Voilà par exemple celle que j’avais prévue pour le positionnement des éléments :

Je n’entrerai pas dans les détails de son implémentation. Tout ce qu’elle faisait c’est permettre de changer facilement la position d’une div, par exemple, avec un appel de fonction comme hPos (« r », « 25% », 25) pour que le dernier élément utilisé ait une position relative et soit placé avec 25% de décalage à gauche et à 25 * [ unité fixée comme constante, « px » par défaut ] de décalage vertical par rapport à son parent. Il y a évidemment un paquet de choses en plus découlant des particularités d’AVJS (comme l’appel à translateId() pour récupérer l’id de l’élément à positionner quelle que soit la manière dont il avait été renseigné).

La question des noms de fonctions

Pourquoi tous ces « h » à propos ? Parce que je voulais garantir autant que possible que tout en étant courts mes noms de fonctions n’entreraient pas en conflit si un jour quelqu’un voulait l’utiliser en combinaison avec d’autres. Mes fonctions principales, qui s’appelaient à l’origine write (permettant d’écrire dans un élément existant en en remplaçant son contenu, ou le créant si il n’existe pas) et add (permettant d’ajouter du contenu à l’intérieur d’un élément), des noms ayant de grandes chances d’être utilisés par d’autres, avaient donc été renommées en htmlWrite et htmlAdd, puis raccourcies en hWrite/hAdd. Par la suite je me suis mis à utiliser ce h comme préfixe à tout ce qui était modification des contenus de la page (s’il aurait pu être plus logique d’utiliser plutôt c pour les instructions altérant du css), tandis que « e » (abrégeant élément) était utilisé pour les autres fonctions en retournant un (si je me rappelle bien de mes critères, ce qui n’est pas certain).

Et la librairie que je souhaitais adapter au départ, dans tout ça ?

De manière amusante, j’avais tellement bardé AVJS d’autres fonctionnalités, et de choses nécessitant d’écrire leur code différemment, que je ne suis même pas allé au bout de l’adaptation des fonctions de ma librairie initiale (la fonction montrée plus haut permettant de générer des <select>, par exemple, est absente d’AVJS, qui n’avait au stade où j’ai interrompu son développement que celles pour générer des input de type number ou texte, et des listes d’éléments clickables).

Et finalement…

Comme j’étais en pleine formation à l’époque, passée la semaine de vacances que j’avais consacrée à ce projet, dès que les cours ont repris, j’ai été trop occupé pour beaucoup travailler dessus. Puis quand finalement, des mois plus tard, j’aurais eu plus de temps pour l’achever je me suis tout simplement demandé « est ce que ça vaut vraiment le coup ? » En particulier après avoir réalisé qu’elle se transformait de plus en plus en framework inutilement lourd, qui n’intéresserait que très improbablement les amateurs de la légèreté du Js pur, tout en n’ayant aucun des aspects les plus sexy des « vrais ».

Si on prend React par exemple, sa grande force est d’utiliser un DOM virtuel et de n’appliquer au DOM réel que les changements nécessaires au lieu que toute la page ait à être re-rendue, ce que ma librairie ne fait pas (ce serait faisable en js vanilla, en utilisant des méthodes comme celle ci, mais il faudrait que j’y change beaucoup de choses pour les implémenter).

Si on prend Vue.js il est incroyablement léger (un fichier ne pesant qu’environ 20ko zippé), taille que ma librairie égalait déjà en n’ayant pas plus d’un tiers des fonctionnalités que je comptais y mettre. Et comme d’autres frameworks modernes ils ont aussi l’avantage d’utiliser une forme de jsx, de permettre de mêler directement du code html au javascript, sans passer par des string (et la complexe gestion de guillemets que ça entraine parfois pour faire des interpolations). Svelte en pré-compilant html et javascript dans des blocs optimisés arrive à égaler la rapidité d’exécution du js vanilla tout en étant bien moins verbeux. Angular (si j’y suis plutôt allergique personnellement) de son coté est bien plus adapté à produire des applications complexes maintenables sans avoir à être très documentées (du fait qu’il impose une répartition très stricte des fichiers et des méthodologies assez strictes pour utiliser ses fonctionnalités – exactement l’opposé de la philosophie de ma librairie, mais c’est clairement préférable pour qu’un inconnu puisse savoir où trouver chaque chose). JQuery et de nombreux autres ont pour atout de faciliter la communication avec un back-end. Node et Next proposent carrément d’utiliser du Js coté serveur, etc.

AVJS répondait quelque part à son concept (permettre de partir d’une page html blanche, et d’un css l’étant presque autant, et d’en tirer une page web interactive en n’ayant à utiliser quasiment que du javascript), mais il y a en fait très peu de cas où on souhaite utiliser quelque chose comme ça. Elle peut permettre d’improviser une page simple bien plus vite, mais à partir du moment où on n’improvise pas, et cherche à parvenir à un résultat plus élaboré, ça n’apporte pas grand chose. Généralement il est bien plus clair d’entrer un squelette de page complet dans le html (quitte à en laisser des parties vides tant que le javascript ne les remplit pas), et des classes de styles dans un fichier css séparé (offrant aussi beaucoup plus d’options que celles que j’avais automatisées), si une approche mono-fichier est de plus en plus populaire (favorisée par Svelte et Vue, et possible en React).

Enfin, niveau bonnes pratiques, elle ne respectait pas vraiment l’approche SOLID, généralement recommandée pour tout ce qui est programmation objet (ni évidemment l’approche Unobstrusive Javascript pour le développement web – ça encore aucun framework moderneC'est plus une approche qui se justifiait du temps où le javascript ne s'était pas encore imposé comme Le langage frontend, que tous les navigateurs dignes de ce nom supportent et qu'il serait absurde de désactiver. ne s’en soucie vraiment, puis dans le cas d’AVJS c’était quelque peu son concept). Sans oublier que même sans considérer celle ci, pour pas mal de développeurs c’est une hérésie d’utiliser du javascript générant du html comprenant des déclencheurs d’évènements comme onclick etc. (quand il est plutôt recommandé de gérer proprement les évènements en javascript via des eventHandler etc.), si j’ai toujours trouvé bien plus pratique la première option, elle est généralement très mal considérée pour diverses raisons (voir commentaires unanimes à ce vieux post d’un rare développeur partageant ma préférence), et AVJS l’utilise systématiquement.

D’un autre coté ça m’arrive encore aujourd’hui d’être en train de coder en javascript (et y compris avec des frameworks comme React que j’utilise plus souvent que du js pur ces deux dernières années), et de me dire que tel ou tel truc qu’elle prévoyait serait bien plus pratique que ce que j’utilise sans (à savoir du code html inséré avec des interpolations au milieu du javascript plutôt que du code javascript qui génère du code html sans avoir à y toucher, la première chose est bien plus flexible, mais la seconde plus adaptée pour les éléments les plus standards), d’où il m’arrive encore parfois de caresser l’idée de la reprendre (… jusqu’à aller voir son code, réfléchir à la longue liste de choses que j’en changerais aujourd’hui … et me dire qu’après tout ça ne vaut peut être pas le coup de m’y replonger).

Mais quand même,

 const x= hWrite (« Hello world »); // crée automatiquement la div « main » si elle n’existe pas + une seconde div contenant « hello world » et retourne son id

me semble tout de même plus élégant que :

const root = ReactDOM.createRoot(document.getElementById('root'));

 root.render(Hello world);  

(pour prendre l’exemple le plus simple possible)

Néanmoins il est probable que cette horrible page destinée à tester ses fonctionnalités, et cette todolist, développée pour répondre à la tradition des développeurs de frameworks Javascript (qui je ne sais trop pourquoi fournissent systématiquement l’exemple d’une todolist), restent les seules jamais réalisées en AVJS (d’autant que la rédaction de code assistée par IA permet de produire avec bien moins d’efforts de nos jours le genre de blocs HTML qu’elle servait à générer).

 Tout ça pour dire…

Que je ne puis que confirmer le vieil adage selon lequel tout développeur Javascript finit toujours par avoir la tentation de réaliser son propre framework (et comme mon exemple l’illustre, même en partant d’une volonté de ne pas en réaliser un, juste une librairie pour améliorer un peu sa forme « vanilla »), source infinie de memes sur les espaces consacrés à l’humour de programmeurs.

Après est ce vraiment un mal ou un bien ? Évidemment du point de vue des professionnels ayant une approche productiviste du numérique c’est tout sauf recommandable dans la mesure où la multiplicité des frameworks ne peut que faire perdre du temps à ceux qui voudraient reprendre des projets entamés par d’autres. Pour m’être vu proposé récemment de fixer un très vieux site web comprenant du code basé sur SpryUn vieux framework plutôt mal documenté et dont même la version open source n'est plus maintenue depuis 12 ans, qui utilise un paquet de techniques peu recommandées de nos jours, comme barder les pages générées d'iframes pour contourner des limitations de certains navigateurs de son époque. je ne puis que reconnaitre que ça peut être un vrai problème (et encore plus si on imagine un framework artisanal encore moins documenté, d’où je n’irais par exemple jamais réaliser une page avec AVJS si j’imagine qu’elle pourrait avoir à être maintenue par d’autres). Un minimum de standardisation facile évidemment la vie des développeurs web (et explique le succès de choses comme Angular, dont le concept semble être de pousser à une standardisation maximum, même alors que la plupart trouvent plus agréable la liberté qu’offrent des « librairies »Certains frameworks préfèrent se dire librairies, précisément pour souligner que le cadre de travail qu'ils proposent est moins rigide. J'aurais tout de même tendance à utiliser quand même framework à leur sujet, dans la mesure où ils changent largement la manière de coder de leurs utilisateurs (dont en restreignant parfois certaines possibilités du javascript vanilla, comme c'est le cas de React quand il est utilisé pour créer des applications, qui ne permet pas la même manipulation de variables globales qu'en javascript pur) plutôt que de ne faire que proposer un catalogue de fonctions optionnelles. comme Vue ou React).

D’un autre coté, ce serait passer à coté d’un des plus grands charmes de la programmation informatique de s’interdire d’adapter les fonctions qu’on emploie tant aux usages qu’on souhaite en faire qu’à ses propres préférences en matière de rédaction de code.

C’est plutôt une des choses les plus fabuleuses que propose la programmation d’en arriver à développer quasiment son propre langage, à force de création de fonctions personnalisées en fonction de ses besoins. Si ce n’est certainement pas idéal à utiliser hors de projets destinés à rester personnels, c’est au minimum très enrichissant. Cela conduit à la fois à développer ses connaissances sur des aspects du langage utilisé ignorés par ceux qui ne font que passer par des frameworks développés par d’autres et à mieux se connaitre en tant que programmeur (identifier à travers le choix fait de développer un langage dans telle ou telle direction, des tendances dont on ne prendrait pas forcement conscience). Par exemple dans mon cas à quel point je reste influencé par le Basic appris dans mon enfance, me poussant à développer des ersatz de son instruction PRINT (exactement comme dans AVJS, le Basic des années 80 proposait de dire « affiche moi ce texte sur l’écran », sans avoir à se soucier d’un container ou autre structure de page) et permettait d’en fixer le style par des instructions séparées ( COLOR par exemple qui comme le hColor d’AVJS permettait de fixer d’un coup couleur de texte et de fond). Sans vraiment y réfléchir, et tout en offrant par ailleurs toutes les options pour l’adapter à une manière plus moderne de gérer la présentation, c’est à cette forme familière depuis toujours que j’avais tendance à vouloir revenir (enfin dans les cas où il n’est pas nécessaire de faire plus compliqué, pourquoi finalement ne pas faire aussi simple ?). Et pour ce qui est de mieux connaître le Javascript, il y avait pas mal de techniques que j’utilisais très peu, la manipulation du DOM par nodes par exemple, ou la capacité qu’il offre d’étendre les prototypes de ses types de base (ajouter des méthodes à tous les Object, tous les String etc.) que le développement d’AVJS m’a conduit à d’avantage considérer.

Après évidemment c’est souvent « réinventer la roue », que de tenir à se créer son propre framework (ou à ne pas en utiliser du tout, d’ailleurs) plutôt que d’utiliser une des très nombreuses options existantes. Mais sans des gens s’engageant dans ce genre de démarches, la plupart de ces solutions n’existeraient juste pas (même celles développées dans un objectif commercial sont largement basées sur des solutions développées spontanément par des gens voulant se simplifierOu tenant à se la compliquer parfois, sans quoi l'existence du Java EE serait difficile à expliquer. 🙂 la vie, ou plus généralement adapter un langage informatique à leurs attentes particulières). Ceci s’appliquant d’ailleurs aussi aux langages eux-mêmes, PHP par exemple fut créé à l’origine par un informaticien souhaitant ajouter un compteur de visites à sa page personnelle et déçu de ce que PerlLe langage servant à faire ce genre de choses à l'époque, depuis passé de mode au profit du PHP, renommé Raku dans sa dernière version.  proposait en la matière.

Quant à la caricature sur une tendance qui serait propre aux développeurs Javascript de sans cesse en créer, cela découle peut être tout simplement du fait que c’est le langage de programmation le plus populaire au monde, celui que 63% des développeursVoire encore plus si on compte ceux lui préférant le Typescript, qui n'en est jamais qu'une version enrichie d'un système de typage optionnel. utilisent, Python n’étant qu’un lointain second avec 43% d’utilisateurs, suivi de très loin par le Java, les différentes versions de C et le PHP. Tous ces langages comptent certainement la même proportion de développeurs qui ne cessent de chercher à les adapter à leurs besoins ou préférences, mais sachant que ce n’est qu’une de ces tentatives sur des centaines de milliers (millions ?) qui apporte assez aux autres utilisateurs pour devenir un framework populaire (tandis qu’une large majorité finit plus probablement comme AVJS) il est assez naturel d’en trouver à l’arrivée bien plus du coté du langage qui en compte le plus. (Ou si ce n’était pas le cas cela pourrait être une explication de la popularité du Javascript, un langage qui favoriserait la créativité de ses développeurs plus que les autres.)

Ps : Des fois que ça intéresse quelqu’un : le code (probablement à jamais in)complet d’Almost Vanilla Javascript ™.

Quant à Vanilla Javascript, vous pouvez le trouver sur cette page.

pps : Ce post résulte en grande partie du fait que j’ai été trop occupé ces deux dernières semaines pour finir mon générateur procédural de carte, mais voulais quand même publier un article relatif à la programmation cette semaine. La suite du fil rouge arrivera… Quand je trouverai le temps de bien le finaliser.