11513 sujets

JavaScript, DOM et API Web HTML5

Salut à tous, question "café".
C'est quoi cette mode de Github, Node.js, Typescript & consort ?
Là je suis dans une période ou je met à jour ma base de travail habituelle, sorte de framework maison, que j'utilise sur mes projets pro & perso.
Au fil des années j'avais accumulé pas mal de retard sur les versions, notamment PHP et MySQL. Forcément avec les dépréciation, pas mal de trucs à surveiller, gros chantier.
Côté Javascript, j'utilise Jquery et tout un tas d'addons spécifique à la lib. Donc un peu de travail aussi pour garantir que chaque module fonctionne bien avec la version de Jquery.

Et je dois dire que je suis souvent tombé sur un os, impossible de mettre la main sur des fichiers .js ou des procédures clairs d'installation.
En l'espace de quelques années, tout est passé en npm. Alors je suis d'accord qu'en leur temps Jquery & Prototype avaient trouvés leur opposants, notamment car ca séparait la communauté. Et c'est d'ailleurs ce qui s'est passé, notamment dans le milieu pro, avec des offres nécessitant la maitrise de telle ou telle librairie.
Mais on pouvait toujours coder en js pur sur un site utilisant l'un ou l'autre. Que là, parfois, impossible de trouver un fichier .js à télécharger, ou alors il est planqué sur github au bout de 3 répertoires. Par contre, la commande npm à entrer pour tout installer "simplement" est systématiquement mis en avant. Pas sur que si je tape ca dans l'invite Windows, ca fonctionne... xD
Sur les sites officiels, plus de liens de téléchargement direct, on renvoi vers github ou npmjs. On parle quand même de sites ou il faut farfouiller dans des menus pour pouvoir télécharger ce qu'on veut. Et encore, au lieu d'un fichier .js, on se retrouve avec des .zip blindés de sous répertoires et de fichiers dont on ne comprend pas l'utilité.
Plus possible de charger un seul fichier, il faut se faire spéléologue d'arborescence. Un net progrès. ^^'

A contrario, si la commande npm est toujours mise en avant, rien sur le type="module" à ajouter aux balises <script> pour que ca fonctionne. Même les navigateurs ne s'emmerdent pas à le préciser dans leurs messages d'erreur, ou souvent c'est une fonction import qui est notifiée comme source de l'erreur.
Pour comparer, quand on tente des trucs déprécié ou déconseillé en PHP, les erreurs sont claires, complètes, on comprend facilement l'origine de l'erreur.

La dernière originalité constatée et celle qui me convint de venir ici papoter un peu, c'est les fichiers .ts. Alors déjà pour moi c'est un fichier vidéo, avis partagé par mon mpc. Smiley lol
Ensuite, j'ai bataillé un peu dans le zip github pour trouver la source (à défaut de .js) puis ai finit par ouvrir au pif les fichiers les plus lourd, qui n'étaient évidement pas à la racine, ca aurait été trop simple.
C'est de toute manière un échec, j'ai changé l'extension, présumant qu'il s'agissait juste de clarifier le respect ou pas de telle ou telle version d'ECMA, à priori non, le navigateur me renvoi des erreurs de syntaxe.

Tout ca pour dire que je me suis documenté un peu quand même et comprend parfaitement l'intérêt de restreindre les portées variables au seins d'espaces compartimentés, signifier au navigateur la nature d'un script - notamment pour optimiser le chargement des pages - et tout le reste qui ne m'est pas resté en tête.

Mais, à une époque d'inclusivité (réelle ou apparente, ce n'est pas le sujet ici) et d'ouverture, c'est quand même singulier qu'une grande partie de la communauté du dev front JS se soit jetée à corps perdu sur des technologies, des outils et des plateformes très spécifiques, parfois un peu fermées, rompant en grande partie le lien avec d'anciens ou de petits développeurs qui n'ont pas la maitrise ou l'utilité de ces outils.

Voilà, j'espère ne pas avoir semblé agressif ce n'est absolument pas le but et j'ai hâte de lire vos retours qui sauront certainement m'éclairer et surtout seront bien plus pertinents que mon ressenti de petit développeur indépendant perdu au fin fond des Alpes Provençales. Smiley cligne