Discussion :

[Aizen64]

Code javascript :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
function add(a, b) {
    return a + b;
}
 
module.exports = {
    add
};

C'est de ça que tu parles ?



C'est brouillon dans ta tête parce que tu n'es pas formé. module.exports c'est la syntaxe d'export de CommonJS et import from c'est la syntaxe d'import des modules ES6.

Et si ça fonctionne pas nativement c'est parce que c'est pas implémenté dans le moteur que tu utilises. Ça fonctionnera très bien sur Chrome (V8) mais pas sur IE par exemple. Ça n'a pas de rapport avec le langage c'est lié au moteur qui implémente le langage.

Ta remarque sur CommonJs illustre bien mes propros et JS est à ma connaissance le seul language a avoir non seulement 3 façons de faire ce que d'autres langages appellent des classes, n systèmes de modules (CommonJS, AMD pour Async Module Definition ? Il y en a un autre ?).

C'est précisément le point que je soulève, c'est un vrai bordel.

Ce que je trouve assez équivoque c'est qu'un dev avec qui j'ai bossé, quand je lui ai dit que je n'aimais pas le language m'a rétorqué "tu devras changer d'avis en regardant NodeJS", pourtant, j'ai aussi entendu de sa part des "bon... c'est Javascript".

De la part de 3 devs expérimentés, j'ai entendu ces arguments :
- les frameworks Javascript c'est comme des champignons, il em pousse toutes les semaines. Ça ne me pousse pas à utiliser un framework backend car je ne sais pas si il sera là dans 3 ans. Ça bouge trop
- la communauté JS est tellement éparpillée que c'est un peu bordélique
- en framework backend JS (dit il y a un an et demi), il y a Express qui correspond à un micro framework

La partie asynchrone était novateur à l'époque mais il me semble que les langages .NET l'ont intégré, Java aussi j'imagine. Reste les nombreux langages interprétés où ça n'a pas l'air d'être le cas. Du moins des alternatives stables existent.

[Pyramidev]

n systèmes de modules (CommonJS, AMD pour Async Module Definition ? Il y en a un autre ?).

Depuis le début du mois, pendant une partie de mon temps libre, je suis en train de découvrir JavaScript et TypeScript.
Dans le manuel de TypeScript, à la page Modules, lis la section Code Generation for Modules.
On y voit que TypeScript peut transpiler le code vers 5 systèmes de modules différents.

Voici le début de la section :

Depending on the module target specified during compilation, the compiler will generate appropriate code for Node.js (CommonJS), require.js (AMD), UMD, SystemJS, or ECMAScript 2015 native modules (ES6) module-loading systems.

En dessous, on voit un exemple de module très minimaliste en TypeScript puis, pour chacun des 5 systèmes de module, le code JavaScript généré par le compilateur depuis ce module TypeScript.

[Aizen64]

Depuis le début du mois, pendant une partie de mon temps libre, je suis en train de découvrir JavaScript et TypeScript.
Dans le manuel de TypeScript, à la page Modules, lis la section Code Generation for Modules.
On y voit que TypeScript peut transpiler le code vers 5 systèmes de modules différents.

Voici le début de la section :

En dessous, on voit un exemple de module très minimaliste en TypeScript puis, pour chacun des 5 systèmes de module, le code JavaScript généré par le compilateur depuis ce module TypeScript.

Alors, ça illustre bien mon point sur JS, il y a 5 façons différentes de créer des modules JS et presque autant de façons de faire un truc qui se rapproche d’une classe.

Allez PHP, ce truc mal conçu et moche en a 3 include/require et l’autoloading avec les espaces de nom.

Java/C# : une seule directive, Ruby et Python pareil il me semble.

Il faut regarder les choses en face, à la base JS n’a pas été conçu pour être très modulaire sinon ces systèmes de modules n’existeraient probablement pas et il y aurait déjà eu cette notion incluse depuis sa création.

Ce que je trouverai intéressant c’est que webassambly perce et que l’utilisation de JS ne soit plus une obligation.


Je reverrai la doc TS plus tard, merci de l’avoir incluse c’est intéressant.

[Sodium]

Il faut regarder les choses en face, à la base JS n’a pas été conçu pour être très modulaire sinon ces systèmes de modules n’existeraient probablement pas et il y aurait déjà eu cette notion incluse depuis sa création.

Non en effet, encore une fois JavaScript a été conçu à la base pour rajouter des interactions simples dans une page telles que faire clignoter un texte. L'utilisation actuelle de ce langage est un accident.

[Werel]

Par exemple j'en ai une qui prend une valeur en entrée, si c'est un array ça retourne la valeur et si non ca retourne un array contenant la valeur (https://www.npmjs.com/package/arrify).

Je ne suis qu'un débutant en programmation, mais je dois dire que j'ai beaucoup ri. J'ai d'ailleurs fait partager le lien.