C'est quoi cette mode de Node.js, Typescript & Github ?

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.
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.

Salut,

Le métier de développeur à grandement changé et évolué, et c'est assez propre à l'informatique en général. Ce n'est pas qu'il n'est plus possible de coder avec un simple fichier JS. C'es juste que procéder de cette manière, c'est rendre le travail beaucoup plus fastidieux pour répondre aux exigences actuelles (UX/UI, accessibilité, référencement, performance, app mobile, etc). D'où la nécessité de savoir travailler avec un framework, une libraire, etc. Les gestionnaires comme NPM répondent à cette demande: simplifier l'installation, la compilation et le déploiement de notre projet.

Pour résumer, je ne pense pas que ce soit un bordel compliqué et non inclusif (après tout GitHub c'est aussi des milliers de projets open-source avec toute une communauté de contributeurs). Je pense juste que c'est un métier qui nécessite une formation continue constante, sinon tu perds le train, et il roule vite

Merci pour ton retour Anymah. Effectivement c'est un argument censé, mais à contrario, je trouve les évolutions successives de la triplette PHP/HTML/CSS (et MySQL en bonus) tellement plus fluides et respectueuses des développeurs. Sans même parler de l'évolutivité.

Pourtant j'ai connu la fin du grand chamboulement HTML4 > xHTML, l'hégémonie d'IE6, la fin des magicquotes PHP, les atermoiements du CSS en matière de pseudo-éléments, sans parler des errements des navigateurs, entre propriétés propriétaires préfixées et autres conformes W3C.

Mais jamais le fondement même de ces langages (ou assimilés) n'a été remis en question, ou la communauté coupée en deux. Du moins les transitions se font faites en douceur (si on excepte le passage au xHTML/CSS, mais ce cas les gains étaient énormes et universels).
Là je ressent en fait une brutalité dans le truc, d'autant qu'encore une fois, pour les vieux navigateurs tu avais combien de polyfills pour permettre l'usage du CSS3 sans attendre, par exemple ?

Là c'est devenu tellement compliqué pour moi de parvenir à mettre à jour certaines librairies ou modules en JS, que parfois je renonce juste et garde de vieilles versions obsolètes qui en soi fonctionnent toujours très bien.
Et ce n'est pas qu'une question de mise à jour de compétence (qui encore une fois est un argument censé), mais de choix. Je refuse d'utiliser node.js car pour moi c'est ni adapté ni souhaitable.
Ça me fait penser à ces développeurs qui sortent des sites "optimisés pour Google Chrome".
L'un comme l'autre pour moi c'est s'enfermer, au moins un peu.

Le pire c'est que je regarde les apports de ces technos et personnellement je n'y ai pas grand intérêt, au contraire ca complexifierais mes projets inutilement.

Bonsoir,

Le concept de gestion de dépendances et de librairies n'est pas nouveau. Les développeurs front se sont seulement mis à faire ces dernières années ce que d'autres font depuis 10 ou 20 ans.
ON retrouve le concept dans tous les langages usuels: npm pour JavaScript, Composer en PHP, Pip pour Python, il y en a aussi en Rust, en Go, en C#, et Maven pour Java existait bien avant tous ceux-là.
A ma connaissance il n'y a guère que C/C++ qui n'a pas réellement de gestionnaire vraiment adopté unanimement.

En ce qui concerne TypeScript, renseigne-toi sur le typage statique. Il apporte des avantages non négligeables, et ils sont d'autant plus importants au fur et à mesure que la base de code s'agrandit. Au prix, c'est vrai, d'une certaine complexité et une transpilation obligatoire vers JavaScript, mais cet inconvénient est assez vite oublié si tu vois les intérêts que ça apporte.
En fait, tu t'apercevras que plusieurs des langages faiblement typés historiques ont ajouté un typage optionnel plus ou moins récemment dans la même mouvance, à commencer par PHP et Python.
S'ils le font tous, c'est qu'il doit y avoir une vraie raison non ?

Cependant, tu n'es absolument pas obligé d'utiliser tout cela, et peut-être que, pour ton projet, c'est effectivement contre-productif.

En entreprise, on a des projets assez conséquents où ces outils sont indispensables, car sinon la monstrueuse base de code deviendrait totalement ingérable, déjà qu'elle n'est à moitié. On serait aussi beaucoup moins productifs et le travail en équipe serait plus difficile.
Personne n'a envie de perdre du temps et de l'énergie pour faire des choses rébarbatives et/ou répétitives et/ou simples mais où il y a de gros risques de faire des erreurs stupides qui pourraient beaucoup impacter les utilisateurs finaux.
ON a besoin de typage fort, de normes, de standards, de validateurs, de tests automatisés, pour s'assurer que le 95% du développment soit qualitatif et quantitatif à la fois.

Ce qui ne m'empêche pas, dans mes développements privés, de ne pas du tout utiliser certains de ces outils, car je ne les juge pas utiles dans un environnement où je développe seul, où je n'ai pas de clients qui ont des exigences et des délais, et où je maîtrise à peu près totalement toute la chaîne (et où je souhaite la maîtriser car j'aime ça et que je peux prendre le temps de le faire).
J'ai notamment un site perso avec 24000 utilisateurs qui est codé à l'ancienne, à la mode de PHP5, pas de Composer, pas de framework JavaScript, pas de framework CSS, et il se porte très bien depuis 14 ans. J'ai eu quelques soucis de compatibilités pour le monter de PHP 7 à PHP 8, mais rien d'insurmontable.
Pendant un temps, sur le dit site, de 2015 à 2021, j'ai voulu utiliser npm avec CSS autoprefixer, et surtout RequireJS et babel pour pouvoir moderniser mon JavaScript tout en restant compatible IE. Aujourd'hui je suis revenu en arrière, je n'en ai plus besoin, c'est devenu standard sous une forme un peu différente. Ca m'a été bien utile de 2015 à 2018, mais depuis 2020 c'était devenu plus un boulet qu'autre chose. C''était aussi ch### à maintenir à jour les outils en question que si j'avais dû faire à la main le travail qu'il fait à ma place, alors j'ai fini par m'en débarrasser.

En fait, c'est toujours la même question en tâche de fond: chaque outil ou librairie que tu utilises te fait gagner en efficacité, en productivité, en fiabilité, en prévisibilité, et en qualité dans 90% des cas (sauf si tu mises sur des pingres).
Par contre à chaque fois tu perds en maîtrise, en indépendance, et ça on l'oublie facilement, aussi en efficacité, en fiabilité, et en qualité sur les 10% qui ne sont pas couverts, et où tu dois parfois trouver des bidouilles pour contourner des limitations, et où tu te rends parfois compte que, tout ça pour ça au final alors à quoi bon.

En entreprise, on ne s'amuse pas à réinventer la roue. En perso, par contre, ça peut être amusant de réinventer la roue.

C'est à chacun de placer le curseur là où il le juge pertinent pour lui. Dans les plus extrêmes, d'un côté on a le package npm pour calculer si un nombre est pair, et de l'autre, on a ceux qui pensent que si tu ne connais pas chaque transistor de ta machine, tu n'es pas un vrai.
Oui parce que certains ont tellement été lobotomisé à la mode du "je copie/colle, je comprends pas ce que ça fait mais je m'en fous, ça marche" qu'ils sont incapables de trouver la solution triviale en 1 ligne et 5 secondes, et oui parce qu'on peut réfléchir avec la même logique pour son système d'exploitation et son matériel, si on est assez fou pour aller jusque là...

Salut,

QuentinC a écrit :

ON retrouve le concept dans tous les langages usuels: npm pour JavaScript, Composer en PHP, Pip pour Python, il y en a aussi en Rust, en Go, en C#, et Maven pour Java existait bien avant tous ceux-là.
A ma connaissance il n'y a guère que C/C++ qui n'a pas réellement de gestionnaire vraiment adopté unanimement.

Pip est un bon gestionnaire de package. Il est simple et efficace. Il y a quelques surcouches comme pipenv et poetry. Pipenv étant recommandé par python. Il améliore l'ergonomie de la gestion des paquets.

QuentinC a écrit :

En ce qui concerne TypeScript, renseigne-toi sur le typage statique. Il apporte des avantages non négligeables, et ils sont d'autant plus importants au fur et à mesure que la base de code s'agrandit.

On veut faire du TS, alors il faut bien connaitre la POO. Sinon, c'est le mur assuré ! Ce n'est pas que du typage comme certains le pensent… Sinon, ça va être un capharnaüm à gérer dans les fichiers. Quand on connait la POO et le JS, l'apprentissage du TS n'est qu'une virgule.

QuentinC a écrit :

En fait, tu t'apercevras que plusieurs des langages faiblement typés historiques ont ajouté un typage optionnel plus ou moins récemment dans la même mouvance, à commencer par PHP et Python.

Hop pop pop, le Python est un langage à typage fort dynamique. le code ci dessous renvoie une exception de type : TypeError (erreur de typage)

"2" + 2

Il est à noter que c'est un langage dont l'un des paradigmes est le duck typing ¹ ². Dans les dernières versions de python, il y a un module qui permet de mieux gérer mieux le typage ³. Cependant, Python a toujours été un langage à typage fort. C'est l'une des raisons de mon amour pour ce langage.

calcule = lambda a, b, c: (a+b)*c

a = calcule(1, 2, 3)
b = calcule('pommes ', 'et oranges, ', 3)

print(a)
print(b)

Ça renverra :

9
 "pommes et oranges, pommes et oranges, pommes et oranges, "

______
¹ l'une des raisons que beaucoup n'aiment pas
² Si je vois un oiseau qui vole comme un canard, cancane comme un canard, et nage comme un canard, alors j'appelle cet oiseau un canard
³ à partir de la 3.5 de mémoire
Modifié par niuxe (25 Sep 2024 - 12:39)

a écrit :
Hop pop pop, le Python est un langage à typage fort dynamique.

Bien vu, je me suis fait avoir, pourtant je connais la différence. J'ai fait un amalgamme faible/fort et dynamique /statique... c'est une erreur classique.
Donc il fallait effectivement lire: "tu t'apercevras que plusieurs des langages à typage dynamique" et non pas "faiblement typés" dans mon post précédent.

C'est donc une sorte de typage statique optionnel qui a été ajouté en Python et en PHP entres autres, pour des langages qui sont fondamentalement dynamiquement typés.

QuentinC a écrit :

C'est donc une sorte de typage statique optionnel qui a été ajouté en Python et en PHP entres autres, pour des langages qui sont fondamentalement dynamiquement typés.

En fait, il y a 4 niveaux :
- typage fort dynamique (Python et il me semble que le Ruby l'est aussi)
- typage faible dynamique (PHP, JS)
- typage fort statique (Rust, Go)
- typage faible statique (Il me semble que le C dans certains contextes)

Je pense qu'avec tes mots à toi, tu as voulu écrire ce que je viens de rédiger.
Modifié par niuxe (25 Sep 2024 - 20:01)

Bonjour,

Le typage des données ne sert à rien.

Amicalement,

Bonjour,

C@scou a écrit :
C'est quoi cette mode de Github, Node.js, Typescript et consort ?

Ça permet aux pros de garder une longueur d'avance !

Amicalement,
Modifié par parsimonhi (26 Sep 2024 - 00:47)

@C@scou

Qu’est ce qui te paraît compliqué vraiment? Dans quelle mesure tu as l’impression que la communauté est divisée en deux? D’ailleurs pourquoi en deux? Y’a pas que le JS et PHP pour faire du web dynamique. Pour moi ça n’a jamais été aussi simple d’utilisation qu’aujourd’hui. Presque tout est installé et configuré en exécutant juste une ou deux lignes dans le terminal (sauf si tu bosses sur Windows mais ça c’est de ta faute haha) et les IDEs n’ont jamais eu autant de plugins pour t’assister et sont performants comme jamais…

Par contre, je suis d’accord que la liste de compétences nécessaires ne fait que grandir, pour répondre comme j’ai dis précédemment, aux exigences qui ne font que augmenter elles aussi. Malheureusement je crois que c’est fondamental de comprendre tous les outils et librairies qu’on utilise. On ne réinvente pas la roue mais au moins on comprends la roue. Et dans ce sens, oui le métier est devenu plus compliqué.

Édit: essaies voir de développer une API REST en Rust et redis moi si Express et consorts en JS / TS c’est compliqué
Modifié par Anymah (26 Sep 2024 - 23:00)

Salut
je rejoins totalement Anymah, les dev web ne sont pas divisé en 2, mais en 1000

Je me suis mis perso a nodeJS et TS par envie d'apprendre, car le php je connais, ça fait 8 ans, et j'ai toujours aimé le JS, en faire donc côté back est pour moi une chose qui me plaisait.

Et bien et bien... quel facilité pour lancer mon premier serveur (merci chatgtp) et quel plaisir d'utilisé TS (pas tout seul) pour un typage strict et avoir le controle sur tout..

J'avais besoin de faire du microservice sur une archi DDD avec un event broker pour la communication entre micro services conteneurisé, node à une version light pour ça (alpine) et les tests unitaire n'ont jamais été aussi simple à écrire.

Pour moi je vois un réel gains dans le confort d'écriture, de compréhension et de logique algorithmique. La légèreté d'express, l'utilisation d'un router adapté, etc... on peut le faire dans tout langage, mais j'ai pris du plaisir à le faire avec ces technos et une bouffé d'air frais
Modifié par JENCAL (27 Sep 2024 - 10:04)

JENCAL a écrit :
Je trouve ça plus compliqué d'installer wamp que node js sur windows

Alors pour le coup, sous windows, il y a plus simple pour les deux , il suffit d'installer laragon: en démarrant le serveur (apache ou nginx au choix) , php est dispo ainsi que node.js

Hello tous et en particulier C@scou !
Je tombe sur ce post et après avoir lu toutes les réponses je pense qu'il manque un élément essentiel à la compréhension de l'utilisation massive de composants node depuis NPM côté JS client : les builders Javascript.
Le seul moyen d'utiliser ces librairies hébergées sur NPM ou d'utiliser TS dans tes fichiers (ou de bénéficier des nouveautés ES6+, imports et autres) c'est de compiler ces fichiers source.
Ne cherche pas des fichiers JS de tes librairies, il faut les construire avec webpack, rollup ou alors le plus simple avec Vite (le plus simple, le plus rapide, etc...).
Tu demandes comment installer Jcanvas sans node.js, non tu ne peux pas, mais tu peux installer juste une fois node.js sur ta machine (- de 10min), installer vitejs sur ton projet (- de 5min) et ensuite aller faire ton marché dans les milliers de librairies disponibles sur NPM pour ton besoin.
Tu écris dans ton éditeur ton code (avec dans la plupart du temps de l'autocomplétion d'une librairie que tu ne connais pas par coeur), tu lances ton build vitejs et paf tu as ton fichier JS utilisable
Modifié par MatthieuR (11 Nov 2024 - 00:47)