Juste pour signaler que le lien vers ES6 est mort. Mais dans tous les cas, la communauté francophone a réalisé de bonnes traductions de ces articles en français : https://tech.mozfr.org/tag/ES6%20en%20d%C3%A9tails !
Je vais essayer de retrouver le bon lien du coup. Je prend note de la version Française comme "officieuse".
Je viens aussi de tomber sur cet article qui compare les performances de React à celles du JS vanilla. Quand React se vante d'améliorer les performances, visiblement la vérité est un peu différente…
NW est peu connu, mais pourtant pas mal utilisé. Et puis rappelle-toi que Node.js est resté très longtemps en bêta alors qu'un tas d'entreprises l'utilisaient en production.
Quant aux propositions de DigitalSuricate, elle sont bien vues : mustache est une syntaxe très connue et utilisable dans beaucoup de langages. Handlebars n'est (plus ou moins) qu'une implémentation en JS…
Yeoman fait pas mal parler de lui récemment, mais j'ai pas encore eu l'occasion de tester (et puis le principe des générateurs est pas trop mon délire, je préfère garder le contrôle).
Le problème est que ton sujet est mal posé. Entre "inconnue au bataillon" comme un script que toi tu as put faire et "de référence" (comme "node.js" que tu cite) il y a un monde. D'autant que JS est très utilisé dans de petites entreprises ou startup. On peut probablement facilement trouver des boites qui utilise la majorité des lib existantes sur npm par exemple.
Précisons que NW, un peu comme PhoneGap, ce fait pas vraiment du natif mais package le JS dans un exécutable classique. Mais pour desktop (plutôt que du mobile comme PhoneGap) et en intégrant à la fois un WebKit complet et Node.js (ce qui permet de contrôler à la fois le rendu via WebKit et d'accéder aux APIs système via Node).
Je dirais plutôt "hybrides" en l'occurrence mais il me semble que le terme est plutôt utilisé pour les outils orientés mobile comme PhoneGap dont tu parles
C'est ça. PhoneGap intègre des APIs pour utiliser les fonctions natives (via des plugins pour le coup), là où Node-WebKit se contente de réunir WebKit et Node.js. PhoneGap n'intègre pas tout ça (d'où les problèmes de compatibilité sur mobile, d'ailleurs)…
Moi je propose aussi XUL, de Mozilla. XUL en tant que tel est du XML, mais qui s'utilise avec du JavaScript et une API ad-hoc, pour faire des extensions pour Firefox ou des logiciels reposants sur la runtime (XULRUnner) de Firefox.
Sinon, niveaux frameworks, on a aussi Mootools, ou Sencha Ext JS
Et niveau IDE, je conseille ceux de JetBrain, notamment WebStorm (orienté Web avec JS et Node.js).
Niveau débug pour les navigos, la référence reste Firebug, bien que les différents navigos implémentent quasiment tous de base des outils similaires (mais toujours un brin en dessous, en fonctionnalité et en ergonomie).
Mmh pour XUL il s'agit quand même d'une techno à l'abandon, qui se meurt. Le XUL est supprimé au profit du HTML5 (même si des fonctionnalités de XUL sont encore pratique hein)
Mmh pour XUL il s'agit quand même d'une techno à l'abandon, qui se meurt. Le XUL est supprimé au profit du HTML5 (même si des fonctionnalités de XUL sont encore pratique hein)
Je n'en suis pas si sûr. Pour la création d'extensions simples, oui. Mais pour les trucs poussés qui ont besoin d'autant de fonctionnalités que Firefox, le XUL reste nécessaire.
Sinon en éditeur je proposerais bien Sublime Text (avec quelques plugins éventuellement), sinon Visual Studio Code est pas mal pour faire du Node.js (avec git intégré en prime).
Autrement j'ai pas trop suivi Firebug depuis un certain temps, mais les DevTools de Chrome (que l'on peut retrouver un peu partout, que ce soit dans PhoneGap Build ou NW.js, du moins partiellement) sont vraiment pas mal je trouve.
Par contre c'est quoi l'apport d'XUL comparé à du XML classique ou des WebComponents ?
Je suis pas forcément d'accord pour dire que Firebug reste la référence des devtools, qu'est-ce qu'il a de plus que les devtools intégrés à Firefox par exemple (je connais pas trop ceux des autres navigateurs donc je me prononce pas) ?
Pour moi la devtools par défaut de Chrome vaut bien celle de Firebug, enfin je dis surement ça parce-que je n'utilise pas les fonctions avancées de Firebug …
Le XUL est fait pour structurer des interfaces flexibles et il ne le fait pas mal (même si c'est quelque fois un peu verbeux). Le HTML a encore du mal avec ça (la solution c'est flexbox). XUL gère ça de base. Maintenant, XUL reste limité aux applications Mozilla, au contraire d'HTML 5. Et de ce que je sais de WebComponents, c'est un truc un peu raté. D’ailleurs, XUL propose XBL, un langage XML qui permet de définir ses propres éléments, un peu comme WebComponents, avec aussi un shadow DOM.
Mouais le problème du topic c'est le problème de "l'écosystème JavaScript" en tant que tel.
Y'a pas de standard de fait (ou très peu, uniquement les ECMA N), et l'historique du langage et son utilisation font que les gens ont énormément tendance à faire leur petit machin dans leur coin sans qu'une grosse fondation organise un peu tout ça.
Ca change un petit peu, avec les mastodontes du web qui prennent les choses en main (AngularJS 2 made in Typescript donc made in Google + Microsoft, en prenant un gros raccourci qui tâche), Facebook propse React qui est très séduisant mais nécessite de franchir un sacré cap quand les applications se compliquent (et aller fouiller du côté de l'architecture "Flux" et "Immutable", sans quoi on se prend encore plus la tête qu'avec les scope d'Angular).
Certains ont parlé de déclaration de dépendances, là encore pas ou peu de standard… ECMA 6 essaie d'en introduire un, on verra ce que les navigateurs en font mais d'ici là c'est soit le format AMD soit le format commonjs, respectivement implémentés par requireJS et node (pour la faire courte… Webpack gère les deux par exemple, browerify repose sur commonjs).
Bref, "l'écosystème" JS est son plus gros défaut à mon sens. "On va pas se plaindre d'avoir le choix ?!" Bah en fait… Si un peu… Et ce sujet va finir en une liste interminable de technos plutôt sympas mais dont l'avenir est complètement incertain sauf pour un très petit nombre (on doit pouvoir penser que node s'impose comme un standard aujourd'hui, jusqu'au jour où un concurrent trouvera le moyen d'avoir de meilleurs performances…).
Bon courage firm1, mais je pense que la liste va inévitablement virer au capharnaüm parce que c'est malheureusement la nature de cet écosystème, difficile de ranger des trucs dans des cases :\
C'est pour ça que je n'utilise quasiment que le JS de base, car dépendre de technos/libs tierces incertaines est une mauvaise chose. On a a déjà discuté ailleurs, même Node.js souffre du problème : au lieu de créer un "noyau" solide et ben complet, Node.js repose sur des certaines de modules développés à tout va, et dont la plupart ne sont jamais complets et ne sont déjà plus mis à jour.
Chacun fait son petit script dans son coin, son petit framework, pour palier les lacunes/manquements du JS de base. Si JS était correctement encadré, des choses comme jQuery ne devraient même pas exister. Mais JS est limité par sa nature même de langage de script interprété, au bon vouloir des navigateurs, ce qui freine considérablement son évolution.
Connectez-vous pour pouvoir poster un message.
Connexion
Pas encore membre ?
Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte
On s'est de toutes façons que tout le monde triche 
