Discussion :

[Beginner.]

Salut,

Est-ce possible de travailler sous forme de projet (avec plusieurs fichier .js) ? Connaissez-vous un IDE qui permet cela ?
Comment faites-vous quand vous avez plusieurs fichiers dépendant les uns des autres ?

Je veux dire un peu comme Java par exemple : on a plusieurs fichiers (une classe par fichier), des packages et les "imports"...

- Si j'ai bien compris ES6 permettrait cela mais ce n'est pas encore pris en compte par les navigateurs, c'est bien ça ?
- J'ai commencé à lire des truc sur Require.js, include.js, Babel, Browserify... Mais je suis un peu perdu pour l'instant...

Je n'ai pas encore compris si on peut utiliser ces outils durant la phase de développement ou bien si c'est seulement après, pour la distribution...

Je me doute que c'est un sujet vaste...

Merci.

[sekaijin]

il existe des outil comme en java
grunt gulp maven etc

ou tout simplement si ce n'est pas gros une liste de balise script dans la page html

A+JYT

[Beginner.]

Merci. Il n'y a pas foule dans ce fil... (Sujet difficile je pense)

Alors dans mes lectures j'ai effectivement croisé grunt et gulp, si j'ai bien compris ça permet d’exécuter des taches automatiquement mais les taches en question sont développées dans des modules extérieurs... ???

Sinon c'est difficile de comprendre l’intérêt si on ne comprends pas le problème de départ :

- Est-ce qu'on utilise ces outils (Require.js, include.js, Babel, Browserify...) pour éviter d'avoir à insérer manuellement une liste plus ou moins longue de balise <script> ?

J'ai cru comprendre qu'un des problèmes c'est qu'il faut insérer les scripts dans le bon ordre sinon ça ne fonctionne pas... Si on le fait manuellement il faut donc connaitre cet ordre...

Un autre c'est que les scripts peuvent dépendre les uns des autres, là c'est chaud, je ne vois pas comment on peut faire manuellement, ça me semble plus difficile de comprendre comment les outils règlent ce problème là... Y a-t-il des cas insolubles ?

Je suppose aussi que ces outils veillent à ce que les scripts ne soient chargés qu'une seule fois ? Mais je me demande si il n'y a pas des cas insolubles (sans charger plusieurs fois).



PS : J'ai lu cet article : Modularité -- JavaScript Éloquent

[sekaijin]

il existe des outils pour gérer les dépendances

certains framework en intègre un en natif (sencha par exemple)
dans ce cas le framework est fournis avec un outil (ANT ou ligne de commande) qui parse tout ton code gère les dépendances et te génère un seul script js compacté ou pas

sinon requireJS fonctionne différemment tu lui donne une liste de dépendance et le script qui en dépend
ainsi de proche en proche il reconstruit tout l'arbre (comme le fait le import en java)
Mais c'est à l’exécution qui va calculer les dépendances.

là encore des outils permettent de parser le code relever toutes les dépendances et soit te générer un dossier avec tout tes script utilisés soit un seul script compacté ou pas.

on peut voir ces outils comme une phase de compilation.
c'est entre autre ce que font les outils Abstract Syntax Tree comme http://shift-ast.org/

Grunt Gulp est un peut comme Ant mais en JS
Ils possèdent quantité de tâche plugable pour générer un projet.

A+JYT

[Beginner.]

Merci encore.

là encore des outils permettent de parser le code relever toutes les dépendances et soit te générer un dossier avec tout tes script utilisés soit un seul script compacté ou pas.

Oui justement j'ai cru comprendre que c'est ce que fait Browserify, certains disent en gros qu'il permet de travailler dans le navigateur (client) comme on le fait avec node.js (il parait car je ne connait pas vraiment)... Genre on peut mettre des require() partout...

Mais j'en déduis que c'est seulement pour la distribution alors ? Pas pour la phase de développement avec débogage dans le navigateur ? Car le navigateur ne connait pas require() ?


EDIT :

on peut voir ces outils comme une phase de compilation.

Ah oui ok, donc peut-être qu'avec ces outils on "compile" de sorte que le code soit ensuite exécutable dans le navigateur ?

[sekaijin]

oui il existe des tâche grunt gulp etc qui prennent tous les requires pour organiser l'arbre de dépendances et copient dans l'ordre approprié le contenu du code dans un seul fichier js.

[Beginner.]

Merci.

[nicdodo]

WebPack est pas mal à la mode aussi en ce moment

[Beginner.]

Salut,

Connaissez-vous un IDE qui permet de travailler sous forme de projet ?

Pour l'instant j'ai l'impression qu'il faut presque tout faire soi-même (prendre un éditeur, ajouter des extensions et les configurer, définir des tâches...)...

Cela m'étonne un peu quand même, quelque chose doit m’échapper...

[SpaceFrog]

Je dirais que le dev web avec javascript est tellement vaste, les contextes tellement variés, qu'actuellement il n'y a pas vraiment de solution qui s'impose, et donc pas de choses toutes faites.
Il faut en effet bien souvent monter son propre environnement de développement en choisissant son éditeur, y adjoindre des plugins, des addons, des librairies.

C'est encore assez instable, certains ne jurent que par gulp, d'autre grunt, d'autre encore vénèrent angular. Ajouter à cela les phénomènes ridicules de "mode", tout le monde se jette sur telle ou telle techno qui sois disant révolutionne le dev web.
Tout cela au final en ignorant bien souvent les bases même de javascript et du DOM, et on se retrouve avec des développeurs qui ont monté des environnements de développement qui ressemblent plus a des centrales nucléaires, mais sont incapables de positionner ou masquer un élément de la page ...

Il est clair que certains outils peuvent aider au développement et simplifier la génération d'un code propre et compatible, je pense en particulier à SASS, LESS ou Stylus mais de ce que je vois de l'évolution du développement web aujourd'hui il y a beaucoup de complexifications inutiles, chacun y allant de son outil qui ramène le codage de javascript vers des habitudes de codage d'autres technologies (3/3 en particulier).

Tout cela au détriment de la connaissance des bases du HTML / JS / CSS.

[SylvainPV]

Oui c'est la jungle Pour les débutants, ça doit être un enfer... On ne sait même plus de quoi on parle.

Mes conseils :
- Oublier grunt et gulp, ce sont juste des outils pour vous aider à gérer des tâches complexes genre 20 scripts en parallèle. La plupart des gens, surtout débutants, n'auront qu'une ou deux commandes qu'ils peuvent taper manuellement à chaque fois ou mettre dans la section scripts de package.json pour les lancer avec npm run.
- Oublier webpack, même si très puissant c'est aussi une usine à gaz et il n'apporte pas grand chose sur les "petits" projets.
- Oublier Angular, React et tous les gros frameworks qui apportent leur outillage, syntaxe non standard et autre : mieux vaut se concentrer sur les bases et commencer petit
- Oublier RequireJS, CommonJS, AMD etc... tous ces formats sont obsolètes par rapport aux modules ES et à import/export

- Utiliser ES6 : contrairement aux idées reçues, les dernières features JS permettent souvent de simplifier le code là où leurs équivalents ES5 sont longs et verbeux.
- Utiliser les modules ES : les modules sont une manière bien plus propre d'organiser son code, fini de s'embrouiller avec un tas de balises script et une meilleure analyse statique dans l'IDE
- Utiliser Babel avec preset-env: certes un peu compliqué à mettre en place, mais ensuite on peut utiliser tout ce qu'on veut en ES6 sans se soucier du support navigateur. Et ensuite on peut facilement ajouter le module bundling et la minification du JS.

Tous les autres outils (TypeScript, PostCSS, gros frameworks JS...) sont à mettre dans les mains de développeurs expérimentés avec ces bases, pour ne pas s’emmêler les pinceaux entre syntaxes standard et non standard.

Bon allez, je retourne bosser sur mon projet Angular/Gulp/Babel/Webpack/PostCSS

[Beginner.]

Merci à vous.

Ok donc c'est normal que je sois perdu, me voilà rassuré...

Que pensez-vous des modules IIFE (immediately-invoked function expression) ? Sont-ils aussi obsolètes ?

Pourquoi on n'utilise des modules IIFE et pas juste des objets (avec les classes ou les prototypes) ?

EDIT : Je reviens car je me pose une question mais il y a peut-être ma réponse ici :

- Utiliser les modules ES : les modules sont une manière bien plus propre d'organiser son code, fini de s'embrouiller avec un tas de balises script et une meilleure analyse

Est-ce qu'en utilisant les "import" on n'a plus à inclure soi-même les scripts dans le bon ordre à l'aide de la balise <script> ? Cela se fait automatiquement ? Et si les modules sont interdépendants, il se débrouille ?

Merci.

[SylvainPV]

les IIFE ne sont pas un format de module mais un simple pattern pour isoler un bout de code en se servant de la portée locale d'une fonction anonyme. Depuis ES6 on peut faire la même chose simplement en mettant son code entre accolades:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
//IIFE en ES5
(function(){ 
var x = 42;
})()
 
// en ES6
 
{
var x = 42;
}

Les modules ES ne doivent pas être interdépendants, càd que si A importe B, B ne peut pas importer A. Certains module bundlers peuvent parvenir à gérer ce genre de références circulaires mais il vaut mieux les éviter et avoir un arbre de dépendances clair pour ne pas avoir à gérer cette notion d'ordre d'import justement.

[Beginner.]

Merci.

- Ok c'est pour isoler le code mais avec les objets (avec les classes ou les prototypes) le code est aussi isolé, non ?

- Et si je veux exporter la variable x par exemple, c'est-à-dire y avoir accès, on fait ça : var obj = {var x = 42;} puis obj.x ?

Les modules ES ne doivent pas être interdépendants, càd que si A importe B, B ne peut pas importer A. Certains module bundlers peuvent parvenir à gérer ce genre de références circulaires mais il vaut mieux les éviter et avoir un arbre de dépendances clair pour ne pas avoir à gérer cette notion d'ordre d'import justement.

Ok.
Sinon j'ai essayé avec Chrome mais ça marche pas... Je me demande toujours si en utilisant les "import" c'est le navigateur qui inclus les script ---> on n'aurait plus à le faire soi-même avec la balise <script>...

[Beginner.]

Je répond ici à ton message de l'autre fil car ça rejoint le sujet de ce présent fil...

Ça dépend de comment tu configures tes outils. Actuellement on fait souvent la minification uniquement pour distribuer le code de production, parce que ça prend du temps et ça complique le débogage. Mais la mise à plat des modules est systématiquement faite vu le faible support navigateur actuel pour les modules ES. Ça changera peut-être d'ici un an ou deux.

Oui bien sûr on ne va pas déboguer le code minifié déjà que de devoir déboguer tous les codes compactés dans un seul fichier me pose problème (durant le débogage c'est plus facile de repérer le code auquel on a faire quand ils ont chacun leur fichier)...

Mais moi je voulais parlé du "bundle" non minifié, ce fichier on peut l'exécuter dans le navigateur si j'ai bien compris et donc on peut le déboguer, non ? C'est juste que je trouve ça plus difficile, moins agréable (lisible) que lorsque le code est séparé dans plusieurs fichiers...

Mais je me demande si cette histoire de "source map" que je ne connais pas n'a pas pour but de régler ce problème justement...

[SylvainPV]

j'ai essayé avec Chrome mais ça marche pas

Les modules sont supportés à partir de Chrome 61 uniquement : http://caniuse.com/#feat=es6-module (60 sous flag)

Ok c'est pour isoler le code mais avec les objets (avec les classes ou les prototypes) le code est aussi isolé, non ?

Tu confonds structure et visibilité, ce n'est pas le même sujet. La question est de savoir si la variable x est publique/exposée ou non, peu importe si x est un nombre, une fonction, un objet, une classe etc...

var obj ={var x =42;}

Cette syntaxe est invalide, s'il y a un égal à gauche de l'accolade alors c'est interprété comme une déclaration littérale d'objet et non comme un bloc.
Il n'y a pas d' "export" possible si la variable est déclarée dans la portée locale. C'est ce qu'on cherche à faire, isoler le code. Pour transmettre la valeur hors d'une IIFE ou d'un bloc, il faut l'assigner à une variable hors de cette portée.

Oui bien sûr on ne va pas déboguer le code minifié déjà que de devoir déboguer tous les codes compactés dans un seul fichier me pose problème (durant le débogage c'est plus facile de repérer le code auquel on a faire quand ils ont chacun leur fichier)...

En effet, les sourcemaps servent à régler ce problème.

[Beginner.]

Merci.

Ok je ne connais pas les classe en JS en fait, je croyais que c'était proche de Java où on peut utiliser des mot clés comme "private"... Mais j'ai cru comprendre qu'un des intérêts d'isoler le code c'était d'éviter la multiplication des variables globales mais n'est-ce pas aussi le cas avec les classes, les propriétés (variables fonctions...) d'une classe ne sont pas globales, non ?

Enfin j'ouvrirai un autre fil sur ce sujet quand j'en saurais plus...

-----------------

---> Pour en revenir à la "programmation modulaire" avec le navigateur : Alors j'ai voulu tester Browserify et ça a bien marché du premier coup... Alors si je me base sur ce test pour définir une procédure/méthode je dirais :

1- On travaille avec plusieurs modules comme on (pas moi hein) le fait avec node (on peut utiliser require()).
2- Mais le navigateur ne connait pas require() c'est pourquoi on doit utiliser un outil (Browserify pour mon test).

• Cet outil prend tous les modules et les mets dans un seul fichier js "exécutable" dans un navigateur...
• Il suffit d’insérer ce fichier (bundle) dans la page html pour tester...

3- Le problème c'est le débogage : nous ce qu'on a en tête c'est nos modules dans des fichiers séparés, et si on veut déboguer le code d'un module en particulier on doit le repérer dans le fichier (bundle) ce qui n'est pas pratique...

---> Alors j'ai vu qu'avec Browserify il y a une option pour régler ça : on peut avoir une version avec "source maps" ---> cela permet de déboguer à partir des fichiers d’origine : concrètement on peut par exemple mettre des breakpoints dans les modules qu'on veut...

Je suis content d'avoir pu faire ce test alors que je ne m'y connais pas vraiment, ça m'a permit de comprendre plusieurs choses...

Mais je ne sais pas si cette façon de faire est bonne alors je me demande comment les développeurs font en général ?
Et vous comment faites-vous ?

Merci.

[SylvainPV]

Comme dit plus haut, je te conseille d'oublier browserify et require(), les modules CommonJS sont obsolètes maintenant que les modules ECMAScript sont là.
Regarde plutôt du côté de https://rollupjs.org/ , en plus les sourcemaps sont gérées par défaut.

[Beginner.]

Merci.

Ok ils sont obsolètes mais j'ai l'impression qu'ils sont très répandus à causse de node, tous les modules qu'on installe avec npm sont des modules CommonJS ?...

Est-ce qu'on peut utiliser ces modules avec les "import" de ES6 ?

Sinon c'est vrai que ce serait mieux de travailler avec les "import" de ES6 puisqu'il est prévu qu'ils soient supportés nativement par les navigateurs...

Regarde plutôt du côté de https://rollupjs.org/ , en plus les sourcemaps sont gérées par défaut.

Ok je vais regarder mais si le but est de travailler avec les "import" de ES6 on peut aussi le faire avec browserify mais si rollups le fait directement cela peut être intéressant... Reste à savoir si on peut travailler avec les modules node...

---> Par contre il y a une chose aussi que je trouve bien et qui réponds à une autre de mes questions :

Si par exemple je modifie juste un module et que je veux vérifier tout de suite ce serait dommage de recompiler/re-parser tous les autres modules que je n'ai pas modifiés, si j'ai beaucoup de modules ça peut prendre du temps à chaque fois en plus d'être du gaspillage... Et justement j'ai vu qu'il y avait watchify pour régler ça...

Alors juste je me demandais si ce problème était aussi régler avec rollups ?

Merci.

[SylvainPV]

Oui Node.js retarde l'adoption des modules ES6 à cause de débats stériles sur la manière de les intégrer avec l'écosystème existant (CommonJS). Mais ce n'est pas un problème vu qu'on a l'outillage pour passer d'un format à l'autre très facilement. Aussi, hier on a annoncé un moyen de supporter les modules ES dans Node : https://medium.com/web-on-the-edge/e...ay-32cff914e4b

Le rechargement partiel dont tu parles est communément appelé hot reload ou rechargement à chaud. Et oui, la plupart des outils dont Rollup le supportent (sans besoin de plugin supplémentaire comme watchify)