Essayer d’avoir un projet sans trou de sécu dans ses dépendances javascript, c’est devenu quasi impossible vu le nombre de dépendances, vu le système de non-résolution des dépendances (chaque dep a son propre arbre) et vu que la communauté s’en fout.
C’est la principale raison pour laquelle je n’aime pas trop les projets en nodejs. Ça et l’utopie de croire que tout exécuter avec un seul proc/cœur, y’a qu’à scaler si on veut gérer de la concurrence, s’avère bien plus compliqué qu’il n’y parait au premier abord.
Après le langage en lui-même est particulier mais il n’est pas particulièrement repoussant.
Une version unique de dépendance comme on fait ailleurs c'est déjà beaucoup mieux.
Je trouve hallucinant les dépendances qui comportent à peine quelques lignes de code (voir une seule comme dans l'exemple !) et que des gens l'utilisent au lieu de l'implémenter eux-mêmes. Le code derrière qui utilise ça ne doit pas être bien beau….
Javascript est immonde et devrait arrêter d'être écrit et simplement généré à partir d'autre chose. Voir à long-terme complètement remplacer mais même Google y a renoncé.
C’est la principale raison pour laquelle je n’aime pas trop les projets en nodejs. Ça et l’utopie de croire que tout exécuter avec un seul proc/cœur, y’a qu’à scaler si on veut gérer de la concurrence, s’avère bien plus compliqué qu’il n’y parait au premier abord.
Posté par Faya .
Évalué à 3.
Dernière modification le 25 novembre 2021 à 18:20.
Et Flutter avec Dart ! Je n'ai encore rien fait de sérieux avec mais ça me plaît. Je suis juste un peu inquiet du fait que ça soit maintenu par Google qui a la fâcheuse habitude de casser/jeter les projets régulièrement.
Javascript est immonde et devrait arrêter d'être écrit et simplement généré à partir d'autre chose.
<mavie>
Amusant ; c'est exactement un ressenti similaire qui m'a poussé à créer les bibliothèques sur lesquelles je travaille actuellement. D'origine, c'était du code C++ générant du JavaScript destiné à manipuler le DOM du navigateur, avec comme effet secondaire de ne plus avoir à écrire de frontend dédié, le DOM du navigateur étant directement manipulé à partir du backend.
Par la suite, j'ai crée des wrappers vers ce code pour Java, Perl, PHP (mais qui n'est plus maintenu), Python, Ruby et… Node.js. Pour ce dernier, l'intérêt étant uniquement de ne pas avoir à écrire de frontend dédié.
</mavie>
Pour nous émanciper des géants du numérique : Zelbinium !
Je trouve hallucinant les dépendances qui comportent à peine quelques lignes de code (voir une seule comme dans l'exemple !) et que des gens l'utilisent au lieu de l'implémenter eux-mêmes.
La faute à une stdlib trop pauvre. Je vois la même chose avec Rust mais comme ça compile statiquement au lieu d'avoir un node_modules de 10Go, ça choque personne.
Le code derrière qui utilise ça ne doit pas être bien beau….
Bah… pas forcément… En quoi le code qui copie/colle 3 lignes serait plus beau que le code qui fait un require?
Javascript est immonde et devrait arrêter d'être écrit et simplement généré à partir d'autre chose.
Oof, on était pas encore Vendredi pour un troll pareil.
Cracher comme ça sur un langage c'est vraiment ne pas comprendre ce qu'il apporte ni le pourquoi du comment.
Alors rappelons un peu l'histoire, Javascript est une implémentation de la norme EcmaScript (QtScript en est une autre pas exemple). La version supporté à 100% par la totalité des plateforme c'est la version 5 de la norme.
Cette norme a beaucoup évolué. La version 6 date de 2015, depuis on a abandonné ce numérotage et on est passé sur des dates, nous sommes aujourd'hui à ES2020. C'est un langage beaucoup plus mature, qui règle nombre des problèmes qui étaient présent dans la version 5, tout en gardant une rétro-compatibilité phénoménale. Et oui ton code d'il y a 20 ans va toujours pouvoir s'exécuter sans aucun soucis aujourd'hui. Montre moi un autre langage comme ça (j'ai C++, Python et Java dans le viseur).
En plus, aujourd'hui il y a TypeScript, dont le système de type est tellement expressif qu'il est une machine de Turing permettant des implémentations assez drôles:
Posté par ff9097 .
Évalué à 0.
Dernière modification le 26 novembre 2021 à 19:00.
Bah… pas forcément… En quoi le code qui copie/colle 3 lignes serait plus beau que le code qui fait un require?
Quand on préfère ajouter bêtement une dépendance au lieu d'implémenter 1 ligne pour quelque chose qui n'évoluera jamais c'est qu'on ne réfléchis pas beaucoup à ce qu'on fait. Ce qui laisse à penser qu'on a pas beaucoup réfléchi au reste.
Que ce soit du copier/coller, ou du require. C'est emmerdant car on doit le maintenir. Ce genre de code devrait faire partie de la stdlib.
Maintenant tu as quelqu'un qui a préféré fournir un ensemble de micro package, au lieu de fournir un immense package. Pourquoi ? Parce qu'il a estimé que les gens n'utiliserai pas un gros package sous prétexte que 95% de ce dernier ne leur sert pas.
Des micro-package c'est normal mais 1 ligne sérieusement….
Ce genre de chose c'est en aucun cas la faute du langage. Je peux t'écrire des libs de 1 ligne en Python, en Go, en Rust, en C++, etc…
Tu n'as qu'a pas les utiliser, personne t'y obliges.
Par contre si je pouvais avoir une lib pour implémenter String.capitalize avec les edge cases du type emoji, kanji et autres alphabets exotiques, etc… Je l'ajouterai sans regrets car j'ai pas envie de les gérer moi même.
J'espère qu'il y a les packages isEven, isOdd, isTrue et isFalse faudrait quand même pas devoir les implémenter moi même.
Des exemples à la place d'un avis subjectif sorti de nul part ?
typage faible
Python, Erlang/Elixir, Lua, PHP, Perl, Ruby, … En quoi c'est un problème ?
C'est drôle tu défends JavaScript en nous parlant de Typescript.
Donc après avoir cité la norme EcmaScript, toutes les évolutions du language Javascript qui ont eu lieu et qui sont en cours, j'ai le malheur de mentionner Typescript une seule fois et c'est tout ce que tu retiens ?
Le typage faible, c'est lorsque le compilateur/interpréteur n'est pas strict sur la vérification de type avant exécution du code.
La majorité des langages avec typage dynamique ont donc par définition un typage faible.
Je prend par exemple Python:
3 < "something"
int.__lt__(3, "something")
Et oui, on check pas le type on vérifie juste si la méthode est défini --> typage faible.
En Erlang/Elixir on peut comparer aussi différents types:
1 < :atom
1 == 1.0
C'est donc du typage faible.
Pareil dans les autres langages que j'ai cité.
Bordel, je pourrais rajouter le langage C/C++ dans le typage faible pour la bonne et simple raison que je peux aller chercher un pointeur sur la zone mémoire et convertir ça dans n'importe quel autre type.
Tu ne répond donc pas à la question, en quoi le typage faible est il un problème ?
Je vais même aller plus loin, l'appellation "typage fort" et "typage faible" n'a aucun sens, et est complètement inutile.
Tu ne répond d'ailleurs à aucune des autres critiques. Donc oui on va arrêter là car tu n'es clairement la que pour le troll.
Et oui, on check pas le type on vérifie juste si la méthode est défini --> typage faible.
Non le typage de Python est fort. Tu ne peux pas faire :
a = "2"
a += 1
b = 3
b += "1"
Alors qu’en javascript tu peux car la variable a va rester une chaîne de caractère et l’opération + va forcer une conversion implicite des opérandes (ici 1 devient "1"). Idem pour b qui va être converti en chaîne avant d’être convertie, encore implicitement en chaîne de caractère avant d’être concaténée avec "1").
En python tu as deux TypeError à l’éxécution (typage fort) et aucun problème à la compilation (typage dynamique)
Arrêtez de faire de la publicité pour ce type (j'ai déjà expliqué pourquoi, cherchez dans mes précédents commentaires).
Il parle, il parle, mais il réinvente la roue tout le temps et force tout le monde à utiliser ses outils sans quoi il refuse de continuer. Quelques exemples :
scdoc, parce qu'il n'a pas envie d'écrire dans un format réputé et stable qu'est mdoc, du coup les gens qui veulent maintenir les pages de manuel doivent apprendre son nouveau format.
son système de mailing list, parce qu'il a pas envie d'utiliser ce qui existe et donc menace alpine linux de plus contribuer si on enlève son truc.
son propre langage de programmation.
vous pouvez aussi voir ses commentaires sur github pour voir à quel point il est toxique et vient intervenir là où l'a pas invité avec ses opinions.
J'attends qu'une chose, c'est qu'il quitte Alpine Linux (dont je suis contributeur) et je pense pas être le seul à le vouloir. Ce gars est à l'opensource ce que les « influenceurs » sont à instagram.
git is great because linus did it, mercurial is better because he didn't
# Hilarant
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 5.
Par contre ça donne aucune vraie solution.
Essayer d’avoir un projet sans trou de sécu dans ses dépendances javascript, c’est devenu quasi impossible vu le nombre de dépendances, vu le système de non-résolution des dépendances (chaque dep a son propre arbre) et vu que la communauté s’en fout.
C’est la principale raison pour laquelle je n’aime pas trop les projets en nodejs. Ça et l’utopie de croire que tout exécuter avec un seul proc/cœur, y’a qu’à scaler si on veut gérer de la concurrence, s’avère bien plus compliqué qu’il n’y parait au premier abord.
Après le langage en lui-même est particulier mais il n’est pas particulièrement repoussant.
[^] # Re: Hilarant
Posté par ff9097 . Évalué à 0.
Une version unique de dépendance comme on fait ailleurs c'est déjà beaucoup mieux.
Je trouve hallucinant les dépendances qui comportent à peine quelques lignes de code (voir une seule comme dans l'exemple !) et que des gens l'utilisent au lieu de l'implémenter eux-mêmes. Le code derrière qui utilise ça ne doit pas être bien beau….
Javascript est immonde et devrait arrêter d'être écrit et simplement généré à partir d'autre chose. Voir à long-terme complètement remplacer mais même Google y a renoncé.
Quel rapport avec le reste ?
[^] # Re: Hilarant
Posté par Nibel . Évalué à 4.
C'est ce qui est fait avec des frameworks comme Vue, React ou Angular.
Ca rend pas la chose moins immonde cela-dit, pour faire de l'Angular dans un cadre pro depuis 3 ans…
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Hilarant
Posté par Faya . Évalué à 3. Dernière modification le 25 novembre 2021 à 18:20.
Et Flutter avec Dart ! Je n'ai encore rien fait de sérieux avec mais ça me plaît. Je suis juste un peu inquiet du fait que ça soit maintenu par Google qui a la fâcheuse habitude de casser/jeter les projets régulièrement.
[^] # Re: Hilarant
Posté par ff9097 . Évalué à 2.
Si je ne me trompe pas on écrit toujours en JavaScript avec ces frameworks
[^] # Re: Hilarant
Posté par Nibel . Évalué à 4. Dernière modification le 26 novembre 2021 à 00:04.
En TypeScript pour être exact.
C'est du javascript typé, très très grossièrement.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Hilarant
Posté par Claude SIMON (site web personnel) . Évalué à 4. Dernière modification le 25 novembre 2021 à 17:25.
<mavie>
Amusant ; c'est exactement un ressenti similaire qui m'a poussé à créer les bibliothèques sur lesquelles je travaille actuellement. D'origine, c'était du code C++ générant du JavaScript destiné à manipuler le DOM du navigateur, avec comme effet secondaire de ne plus avoir à écrire de frontend dédié, le DOM du navigateur étant directement manipulé à partir du backend.
Par la suite, j'ai crée des wrappers vers ce code pour Java, Perl, PHP (mais qui n'est plus maintenu), Python, Ruby et… Node.js. Pour ce dernier, l'intérêt étant uniquement de ne pas avoir à écrire de frontend dédié.
</mavie>
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Hilarant
Posté par David Delassus (site web personnel) . Évalué à 3.
La faute à une stdlib trop pauvre. Je vois la même chose avec Rust mais comme ça compile statiquement au lieu d'avoir un node_modules de 10Go, ça choque personne.
Bah… pas forcément… En quoi le code qui copie/colle 3 lignes serait plus beau que le code qui fait un require?
Oof, on était pas encore Vendredi pour un troll pareil.
Cracher comme ça sur un langage c'est vraiment ne pas comprendre ce qu'il apporte ni le pourquoi du comment.
Alors rappelons un peu l'histoire, Javascript est une implémentation de la norme EcmaScript (QtScript en est une autre pas exemple). La version supporté à 100% par la totalité des plateforme c'est la version 5 de la norme.
Cette norme a beaucoup évolué. La version 6 date de 2015, depuis on a abandonné ce numérotage et on est passé sur des dates, nous sommes aujourd'hui à ES2020. C'est un langage beaucoup plus mature, qui règle nombre des problèmes qui étaient présent dans la version 5, tout en gardant une rétro-compatibilité phénoménale. Et oui ton code d'il y a 20 ans va toujours pouvoir s'exécuter sans aucun soucis aujourd'hui. Montre moi un autre langage comme ça (j'ai C++, Python et Java dans le viseur).
En plus, aujourd'hui il y a TypeScript, dont le système de type est tellement expressif qu'il est une machine de Turing permettant des implémentations assez drôles:
On voit de plus en plus de programmation fonctionnelle arriver en Javascript/Typescript, avec notamment:
Merci donc de se documenter un minimum avant d'aller cracher comme ça sur le travail d'autrui.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Hilarant
Posté par ff9097 . Évalué à 0. Dernière modification le 26 novembre 2021 à 19:00.
Quand on préfère ajouter bêtement une dépendance au lieu d'implémenter 1 ligne pour quelque chose qui n'évoluera jamais c'est qu'on ne réfléchis pas beaucoup à ce qu'on fait. Ce qui laisse à penser qu'on a pas beaucoup réfléchi au reste.
[^] # Re: Hilarant
Posté par David Delassus (site web personnel) . Évalué à 2. Dernière modification le 27 novembre 2021 à 09:43.
Que ce soit du copier/coller, ou du require. C'est emmerdant car on doit le maintenir. Ce genre de code devrait faire partie de la stdlib.
Maintenant tu as quelqu'un qui a préféré fournir un ensemble de micro package, au lieu de fournir un immense package. Pourquoi ? Parce qu'il a estimé que les gens n'utiliserai pas un gros package sous prétexte que 95% de ce dernier ne leur sert pas.
C'est marrant parce que Rust mets carrément ça dans leur best practice et ça choque personne : https://rust-unofficial.github.io/patterns/patterns/structural/small-crates.html
C'est ton avis, un avis de chiotte certes, mais uniquement le tiens.
EDIT: J'adore comment tu ignores le reste de ma réponse :)
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Hilarant
Posté par ff9097 . Évalué à 1.
Des micro-package c'est normal mais 1 ligne sérieusement….
J'espère qu'il y a les packages
isEven,isOdd,isTrueetisFalsefaudrait quand même pas devoir les implémenter moi même.Pas de stdlib, bourrés d'incohérences, typage faible… C'est drôle tu défends JavaScript en nous parlant de Typescript.
[^] # Re: Hilarant
Posté par David Delassus (site web personnel) . Évalué à 0.
Ce genre de chose c'est en aucun cas la faute du langage. Je peux t'écrire des libs de 1 ligne en Python, en Go, en Rust, en C++, etc…
Tu n'as qu'a pas les utiliser, personne t'y obliges.
Par contre si je pouvais avoir une lib pour implémenter String.capitalize avec les edge cases du type emoji, kanji et autres alphabets exotiques, etc… Je l'ajouterai sans regrets car j'ai pas envie de les gérer moi même.
Cette partie, c'est du troll rien de plus…
https://nodejs.org/docs/latest-v16.x/api/index.html
Des exemples à la place d'un avis subjectif sorti de nul part ?
Python, Erlang/Elixir, Lua, PHP, Perl, Ruby, … En quoi c'est un problème ?
Donc après avoir cité la norme EcmaScript, toutes les évolutions du language Javascript qui ont eu lieu et qui sont en cours, j'ai le malheur de mentionner Typescript une seule fois et c'est tout ce que tu retiens ?
C'est de la mauvaise foie pure et dure.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Hilarant
Posté par ff9097 . Évalué à 2.
Tu confonds typage faible et dynamique. On va s'arrêter là.
[^] # Re: Hilarant
Posté par David Delassus (site web personnel) . Évalué à 1. Dernière modification le 27 novembre 2021 à 15:03.
Haha ok.
Le typage faible, c'est lorsque le compilateur/interpréteur n'est pas strict sur la vérification de type avant exécution du code.
La majorité des langages avec typage dynamique ont donc par définition un typage faible.
Je prend par exemple Python:
3 < "something"
int.__lt__(3, "something")
Et oui, on check pas le type on vérifie juste si la méthode est défini --> typage faible.
En Erlang/Elixir on peut comparer aussi différents types:
1 < :atom
1 == 1.0
C'est donc du typage faible.
Pareil dans les autres langages que j'ai cité.
Bordel, je pourrais rajouter le langage C/C++ dans le typage faible pour la bonne et simple raison que je peux aller chercher un pointeur sur la zone mémoire et convertir ça dans n'importe quel autre type.
Tu ne répond donc pas à la question, en quoi le typage faible est il un problème ?
Je vais même aller plus loin, l'appellation "typage fort" et "typage faible" n'a aucun sens, et est complètement inutile.
Tu ne répond d'ailleurs à aucune des autres critiques. Donc oui on va arrêter là car tu n'es clairement la que pour le troll.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Hilarant
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 4.
Non le typage de Python est fort. Tu ne peux pas faire :
a = "2"
a += 1
b = 3
b += "1"
Alors qu’en javascript tu peux car la variable
ava rester une chaîne de caractère et l’opération+va forcer une conversion implicite des opérandes (ici1devient"1"). Idem pourbqui va être converti en chaîne avant d’être convertie, encore implicitement en chaîne de caractère avant d’être concaténée avec"1").En python tu as deux
TypeErrorà l’éxécution (typage fort) et aucun problème à la compilation (typage dynamique)# Il n'est pas un exemple
Posté par David Demelier (site web personnel) . Évalué à 6.
Arrêtez de faire de la publicité pour ce type (j'ai déjà expliqué pourquoi, cherchez dans mes précédents commentaires).
Il parle, il parle, mais il réinvente la roue tout le temps et force tout le monde à utiliser ses outils sans quoi il refuse de continuer. Quelques exemples :
J'attends qu'une chose, c'est qu'il quitte Alpine Linux (dont je suis contributeur) et je pense pas être le seul à le vouloir. Ce gars est à l'opensource ce que les « influenceurs » sont à instagram.
git is great because linus did it, mercurial is better because he didn't
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.