Design & Développement web - Le topic des canards qui mangent des cookies

[Orhin]

Je pensais plus à un cas ou j'utilisais fetch à nouveau en callback d'un fetch
Je crois que j'ai jamais terminé ce code, la syntaxe des promise est pratique mais assez indigeste quand ça se complique.

Whut ?
Au contraire c'est super simple pour enchaîner des appels.

appel1()
  .then(() => {
    return appel2();
  })
  .then(() => {
    return appel3();
  })
  .then(result => {
     effetDeBord(result);
  })
  .catch(err => {
    gestionErreur(err);
  });

etc.

Faut juste tes fonctions retournent toutes une Promise pour pouvoir les chaîner.
Et tu peux faire exactement la même chose avec les Observable (qui peut le plus peut le moins), mais ça te fournit bien plus de possibilités.

Ca reste une bonne idée de prendre l'habitude de se passer de jquery et de piocher dans tout ce que peut offrir npm.

+1
jQuery c'est le mal.

[tenshu]

Whut ?
Au contraire c'est super simple pour enchaîner des appels.

Nah c'était un poil plus cinglé, genre un promise qui appelle un webservice, qui en callback lance x nouvelles requetes qui elle même en lace a nouveau une autre.
Typiquement une promise pyramid of doom.

[Orhin]

Nah c'était un poil plus cinglé, genre un promise qui appelle un webservice, qui en callback lance x nouvelles requetes qui elle même en lace a nouveau une autre.
Typiquement une promise pyramid of doom.

Ah oui je vois.
Bah c'est typiquement le cas où les Observables sont très puissants vu que t'as beaucoup de fonctions pré-fournies pour résoudre ses problèmes (merge, map, combineLatest, etc).

[Gillete]

Ca reste une bonne idée de prendre l'habitude de se passer de jquery et de piocher dans tout ce que peut offrir npm.

+1
jQuery c'est le mal.
[/FONT]

Autant je peux comprendre que NPM c'est l'avenir, mais pourquoi jQuery c'est le mal ? J'ai raté un épisode ?

[Max_well]

Et si j'installe jquery avec npm

[Orhin]

Autant je peux comprendre que NPM c'est l'avenir, mais pourquoi jQuery c'est le mal ? J'ai raté un épisode ?

C'est surtout 2 éléments qui n'ont pas vraiment de rapport.
NPM c'est très pratique pour gérer les dépendances de projet mais c'est tout, derrière tu utilises ce que tu veux comme lib/framework (comme l'a souligné Max_well, tu peux tout à fait installer jQuery avec NPM).

jQuery c'était bien y'a 7-8 ans quand on n'avait rien d'autre sous la main, mais maintenant c'est complètement dépassé maintenant.
Si tu veux avoir du code clair, bien architecturé et maintenable, faut clairement passer à autre chose.

Surtout, que même pour les petits projets perso, y'a maintenant des framework léger de très bonne qualité qui fournissent tout ce qu'il faut (Vue.js par exemple).

[PaulPoy]

Autant je peux comprendre que NPM c'est l'avenir, mais pourquoi jQuery c'est le mal ? J'ai raté un épisode ?

JQuery est un gros couteau suisse quand souvent on aurait juste besoin de quelques petits outils dédiés.
Puis ça peut amener à prendre quelques mauvaises habitudes sur des choses qui pourrait être faites tout aussi bien et facilement en js pur (cf le lien vanillajs plus haut).

[Mayalabielle]

C'est surtout 2 éléments qui n'ont pas vraiment de rapport.
NPM c'est très pratique pour gérer les dépendances de projet mais c'est tout, derrière tu utilises ce que tu veux comme lib/framework (comme l'a souligné Max_well, tu peux tout à fait installer jQuery avec NPM).

jQuery c'était bien y'a 7-8 ans quand on n'avait rien d'autre sous la main, mais maintenant c'est complètement dépassé maintenant.
Si tu veux avoir du code clair, bien architecturé et maintenable, faut clairement passer à autre chose.

Surtout, que même pour les petits projets perso, y'a maintenant des framework léger de très bonne qualité qui fournissent tout ce qu'il faut (Vue.js par exemple).

Maintenir la cohérence d'une page très dynamique avec jQuery c'est le suicide avec Vue.js, c'est la promenade de santé.

[tenshu]

Autant je peux comprendre que NPM c'est l'avenir, mais pourquoi jQuery c'est le mal ? J'ai raté un épisode ?

Comme l'on dit les canards au dessus npm est un gestionnaire de dépendances.
J'ai bien dit : piocher dans tout ce que peut offrir npm.
Donc utiliser des micro dépendances, plutôt que l'ogre qu'est jquery.



Et puis c'est fun de devoir choisir une librairie parmi les 50 qui font la même chose
Puis de changer dans 3 mois par ce qu'une nouvelle aura tout réécrit en mieux avec la pattern à la mode

[Mayalabielle]

Et puis c'est fun de devoir choisir une librairie parmi les 50 qui font la même chose
Puis de changer dans 3 mois par ce qu'une nouvelle aura tout réécrit en mieux avec la pattern à la mode

Chapeau à ceux qui ont assez de temps libre pour faire ça

[PaulPoy]

Si j'aime bien m'y plonger dedans, faut reconnaître que l'écosytème est bordélique.

[Mayalabielle]

Si j'aime bien m'y plonger dedans, faut reconnaître que l'écosytème est bordélique.

https://pbs.twimg.com/media/C90PKzFWsAAyims.jpg

J'ai explosé de rire, je la garde celle la

[Gillete]

Ah oui, voilà c'est comme ça que je le comprenais : jQuery est overkill et il vaut mieux utiliser NPM pour aller piocher les librairies utiles à notre projet.
Là clairement j'avais la flemme de faire ça pour mon POC

[Orhin]

Non mais surtout, quitte à prendre un truc overkill qui fait tout, autant partir sur un gros framework type Angular ou React.
Au moins ça permettra d'avoir un projet propre derrière.

[Awake]

J'ai pas trop suivi la hype javascript de ces dernières années, j'utilise toujours jQuery. Sauf que j'ai un peu de bouteille donc j'arrive à garder qqchose de propre.

Mais du coup npm je l'ai utilisé qu'en backend, pour faire tourner gulp par exemple. Pour l'utiliser en front vous faites comment ? Faut utiliser browserify ou similaire ? Parce que c'est quand même vachement plus galère à installer que d'appeler un script sur un cdn et commencer à coder.

Autre question, y'en a ici qui utilisent TypeScript ? Cay bien ? Pas trop de problèmes de perfs avec la transpilation ?

[tenshu]

Avec http://requirejs.org par exemple.

[Awake]

Je regarde la doc mais je vois pas comment faire passer les fichiers js de npm vers le browser.

[Sekigo Le Magnifique]

Ça va t'installer les fichiers dans un dossier node_module.
Soit tu importes directement le fichier JS via une balise script, en utilisant le dossier node_module (mais je ne pense pas que ce soit vraiment recommandé).
Soit tu utilises un compilateur qui va marchouiller plus ou moins pour ressortir un seul fichier.

[Awake]

Importer directement les fichiers node_module ça risque pas de marcher, les browser ne fonctionnent pas avec des dépendances.

Personne n'a un exemple simple et concret à montrer ? Tous les libs js tournent sous npm de nos jours, ça doit pas être bien sorcier de les rendre utilisable dans le navigateur.

[Calys]

Autre question, y'en a ici qui utilisent TypeScript ? Cay bien ? Pas trop de problèmes de perfs avec la transpilation ?

C'est bien, surtout pour les gros projets où plusieurs personnes travaillent dessus, le typage est bien pratique et évite pas mal de prise de tête.
Le fait d'avoir un "vrai" langage objet est aussi bien pratique pour bien structurer son code.

Point de vue perf ça doit être quasi équivalent à du javascript classique, au final TypeScript n'apporte pas grand chose au langage (on est très loin de Scala.js par exemple), les types sont vérifiés uniquement à la compilation, et le code compilé est finalement très très proche de sa version TypeScript.

- - - Mise à jour - - -

Importer directement les fichiers node_module ça risque pas de marcher, les browser ne fonctionnent pas avec des dépendances.

C'est ta tâche Gulp browserify/requirejs/TypeScriptCompiler qui va récupérer ce qu'il faut dans ton dossier 'node_modules' pour les concaténer avec ton script dans un seul fichier javascript

[Mayalabielle]

C'est ta tâche Gulp browserify/requirejs/TypeScriptCompiler qui va récupérer ce qu'il faut dans ton dossier 'node_modules' pour les concaténer avec ton script dans un seul fichier javascript

webpack, pour être au top de la hype.

[Sekigo Le Magnifique]

Importer directement les fichiers node_module ça risque pas de marcher, les browser ne fonctionnent pas avec des dépendances.

La différence avec un truc genre webpack, c'est que ce dernier va basiquement fusionner tous tes fichiers js en un seul fichier disponible dans ./build/buid.min.js (j'ai oublié le nom exact). Tu peux faire ce boulot à la main (dans mon exemple, j'utilise jquery, si on avait téléchargé d'autres trucs, on peut les incorporer comme je l'ai fais), même si c'est long et fastidieux.

[PaulPoy]

J'aime bien ta console ^^

Ouais les modules qui ont un sens côté browser sont j'imagine généralement fournis avec des fichiers de distribution.
Ce que tu fais là, même avec Webpack et cie il faudra le faire mais ailleurs, sous une forme différente (require, import...).

Il y a Bower aussi pour la partie front. Mais ça commence à être de l'inception là.

[Mayalabielle]

J'aime bien ta console ^^

Ouais les modules qui ont un sens côté browser sont j'imagine généralement fournis avec des fichiers de distribution.
Ce que tu fais là, même avec Webpack et cie il faudra le faire mais ailleurs, sous une forme différente (require, import...).

Il y a Bower aussi pour la partie front. Mais ça commence à être de l'inception là.

C'est effectivement très facile de se perdre dans la tempête de buzzwords et de noms

[Awake]

Il semblerait qu'il n'y ait plus le choix que de passer par npm si on veut pas passer pour un vieux crouton... Symfony va mettre en place webpack avec Encore qui a l'air assez simple d'utilisation, je vais commencer par là.

C'est bien, surtout pour les gros projets où plusieurs personnes travaillent dessus, le typage est bien pratique et évite pas mal de prise de tête.
Le fait d'avoir un "vrai" langage objet est aussi bien pratique pour bien structurer son code.

Point de vue perf ça doit être quasi équivalent à du javascript classique, au final TypeScript n'apporte pas grand chose au langage (on est très loin de Scala.js par exemple), les types sont vérifiés uniquement à la compilation, et le code compilé est finalement très très proche de sa version TypeScript.

Merci pour le retour ! Je vais regarder ça de plus près, parce que du vrai objet (même si c'est possible de faire similaire avec le prototypage) et le typage me manquent cruellement en js.

Mais vos posts confirment ce que je pensais, mettre en place npm et compagnie dans un projet est quand même beaucoup plus complexe que la méthode à l'ancienne.

[Orhin]

C'est plus complexe si tu pars de rien.
Si tu utilises les outils de builds fournis par les framework, t'as absolument rien à faire.

Pour intégrer une nouvelle lib, tu fais juste un :
npm install --save nom_librairie

Tu l'importes là où tu veux l'utiliser (sachant qu'un bon IDE comme Webstorm se chargera lui même d'ajouter les imports) et c'est tout.

D'ailleurs NPM n'oblige pas à ce que la librairie soit dispo sur leur repository (npmjs.org), tu peux très bien l'utiliser en utilisant directement une ressource accessible via git ou http.
Très pratique pour les lib sur github non intégrées dans NPM ou pour les projets privés d'une entreprise.


Pour Typescript, perso c'est devenu obligatoire sur tous mes projets web.

La différence avec un truc genre webpack, c'est que ce dernier va basiquement fusionner tous tes fichiers js en un seul fichier disponible dans ./build/buid.min.js (j'ai oublié le nom exact). Tu peux faire ce boulot à la main (dans mon exemple, j'utilise jquery, si on avait téléchargé d'autres trucs, on peut les incorporer comme je l'ai fais), même si c'est long et fastidieux.

Webpack fait plus que ça :
- code splitting : après avoir merge toutes tes ressources, permet de les séparer dans des bundle distincts qui peuvent être chargé indépendamment dans ton appli => amélioration du temps de chargement
- tree shaking : élimine le code non utilisé => réduit la taille des bundle
- hot module replacement : permet de remplacer un module de ton appli au runtime sans devoir la recharger intégralement => très pratique pour le dev

[Mayalabielle]

C'est plus complexe si tu pars de rien.
Si tu utilises les outils de builds fournis par les framework, t'as absolument rien à faire.

Pour intégrer une nouvelle lib, tu fais juste un :
npm install --save nom_librairie

Tu l'importes là où tu veux l'utiliser (sachant qu'un bon IDE comme Webstorm se chargera lui même d'ajouter les imports) et c'est tout.

D'ailleurs NPM n'oblige pas à ce que la librairie soit dispo sur leur repository (npmjs.org), tu peux très bien l'utiliser en utilisant directement une ressource accessible via git ou http.
Très pratique pour les lib sur github non intégrées dans NPM ou pour les projets privés d'une entreprise.


Pour Typescript, perso c'est devenu obligatoire sur tous mes projets web.


Webpack fait plus que ça :
- code splitting : après avoir merge toutes tes ressources, permet de les séparer dans des bundle distincts qui peuvent être chargé indépendamment dans ton appli => amélioration du temps de chargement
- tree shaking : élimine le code non utilisé => réduit la taille des bundle
- hot module replacement : permet de remplacer un module de ton appli au runtime sans devoir la recharger intégralement => très pratique pour le dev

C'est un peu le problème de Webpack, quand tu vois ce machin pour la première fois "heu, c'est quoi le scope de ce tool ?"

[tenshu]

Perso ça me fait ça avec 80% de ce qui sort en JS.
Je vois passer le nom, j'ouvre le site officiel, je lit la description du produit (quand elle existe), je comprends rien, j'ouvre la doc, je vois a peu près à quoi ça doit servir, j'ai toujours aucune idée de si c'est ce qu'il me faut ni comment l'utiliser concrètement.

[PaulPoy]

Il semblerait qu'il n'y ait plus le choix que de passer par npm si on veut pas passer pour un vieux crouton... Symfony va mettre en place webpack avec Encore qui a l'air assez simple d'utilisation, je vais commencer par là.
Merci pour le retour ! Je vais regarder ça de plus près, parce que du vrai objet (même si c'est possible de faire similaire avec le prototypage) et le typage me manquent cruellement en js.
Mais vos posts confirment ce que je pensais, mettre en place npm et compagnie dans un projet est quand même beaucoup plus complexe que la méthode à l'ancienne.

La mode en ce moment semble se porter sur Webpack (automatisation) + NPM (listing des tâches d'exécution).

Et si tu veux du typage avec JS mais juste ça, Facebook a pondu son propre outil Flow.

[Mayalabielle]

La mode en ce moment semble se porter sur Webpack (automatisation) + NPM (listing des tâches d'exécution).

Et si tu veux du typage avec JS mais juste ça, Facebook a pondu son propre outil Flow/.

Et encore, npm est de plus en plus remplacé par yarn, pour la gestion des deps (il faut l'avouer, c'est quand même carrément plus rapide)