Ras le bol de JavaScript

Je vais paraître troll mais je n'en peux plus d'entendre que ce "langage" est l'avenir!

Pratiquement toutes ces libraires/préprocesseurs/whatever sont des workaround pour tenter en vain de fixer Javascript. Un langage absolument dégueulasse qui ne donne franchement pas envie selon moi.

ECMAScript6 a l'air franchement pas mal, j'espère qu'une fois adopté on aura plus besoin de toutes ces librairies et que javascript pourra enfin être utilisable en l'état...

Parce que personnellement, je n'ai ni le temps ni l'envie d'apprendre scala.js, typescript, dart, asm.js, machin.js,...

FAUX : javascript est formidable.

Combien de langages sont utilisables (et efficaces) sans un framework derrière ?

Javascript est un bon langage, il souffre d'années de mauvaise pratique, où ses défauts en ont fait un langage de bidouille. Depuis quelques années, il se professionnalise (malgré ses défauts, merci jQuery), aujourd'hui il révèle un fort potentiel, d'où son renouveau. Je ne vois pas pourquoi on s'en plaindrait, je préfère ça à un langage figé et un web qui n'évolue plus.

Groovy, Scala, Ceylon, Clojure,... sont autant de langages fonctionnels qui pourraient parfaitement prendre la place de javascript côté navigateur.

Je ne connais que les langages de la jvm, mais je suppose qu'avec n'importe quelle autre plateforme, c'est la même.

Je ne comprends pas qu'on fasse tant d'efforts autour de javascript. Ca ressemble à de l'hystérie sans aucun bon sens.

La programmation prototypale c'est sympa, mais ça ne vaut pas (selon moi) ce qu'il est possible de faire avec Groovy en matière de métaprogrammation,
et au moins en Groovy on ne déclare pas une classe comme ça: var Car = function...

Si Apple, Google, Mozilla et Microsoft sont capables de se mettre autour d'une table pour standardiser javascript, pourquoi ne pas en faire de même pour repenser javascript, voir l'éradiquer complètement?

Pour ECMAScript 6, justement je pensais que cette version réglerait ces problèmes, mais si c'est juste du syntax sugar, bah on va s'retrouver encore avec du coffeescript 2, machinscript jusqu'en 2050...

Franchement, j'ai déjà essayé un paquet de fois de me mettre sérieusement à javascript, sans succès. Coder dans un langage qui pousse à la confusion, aux erreurs, aux comportements imprévus, ça m'a jamais botté. C'est d'ailleurs pour ça que j'ai du mal avec le JS. Je ne veux pas bosser pour un langage, je veux que le langage bosse à ma place!

Il y a une différence entre un framework permettant de structurer son code et simplifier la vie des développeurs (genre angularJS) et un workaround pour tenter de fixer un langage déjà plombé depuis 10 ans (genre dart,scala.js, la librairie de cette news, coffeescript,...)

Ps: je fais du javascript, du front end, toussa. J'ai déjà testé un paquet de trucs en javascript (grunt, jquery, bower,angular,...). Ces librairies sont sympas, je ne les critique aucunement. Ce que je critique, c'est le js, et toutes ces tares. et le fait que les grands du web nous l'impose encore pour quelques années.. C'est comme bosser dans une boite avec java 1.2, ou Sharepoint,... le choix a pas de sens, ça emmerde les devs et ça n'apporte strictement rien par rapport à autre chose...

Ce n'est pas tant le JavaScript qui me dérange (même si un peu mais bon), mais les navigateurs :

• Les entreprises qui refusent de mettre à jour les navigateurs, on est obligé de se taper des vielles versions et surtout cette grosse daube d'IE. Si seulement les entreprises se rendaient compte qu'un développeur travaille mieux et perd moins de temps pour assurer les compatibilités grâce à une version récente d'un navigateur comme Chrome ou Firefox... Une solution serait de faciliter un maximum les mises à jour pour les rendre le plus transparent possible comme le fait Firefox.
• Les navigateurs, bien qu'à jour pour certains, sont tout simplement buggés. L'autre jour j'ai mis en place une fonctionnalité JS avec jQuery, tout en suivant la doc... la fonctionnalité aurait du fonctionner normalement et pourtant... j'ai donc posté un message sur les forums et bizarrement ce que j'ai produit de mon coté et qui ne fonctionne pas avec mon Firefox fonctionne chez les autres... Solution ? Bidouiller un peu comme d'hab pour que ça passe (pour ceux qui sont intéressé par le problème que j'ai rencontré c'est ici).

Je sais que cela a déjà été proposé, mais l'idéal serait de mettre en place un BVM (Browser Virtual Machine :aie: ) pour que n'importe qui puisse développer avec le langage qu'il souhaite et que ce soit un même bytecode qui soit interprété par les navigateurs.

Message initial de Kimojasan que j'ai dû couper en deux :

Citation:

---

Envoyé par Kimojasan

Citation:

---

Je vais paraître troll mais je n'en peux plus d'entendre que ce "langage" est l'avenir!

---

Citation:

---

ECMAScript6 a l'air franchement pas mal.... Un langage absolument dégueulasse qui ne donne franchement pas envie selon moi.

---

ECMAScipt6 ne réglera pas les problèmes fondamentaux du js. L'une des principale avancé selon mois sera la gestion de la porté des variables avec le mot clé let, le reste est sympas mais n'enlèvera pas tous ces défauts. (Opération mathématique sur des float bizarre ! , opérateurs de comparaison contre intuitif, typage fort inexistant, conversion de type, undefined et null ...)
Je ne voit pas comment tu peux être aussi négatif sur une version alors que tu sembles enthousiaste sur une autre qui n'apporte au final pas grand-chose si ce n'est du sucre syntaxique, et quelques composants intéressant ... :weird:
Le js à beaucoup de bon coté, son aspect fonctionnel vraiment puissant, orienté programmation événementiel, l'héritage par prototype aussi qui apporte plus de souplesse et de fonctionnalité qu'un système de classe. Tout n'est pas parfait, et ça ne sera jamais le langage de l'avenir, ni même un truc "dégueulasse", tu devrais te pencher sur ces aspects du langages, peut être que tu auras un avis plus objectif par la suite.

---

N'oubliez pas cette citation magique de Bjarne Stroustrup :

Citation:

---

There are only two kinds of languages: the ones people complain about and the ones nobody uses.

---

Citation:

---

Envoyé par Gugelhupf

Ce n'est pas tant le JavaScript qui me dérange (même si un peu mais bon), mais les navigateurs :

• Les entreprises qui refusent de mettre à jour les navigateurs, on est obligé de se taper des vielles versions et surtout cette grosse daube d'IE. Si seulement les entreprises se rendaient compte qu'un développeur travaille mieux et perd moins de temps pour assurer les compatibilités grâce à une version récente d'un navigateur comme Chrome ou Firefox... Une solution serait de faciliter un maximum les mises à jour pour les rendre le plus transparent possible comme le fait Firefox.
• Les navigateurs, bien qu'à jour pour certains, sont tout simplement buggés. L'autre jour j'ai mis en place une fonctionnalité JS avec jQuery, tout en suivant la doc... la fonctionnalité aurait du fonctionner normalement et pourtant... j'ai donc posté un message sur les forums et bizarrement ce que j'ai produit de mon coté et qui ne fonctionne pas avec mon Firefox fonctionne chez les autres... Solution ? Bidouiller un peu comme d'hab pour que ça passe (pour ceux qui sont intéressé par le problème que j'ai rencontré c'est ici).

Je sais que cela a déjà été proposé, mais l'idéal serait de mettre en place un BVM (Browser Virtual Machine :aie: ) pour que n'importe qui puisse développer avec le langage qu'il souhaite et que ce soit un même bytecode qui soit interprété par les navigateurs.

---

Effectivement, une vm côté client permettant d'utiliser le langage que l'on souhaite est une excellente idée.

Pour revenir à la discussion, encore une "excellente" idée des tenors du web pour fixer javascript: http://www.developpez.com/actu/86605...ur-JavaScript/

Et ça, rien que cette semaine... On a droit à au moins une grande idée par semaine pour fixer javascript. Ca commence à faire beaucoup...

jour

a chaques fois je dit bien a chaque fois que les gens pestes javascript c'est parce qu'ils le mélangent avec le DOM tant que vous ne vous mettrez pas bien dans la tête que javascript et le DOM sont deux choses différentes vous continuerez a pester javascript.

Citation:

---

Envoyé par reviretan

encore une "excellente" idée des tenors du web pour fixer javascript

---

WebAssembly n'est pas un remplaçant de JavaScript, ils n'arrêtent pas de le répéter. Son but n'est pas de "fixer" JavaScript, mais d'être un standard dédié au rôle de langage assembleur du web (ce qui n'avait jamais été la vocation de JS).

Ce n'est pas parce qu'un langage bénéficie d'évolutions récurrentes et d'un vaste outillage qu'il faut en conclure qu'il doit être "fixé". D'après moi c'est plus un signe de bonne santé, la preuve qu'il dispose d'une communauté active et qu'il s'agit d'un langage polyvalent avec de multiples facettes. Je n'ai pas codé ObjectModel pour "corriger" JavaScript, mais au contraire pour mettre à profit les getter/setters ES5 qui sont un aspect méconnu du langage avec un potentiel largement sous-exploité.

Ah c'est toi qui a développé ObjectModel, j'avais pas compris :D Beau boulot, effectivement avoir du typage en JS, c'est un grand plus!

Du coup, désolé d'avoir polluer ta news. C'était pas dans mes intentions.

Maintenant, je pense comprendre ton point de vue, même si je ne suis pas d'accord sur tes conclusions.

Si tu as écrit cette librairie, c'est parce qu'il n'y a pas de typage en javascript. Si TypeScript a été développé, c'est parce qu'il n'y a pas de typage en javascript.

Si WebAssembly voit le jour, c'est parce que les performances de javascript n'arrivent pas à la cheville du natif (je veux pas troller à coup de benchmark, c'est juste ce que dit la news), en partie parce qu'il n'ya pas de typage en javascript...

Je peux continuer ainsi pour chaque librairie que j'ai cité plus haut. Ces librairies ont été développée pour contourner les limitations du langage, pas pour le faire évoluer. Maintenant, c'est vrai qu'il y a une nuance: si tu vois javascript comme une plateforme, alors oui ces librairies sont une évolution. Mais si comme moi, tu considères javascript comme un langage et non comme une plateforme, alors tu ne peux pas parler d'évolution selon moi...Ce sont des contournements, des workarounds, bref des rustines pour réparer un moteur déjà foutu.

Ca reste un point de vue, je respecte les autres points de vue et je ne dirai pas que j'ai raison et que le reste du monde a tort... C'est mon ressenti.

Il suffit de se remémorer le destin de Flash, qu'on pensait indéboulonnable. Il a suffi de l'iPhone pour le déprecier. Pour moi, c'est la solution. Déprecier Javascript, se mettre autour d'une table et penser au langage idéal.

Je ne sais pas si tu fais beaucoup de backend, mais moi je prends vraiment beaucoup de plaisirs avec énormément de langages. Je ne suis pas sectaire, je me fie seulement à mon instinct quand il s'agit d'une nouvelle technologie. J'essaie tant bien que mal de ne pas tomber dans la hype du nouveau paradigme à la mode. Et j'ai vraiment l'impression qu'aujourd'hui, javascript est juste un phénomène de mode...Le fait qu'il ait le vent en poupe nous fait oublier ces problèmes, et nous pousse à nous embourber dans un nombre incalculable de workarounds et de solution alternative pour enfin avoir un langage capable de rivaliser avec les autres.

Citation:

---

Envoyé par melka one

jour
a chaques fois je dit bien a chaque fois que les gens pestes javascript c'est parce qu'ils le mélangent avec le DOM...

---

C'est très réducteur. Perso, venant de php, les premières fois que j'ai fait du js j'ai largement pesté contre la quasi absence de fonctions sur les tableaux par exemple, en même temps que sur son support incomplet ou différent suivant les navigateurs (et là jquery fut bien pratique).

Petite précision quand je parle de plateforme vs langage.

Si on prend la jvm par exemple (machine virtuelle java), c'est une plateforme qui permet de développer dans plus de 200 langages. Si tu n'aimes pas le java, tu peux développer en groovy, en scala ou en Clojure si tu le souhaites, ça n'a aucune importance puisque le code est transformé en bytecode ensuite. Mieux même, tu peux utiliser n'importe quelle librairie compilée dans n'importe quel autre langage.

Si javascript est une jvm, alors effectivement, on peut dire que TypeScript, Dart, ceylon.js, scala.js ou même coffeescript sont des langages, au même titre que groovy, scala etc. Dans ce cas, javascript est une plateforme, ces librairies sont des évolutions.Le problème, c'est que javascript comme plateforme pose aussi des problèmes de performance... Donc on met en place webassembly, pour contourner un problème de la plateforme elle-même... Et ça, à ma connaissance en tout cas, ça n'existe pas dans l'univers java. On peut choisir de changer de garbage collector, mais ça ne signifie pas que le garbage collector par défaut pose des problèmes dans la majorité des cas...

Un article sur le même thème qui m'avait bien fait marrer : http://sametmax.com/un-gros-troll-de...r-javacscript/ (et avec des vrais arguments quand même).

Bien que je trouve que cet article exagère évidemment son propos, je ne peux que penser qu'il y a un fond de vérité en me demandant juste : "Pourquoi ils ont fait ça ?". Je suis pour ma part assez d'accord avec la conclusion : il faut utiliser JS que là où il y a un clair avantage par rapport à d'autres technologies. Vouloir l'utiliser dans tout les cas, pour tous les problèmes et dans tous ses projets afin d'unifier son code est une bêtise absolue. L'exemple le plus marquant qui m'a choqué dernièrement c'est que le module de prépocesseur/minimifieur de ressources CSS/JS dans Laravel (framework PhP donc) utilise Gulp, un module Node.js ! C'est quand même assez dingue de voir ça dans le coeur d'un framework PHP, fusse t'elle la qualité de gulp, là n'est pas la question !

@reviretan: si le langage était vraiment défaillant, ces bibliothèques n'auraient pas pu être construites par-dessus. Ajouter un typage fort, ce n'est pas une rustine, c'est une nouvelle fonctionnalité. Et je n'aurais jamais pu le faire si JavaScript ne m'avait pas donné les bons outils. Je ne vois pas d'intérêt à vouloir un langage tout-en-un, on arrive jamais à se mettre d'accord sur le périmètre fonctionnel et les choix techniques. JS est déjà un langage multi-paradigme (fonctionnel/impératif/OOP). Il y a des milliers de bibliothèques censées aider au développement, on ne peut pas toutes les mettre dans le langage même s'il y avait de bonnes raisons pour. C'est un peu comme les core packages java, ils ne font pas partie du langage mais ils sont pourtant essentiels.

Sinon oui j'ai fait du back-end et de la prog logicielle plus classique. Je suis passé par C / C++ / C# / Java / PHP / VB / Python, un peu de Ruby et quelques autres que j'ai dû oublier entre temps. On ne m'a pas enseigné JavaScript à l'école d'ingé, mais c'est quand même le langage que j'ai choisi professionnellement. Finalement c'est avec JavaScript j'ai eu le plus de "fun", le sentiment d'être productif et créatif. Aussi c'était un langage en pleine expansion et je ne me suis pas trompé en misant dessus à l'époque (2005) quand on sait tout ce qui est arrivé depuis. Aujourd'hui on a plusieurs services back en Node.js et on fait nos builds projets en JS (Grunt/Gulp).

Qui a dit que JS n'était pas performant ? Au dernier Black Friday aux USA, Walmart a utilisé Node.js pour arriver à tenir la charge de centaines de millions d'utilisateurs concurrents. Paypal a aussi doublé son nombre de requêtes par seconde en migrant sur Node.JS. J'ai un stagiaire en train de benchmark des implémentations Websocket/SSE sur différents environnements serveurs et Node.js est en tête de classement pour le moment. Tout ça sans WebAssembly.

Il y a cet article fort à propos sur le site : http://sylvainpv.developpez.com/traductions/javascript/idees-fausses-heritage/

Citation:

---

Envoyé par melka one

a chaques fois je dit bien a chaque fois que les gens pestes javascript c'est parce qu'ils le mélangent avec le DOM tant que vous ne vous mettrez pas bien dans la tête que javascript et le DOM sont deux choses différentes vous continuerez a pester javascript.

---

JavaScript fournit une API pour manipuler le DOM. Si JavaScript ne sert pas à manipuler le DOM où se trouve l'intérêt de l'utiliser ?

Citation:

---

C'est très réducteur

---

je l'admet mais quand même trop souvent j'entend parlé de non compatibilité entre navigateur qui sont généralement du au dom de ie <=8 apres ca c'est vrais que javascript etait un langage pauvre qui finalement ne permettait pas de faire grand chose ce qui serait bien et qui na jamais été fait c'est si il y avait eu une sorte de nomalisation au niveau lib afin d'en créer une qui soit universelle et qui reproduise par exemple les possibilité de traitement des tableau de php (des fonctions avec des parametres).

Citation:

---

JavaScript fournit une API pour manipuler le DOM. Si JavaScript ne sert pas à manipuler le DOM où se trouve l'intérêt de l'utiliser ?

---

d'accord mais ne pas confondre javascript et dom et pour ton probleme d'evenement c'est pour mois un probleme de lib et il me semble du mauvais choix pour l'evenement et de rappeler que la gestion des evenements c'est du ressort du dom

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

<html> <head> <meta charset="utf-8" /> <script type="text/javascript"> function add_evt(){ document.getElementById("element2").onmousedown=function(evt){ var evt = evt || window.event; var btnClicked=evt.button switch (btnClicked) { case 0: alert('Left Mouse pressed.'); break; case 1: alert('Middle Mouse pressed.'); break; case 2: alert('Right Mouse pressed.'); break; default: alert('You have a strange Mouse!'); } } } (typeof window.addEventListener == 'undefined') ? document.attacheEvent(add_evt) : window.addEventListener("load", add_evt, false); </script> </head> <body> <div id="element2" style='height:200px;width:200px;background:red'></div> </body> </html>

---

ps : si je dit des betises n'ayez pas peut de me taper sur les doigts

@SylvainPV Effectivement, si tu y prends du plaisir et si ça te permet de t'exprimer davantage qu'avec d'autres langages, je ne vais pas essayer de te convaincre du contraire. J'ai rapidement consulté ton site web, et je dois dire que j'envie à mort ton niveau en Javascript ;-) 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. C'est peut-être pour ça qu'on va pas pouvoir se mettre d'accord aujourd'hui. Mais cet échange fut très enrichissant!

Citation:

---

Envoyé par melka one

je l'admet mais quand même trop souvent j'entend parlé de non compatibilité entre navigateur qui sont généralement du au dom de ie <=8 apres ca c'est vrais que javascript etait un langage pauvre qui finalement ne permettait pas de faire grand chose ce qui serait bien et qui na jamais été fait c'est si il y avait eu une sorte de nomalisation au niveau lib afin d'en créer une qui soit universelle et qui reproduise par exemple les possibilité de traitement des tableau de php (des fonctions avec des parametres).
(...)
d'accord mais ne pas confondre javascript et dom et pour ton probleme d'evenement c'est pour mois un probleme de lib et il me semble du mauvais choix pour l'evenement et de rappeler que la gestion des evenements c'est du ressort du dom
ps : si je dit des betises n'ayez pas peut de me taper sur les doigts

---

Erf, le troll sur la compatibilité entre IE6 et le reste du monde, c'est hasbeen ;-) Non, quand je parle de js, je parle bien du langage, qu'il soit exécuté côté client ou côté serveur. je trouve au contraire que javascript convient parfaitement pour de la manipulation de dom.

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

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 :calim2:

Citation:

---

Envoyé par reviretan

@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 :)

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.

Citation:

---

Envoyé par reviretan

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.

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 !

@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 >_<

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

Une bonne réponse à la fameuse complainte "y'a trop de frameworks en JS":
https://www.youtube.com/watch?v=DFP6UDgVJtE

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.

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 :mrgreen:

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.

Ahaha bon point pour Riot.js, je suis d'accord, si les mecs veulent pomper ils en ont le droit :D 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.

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.