Discussion :

[melka one]

je voit javascript comme un langage de programmation simple et c'est tout après au niveau syntaxe pour moi c'est dans la ligné du C, ensuite vient l’épineuse partie qu'est la poo par prototype qui est peut rependu et qui au passage serait sur le papier meilleurs que la poo par class d’où encore un sujet a controverse

ce qui est propre au langage et qui me plait c'est la philosophie de gerer la plus part des chose comme des objets (le point est ton amis) que je prefere par exemple au php ou beaucoup se fais avec des fonctions et les parrametres

[reviretan]

Petit troll du weekend.

Je sais pas vous mais moi, j'ai jamais réussi à faire fonctionner NodeJS du premier coup. Que ce soit sur Linux, Mac ou Windows. La pire galère dans chacun de ces environnements.

Pire, NPM. Je n'ai jamais réussi à installer un seul paquet npm sans avoir d'erreurs dans les logs. aucune idée si ces erreurs sont normales, à part en testant directement le paquet installé.

Ci-dessous un screenshot de l'installation de yeoman, je suis loin d'être sysadmin mais quand tu es root, tu peux vraiment avoir des permissions denied? o_O C'est la première fois que ça me le fait

[ABCIWEB]

@SylvainPV C'est comme dans tout, il faut avoir le déclic. On est dans deux contextes différents: tu as déjà eu le déclic, et moi pas encore. Je vois ce langage avec un œil extérieur.

Pour ma part ce n'est pas un déclic qui s'est produit mais la nécessité d'avoir des fonctionnalités dynamiques côté client. C'est un complément indispensable de la programmation côté serveur si on veut avoir un site agréable à consulter. Et de même je trouve également cela plus ludique car cela interfère directement sur la présentation, l'ergonomie, le visuel, contrairement à la programmation côté serveur, qui schématiquement est une boite noire qui retourne "simplement" le bon résultat d'une requête

[reviretan]

Pareil, je sais faire un site dynamique côté client, j'ai déjà joué avec angularJS, jQuery, même Backbone j'ai testé

Par contre, je n'ai jamais réussi à être à l'aise en JS. Je sais manipuler le dom, utiliser une libraire, un framework. Mais je suis jamais satisfait du code que j'écris.

[ABCIWEB]

Par contre, je n'ai jamais réussi à être à l'aise en JS...

C'est les inconvénients des avantages. La programmation événementielle est plus longue à appréhender/développer car elle est asynchrone, contrairement à un langage serveur classique comme php. Avec le temps on s'habitue, mais je ne peux pas dire que je vais aussi vite qu'avec php malgré de nombreuses années et le fait que je développe aujourd'hui plus de js que de php. Peut-être ceux "qui sont nés avec" iront plus vite mais je doute qu'ils aillent aussi vite qu'en programmation synchrone, simplement parce qu'il y a plus de choses à penser.

[SylvainPV]

JavaScript a beau être un langage haut niveau, il reste très compliqué à apprendre et maîtriser. J'en fais depuis plus de dix ans et j'ai l'impression de le réapprendre tous les ans :
- au début je faisais du simple code procédural, impératif
- ensuite je suis passé à l'OOP classique pour mieux organiser mon code
- puis en travaillant avec backbone et node.js je me suis mis à la prog évenementielle et aux promises
- après quoi j'ai appris à maîtriser davantage les closures et la chaine prototypale, pour arriver à un autre style d'OOP (héritage prototypal alias OLOO)
- ces derniers mois je découvre la prog réactive avec Rx et Bacon

On peut aussi mentionner la prog fonctionnelle, les monades, et tous les autres design patterns et antipatterns. Sans oublier ES6 qui arrive cette année avec plein de nouveautés.

Bref il faut pas se sentir honteux de ne pas maîtriser le langage, il faut s'attendre à ce qu'un langage dynamique multi-paradigme comme JavaScript parte dans plein de directions différentes. Je pense qu'avec le temps on finira par trouver les meilleurs compromis dans tous ces concepts, et qu'on les concrétisera soit dans un nouveau JavaScript non rétrocompatible, soit dans un langage alternatif pour le remplacer (compilant en wasm ?). En attendant, 20 ans après que le langage ait été créé on continue toujours à expérimenter avec Et moi j'adore ça !

[reviretan]

@Sylvain: je fais aussi de la programmation fonctionnelle avec Scala, Groovy, Java 8. J'ai aussi eu l'occasion de faire la prog réactive avec Rx(qui, me semble-t-il, a été développé en scala au départ), vraiment sympa! d'ailleurs, si tu veux refaire un peu de java/scala un jour, je te conseille le framework Camel (en java), qui je pense est encore plus poussé que Rx

J'en profite au passage pour exprimer ma frustration ici, après deux heures de lutte avec les générateurs yeoman (angular et gulp-angular) qui me font pense que j'aurais été plus vite en dézippant directement un template de projet angular...

Pour installer le générateur, il n'y a qu'une ou deux lignes de commande à exécuter. Pourtant, je continue encore et encore à avoir des erreurs dans mes logs, la commande grunt serve ne fonctionne pas après avoir générer mon projet, la commande gulp serve non plus... Des dépendances manquent, que je dois installer à la main. Et même quand tout est installé je n'arrive pas à builder le projet! Le genre d'erreurs que j'avais en 2005, quand les "freeware" comme on les appelait à l'époque étaient écrit par des amateurs, n'était pas maintenu, mal documenté et loin d'être stable. Mon sentiment, quand j'installe une lib JS est le même que quand j'installe un crack pour un jeu video: 50% de chance que ça marche.

C'est aussi au fond ce que je reproche au monde JS, un peu trop d'amateurisme.Mais au fond, c'est ptet justement dû à mon manque de compétence dans le domaine

Edit: je viens de trouver la possible root cause de mes problèmes, lié à une version de node ou de npm trop récente... pour faire fonctionner mes générateurs, je dois installer une version antérieure de node et npm -_- et encore, c'est pas sûr que ça marche >_<

[reviretan]

http://www.allenpike.com/2015/javasc...ework-fatigue/

[SylvainPV]

Une bonne réponse à la fameuse complainte "y'a trop de frameworks en JS":

[reviretan]

J'ai arrêté la vidéo quand il dit "Si Javascript a autant de frameworks, c'est parce qu'il a un gestionnaire de paquet (npm) et grâce à
github, si c'est pas le cas de votre langage, c'est que votre langage n'est pas populaire / n'a pas de gestionnaire de paquets"

Tout les langages ont un gestionnaire de dépendances, javascript a à peine deux jours qu'il croit déjà avoir inventer l'eau chaude.
C'est juste que sur les autres plateformes, les frameworks viennent et disparaissent bien plus lentement.

Ca n'est pas juste le nombre de frameworks qui sortent,
c'est aussi l'instabilité constante de la plateforme, le fait d'avoir en production des versions 0.0.2.13,... Voir l'article publié ci-dessus.

[SylvainPV]

On ne parle pas de gestionnaire de dépendances mais de dépôt central ouvert. Avec NPM chacun peut s'attribuer un namespace public et universel très facilement, c'est loin d'être le cas pour tous les langages.

Moi j'ai arrêté de lire ton article quand il s'est plaint que Riot 2.0 ne pouvait pas exister parce qu'il était basé sur React qui lui n'était pas encore en 1.0. Comme si Riot devait gentiment attendre son tour juste parce qu'il reprend quelques bonnes idées de Facebook exposées publiquement en 2013

Si des gens veulent utiliser des versions 0.0.2.13 en production, c'est leur problème. Personne ne les oblige à utiliser des libs non finies aux API instables. Il existe bien d'autres stacks JavaScript stables et éprouvées depuis des années.

[reviretan]

Ahaha bon point pour Riot.js, je suis d'accord, si les mecs veulent pomper ils en ont le droit mais bon, ils sont déjà en 2.0 hein... et react a même pas atteint la première release.

Tu connais de bons frameworks stables en JS? Si tu peux m'en conseiller un, pour réaliser un site onePage à la angular, tu me conseillerais lequel?

Parce que angular en V2 est incompatible avec la V1, je vois pas l'intérêt de continuer à dev en 1.X. Y a polymer aussi qui a l'air pas mal, mais seulement en 1.0.

J'ai voulu testé Vue.js, mais ils n'ont pas encore releasé leur première version.

C'est pas pour débattre, j'ai vraiment besoin d'un petit framework pour attaquer mon backend rest, mais je veux pas me lancer dans un truc trop compliqué ou instable.

j'ai déjà testé Backbone, une horreur. Angular est cool, mais j'ai pas envie d'attendre la v2. jamais compris ember.js. je suis en quête

Sinon, bah faudra me citer un langage qui n'a pas le concept de repo/dépôt/whatever you want. en java par exemple t'as maven & gradle, SBT pour scala. En .NET t'as new-get, même si c'est pas l'meilleur.

[SylvainPV]

Riot a une base de code plus de 10 fois plus petite que React, et eux ne cherchent pas à révolutionner le monde avec des IDE React, du React Native et des outils React dans tous les sens. Ça n'a aucun sens de comparer l'avancement de ces deux projets, c'est comme vouloir comparer le temps de conception d'un Boeing et celui d'un biplan parce que les deux ont des ailes et savent voler...

Backbone est un framework stable et éprouvé, très utilisé dans le monde professionnel. Je voudrais bien savoir pourquoi tu le considères comme une "horreur" mais étant donné tous les projets réussis qu'on a fait avec dans ma boîte, je suppose que tu ne sais pas l'utiliser correctement ou que tu n'aimes pas la programmation événementielle.

Aussi, si tu considères que Angular n'est pas stable parce qu'ils font une V2, alors ça veut dire que n'importe quel outil souhaitant évoluer est considéré comme instable pour toi. Si on lui donne un nouveau nom, ça résout le problème ? Des centaines voire des milliers de projets pros à gros trafic tournent en ce moment avec Angular 1.x et leur plan de support est très rigoureux sur les prochaines années. Moi j'appelle ça un framework stable. Ce qui n'est pas stable en revanche, c'est la beta de Angular 2, raison pour laquelle mon prochain gros projet professionnel partira sur Angular 1.4.

SBT et gradle ne sont pas des dépôts centraux, tu confonds avec les package managers. Maven est un bon exemple en revanche: gestionnaire de paquets populaire + langage populaire = plein de modules. Mais il y a beaucoup de repos Maven privés dans le monde de l'entreprise, ce qui fait qu'on n'a pas la même quantité de projets publics open-source que pour JavaScript. Sans doute parce que JS est naturellement "exposé" dans le navigateur. Il y a peu de langages où l'on peut récupérer les sources d'un projet avec un simple F12.