Javascript today

[niahoo]

Hello,

Il y a une librairie sympa en javascript qui s'appelle React [1]. J'ai fait un mini projet avec et c'est très sympahique. Mais ce n'est pas de ça dont je veux parler. Les développeurs de cette lib (Facebook/Instagram) proposent un modèle de développement browser-side qui me semble conceptuellement très sympa.

Mais à la lecture de leur article [2], il se trouve qu'ils utilisent plus d'outils javascript que je ne connais pas que d'outils javascript que je connais.

Aujourd'hui pour pouvoir utiliser les outils à notre diposition il faut connaitre node/npm bien sur, mais aussi broserify, gulp, bower, et 50 autres.

ça commence à être relou je trouve parce que bien sûr une librairie va choisir gulp et une autre lib va prendre un autre script de compilation. Si bien qu'au final je me sens totalement perdu et je finis toujours par utiliser des scripts à l'ancienne (déjà "buildés") que je peux mettre dans mon browser directement (ou bien sur les compacter en un seul script). C'est très gavant. le seul truc uniformément utilisé c'est npm.

Comment faites vous ? pouvez-vous me citer votre stack complète (browser side) pour un projet complexe de votre choix ?

Je finirais cependant sur Une touche d'humour !

[Ter Rowan]

je vais pas parler de mes dev perso, vu que je suis amateur mais d'un point de vue pro, j'encadre deux types de développeurs (la majorité presta) :

ceux qui vont toujours utiliser les mêmes librairies, jusqu'à ce qu'on leur impose un nouveau
ceux qui vont tout essayer tous les trois mois (genre foundation +knock out, et puis finalement bootstrap + angular, mais peut être qu'en essayant blablabla on arriverait a)

dans les deux cas c'est le binz. Après les dev qui proposent leur framework le font aussi pour être des leaders reconnus, donc forcément ils vont te pondre le dernier truc qui vient de sortir histoire de montrer que eux ils connaissent les librairies que toi tu ne connais pas

je pense qu'il faut rester assez rigoureux pour garder (après tests) trois ou quatre librairies / framework max pendant quelques années, sinon on est juste dans le rien maitriser, maintenance complexe, etc etc


deux remarques sinon. Jquery est (du moins dans ma boîte) un incontournable.
On peut faire sans js côté serveur (donc ton "bien sûr" je répondrais "ou pas")



et j'aime bcp la page , même si ce n'est pas que de l'humour mais aussi le réel a mon sens

[niahoo]

Merci pour ta réponse. Effectivement c'est ce que je compte faire, me choisir une stack pas trop volumineuse et rester dessus pour la maîtriser. Mais justement chaque élément de cette stack utilise différents outils de build qu'il faut connaître, ça "tire la couverture" dans tous les sens En fait j'essaie de trouver mes limites dans ce que je prends de différent qui fait parfois (mais jamais entièrement) les mêmes choses.

Pour npm et node, je ne fais pas de js côté serveur. mais ces outils sont utilisés par la majorité des outils de build (puisque écrits en javascript et que node permet d'exécuter ce js dans la console pour les build/compilation/minifications/...) et npm est le gestionnaire de paquets tant pour le browser que le serveur.

[Aedius]

Je suis d'accord avec Ter Rowan actuellement JQuery est incontournable ( ce qui n'était pas le cas il y a genre 5 ans où il se disputait la vedette avec mootools )

Après, les outils ...

Personnellement (et au boulot) on part du framework / plugins / outils / bouzin qui ressemble le plus à ce qu'on doit obtenir à la fin et on adapte avec des jeux de bonus / malus , quelqu'un connait ? bonus, "on s'est déjà cassé la gueule avec ?" : Malus ... Et on prends la meilleur note.

en général juste avec ce premier gros morceau, tu as plus trop de choix.

[Sephi-Chan]

J'ai de plus en plus de mal avec le côté monolithique de jQuery, d'autant que j'en utilise très peu, encore plus dans mes single page apps (Backbone, Angular, etc.). J'espère que Backbone (et par extension Marionette) se débarrassera de sa dépendance à jQuery au plus vite.

Pour ce qui est de la stack avec Bower et Grunt/Gulp, je l'ai expérimentée et je la trouve plutôt bonne. Elle offre l'avantage de pouvoir s'intégrer avec n'importe quel framework et langage. En contrepartie, c'est moins intégré (que l'assets pipeline de Rails, par exemple), mais j'aime de plus en plus l'idée de ne pas mettre tous mes œufs dans le même pannier.

Je passerais volontiers à ça pour tous mes projets quand j'aurais trouvé de bonnes solutions pour réécrire automatiquement les paths (que ce soit dans les url() du CSS, les attributs src des balises HTML script/img, etc) par la version digest de mes assets (transformer /path/to/img.png en /path/to/img-5e7247.png) lors d'une release en production.