Personnellement j'adore JavaScript, c'est pour moi le langage le plus abouti qui soit à l'heure actuelle. Mais il faut bien comprendre que depuis le début il essaye de se faire passer pour ce qu'il n'est pas.
JavaScript est un langage prototypal, mono thread orienté vers la programmation événementielle. Et c'est tout. Pour tout un tas de raisons on lui a donné une syntaxe aussi proche du C++/Java que possible - alors qu'il est plutôt proche des langages fonctionnels. On va dire que ça a grandement aidé à son adoption (c'est pas Erlang ou Racket qui peuvent prétendre avoir réussi à séduire les foules même si ils sont meilleurs sur bien des points).
Maintenant il faut bien comprendre qu'il s'agit de maquillage. En JavaScript vous avez des Scopes (ou états si vous préférez) qui contiennent des paramètres qui peuvent eux mêmes être des scopes. Ces scopes se partagent un temps d’exécution sur un seul thread en utilisant des évènements pour se passer la main les uns aux autres. Voilà c'est tout. Il y a tout en haut des prototypes qui peuvent servir de moules, c'est pratique mais pas franchement essentiel. Ça évite de devoir se fader une lib en plus pour la gestion des tableaux et des chaines principalement.
Tout le reste, et ça inclue les notions de variables, d'objet, de fonction etc, ne sont que des postiches pour faire plaisir aux codeurs C/C++/Java.
Une fois qu'on a compris ça, on arrête de coder en JavaScript comme si il s'agissait d'un langage procédural, et ça va beaucoup mieux.
Après concernant la multitude de bibliothèque en pré-alpha, c'est vrai que npm+GitHub n'a pas simplifié la tache. On manque en Javascript d'une bibliothèque standard. Mais à moins que vous soyez en train de coder un shell ou un système d'init en JS (là on crache du sang, je confirme), on trouve toujours d'excellente libs qui facilitent le boulot dans des proportions hallucinantes. J'ai écrit une interface console pour le pilotage et le monitoring d'appareils via TL1 ou SNMP en quelques heures (et encore parce que je ne connaissais pas bien TL1).
Après il y a des limitations, pour la crypto, le temps réel (même mou) ou le calcul massivement parallèle (les workers c'est bien, mais jusqu'à un certain point), c'est clairement pas le bon langage.
Mais clairement un langage de script qui permet en quelques centaines de lignes d'encaisser et d'envoyer des millions de traitement par seconde tout en restant lisible et debugable et en prenant moins de 100Mo tout compris en exécution - il y en a quand même pas des masses.
Et ensuite il y a des produits dont je ne peux plus me passer en JavaScript. PEG js par exemple - ou D3 js même si il est parfois incohérent avec lui même - ou Blessed
Alors certes ce n'est pas le langage parfait, son plus gros défaut étant les comportement singulier de certaines fonctions suivant que vous soyez en mode exécution (normal) ou en mode évaluation (console de debug navigateur par exemple) CF Understanding delete
Mais les incohérences sont tellement faibles comparées aux autres langages, à moins de faire du Haskell, ca va être dur de trouver un langage raisonnablement moderne et ouvert sur l'extérieur (capable de gérer des I/Os de façon un poil intuitive) qui soit meilleur à ce niveau là.
Après oui, pas mal de gens ont du mal avec la gestion par évènements et se retrouve piégé dans un callback hell, ou à devoir faire des promesses de promesses. Et on est en train de créer des tonnes de sucre syntaxiques pour que les fans de C++/Ruby puissent utiliser leur habitudes de programmations sans dégommer les perfs.
Tant mieux si ça ramène des gens en plus sur le langage. Mais je suis très content en ES5 avec du Q(pour le prototypage)/Bluebird (pour la production), du lodash et les outils précités pour l'habillage.
# Opinion personnelle
Posté par Kaane . En réponse au journal Et si JavaScript allait droit dans le mur ?. Évalué à 10.
Personnellement j'adore JavaScript, c'est pour moi le langage le plus abouti qui soit à l'heure actuelle. Mais il faut bien comprendre que depuis le début il essaye de se faire passer pour ce qu'il n'est pas.
JavaScript est un langage prototypal, mono thread orienté vers la programmation événementielle. Et c'est tout. Pour tout un tas de raisons on lui a donné une syntaxe aussi proche du C++/Java que possible - alors qu'il est plutôt proche des langages fonctionnels. On va dire que ça a grandement aidé à son adoption (c'est pas Erlang ou Racket qui peuvent prétendre avoir réussi à séduire les foules même si ils sont meilleurs sur bien des points).
Maintenant il faut bien comprendre qu'il s'agit de maquillage. En JavaScript vous avez des Scopes (ou états si vous préférez) qui contiennent des paramètres qui peuvent eux mêmes être des scopes. Ces scopes se partagent un temps d’exécution sur un seul thread en utilisant des évènements pour se passer la main les uns aux autres. Voilà c'est tout. Il y a tout en haut des prototypes qui peuvent servir de moules, c'est pratique mais pas franchement essentiel. Ça évite de devoir se fader une lib en plus pour la gestion des tableaux et des chaines principalement.
Tout le reste, et ça inclue les notions de variables, d'objet, de fonction etc, ne sont que des postiches pour faire plaisir aux codeurs C/C++/Java.
Une fois qu'on a compris ça, on arrête de coder en JavaScript comme si il s'agissait d'un langage procédural, et ça va beaucoup mieux.
Après concernant la multitude de bibliothèque en pré-alpha, c'est vrai que npm+GitHub n'a pas simplifié la tache. On manque en Javascript d'une bibliothèque standard. Mais à moins que vous soyez en train de coder un shell ou un système d'init en JS (là on crache du sang, je confirme), on trouve toujours d'excellente libs qui facilitent le boulot dans des proportions hallucinantes. J'ai écrit une interface console pour le pilotage et le monitoring d'appareils via TL1 ou SNMP en quelques heures (et encore parce que je ne connaissais pas bien TL1).
Après il y a des limitations, pour la crypto, le temps réel (même mou) ou le calcul massivement parallèle (les workers c'est bien, mais jusqu'à un certain point), c'est clairement pas le bon langage.
Mais clairement un langage de script qui permet en quelques centaines de lignes d'encaisser et d'envoyer des millions de traitement par seconde tout en restant lisible et debugable et en prenant moins de 100Mo tout compris en exécution - il y en a quand même pas des masses.
Et ensuite il y a des produits dont je ne peux plus me passer en JavaScript. PEG js par exemple - ou D3 js même si il est parfois incohérent avec lui même - ou Blessed
Alors certes ce n'est pas le langage parfait, son plus gros défaut étant les comportement singulier de certaines fonctions suivant que vous soyez en mode exécution (normal) ou en mode évaluation (console de debug navigateur par exemple) CF Understanding delete
Mais les incohérences sont tellement faibles comparées aux autres langages, à moins de faire du Haskell, ca va être dur de trouver un langage raisonnablement moderne et ouvert sur l'extérieur (capable de gérer des I/Os de façon un poil intuitive) qui soit meilleur à ce niveau là.
Après oui, pas mal de gens ont du mal avec la gestion par évènements et se retrouve piégé dans un callback hell, ou à devoir faire des promesses de promesses. Et on est en train de créer des tonnes de sucre syntaxiques pour que les fans de C++/Ruby puissent utiliser leur habitudes de programmations sans dégommer les perfs.
Tant mieux si ça ramène des gens en plus sur le langage. Mais je suis très content en ES5 avec du Q(pour le prototypage)/Bluebird (pour la production), du lodash et les outils précités pour l'habillage.