Un d�veloppeur sans solides connaissances en anglais est un d�veloppeur mal barr�...
Version imprimable
Un d�veloppeur sans solides connaissances en anglais est un d�veloppeur mal barr�...
Merci pour l'information, je ne m'en serais jamais dout�...
En quoi la JVM est adapt�e au mobile et � l'embarqu� ? C'est plut�t l'inverse : l'embarqu� qui s'est adapt� � la JVM. Avant les syst�mes �taient optimis�s pour �tre utilisable avec des ressources limit�es. Maintenant pour supporter la JVM, on est oblig� de mettre du mat�riel plus puissant. Et si micropython existe, c'est peut-�tre aussi parce que la JVM n'est pas si adapt�e que �a...
Compl�tement subjectif. Perso, je suis bien plus g�n� par la syntaxe verbeuse de Java.
Les performances de V8 sont tr�s correctes. Sur du front, la performance d�pend beaucoup de la qualit� de la connexion et de la qualit� du code. Si un dev a choisi un algo pourri, aucun langage ne le rendra efficace par magie.
Cet article n'a aucune valeur : il pr�sente des points de d�tail ou de syntaxe comme si c'�tait d'une importance capitale, il ne prend pas vraiment en compte les normes r�centes, certains arguments sont justes des pr�f�rences personnelles de l'auteur et beaucoup de critique ne sont pas des critiques du langage mais de mauvaises pratiques de d�veloppement qui auraient aussi lieu avec un autre langage.
mais encore ?
Pas vraiment : JS est apparu � peu pr�s en m�me temps que VBScript. Et je ne vois pas en quoi c'est un d�faut.
Non, il pointe des subtilit�s absurdes qui peuvent mener � des bugs difficiles � r�soudre, une syntaxe difficile � �crire et � comprendre et surtout non standardis�e puisqu'il y a souvent quatre ou cinq fa�on d'arriver � un m�me r�sultat. Quand il faut conna�tre 300 subtilit�s pour �tre s�r du r�sultat d'une �galit�, je n'appelle pas �a un point de d�tail.
L'appr�ciation personnelle de JavaScript est subjective, ses faiblesses �videntes sont objectives.
Si ton seul argument est de sortir 6 mots de leur contexte pour jeter en bloc toutes mes remarques alors effectivement il vaut mieux "en arr�ter l�".
Sinon, j'attends avec impatience tes arguments montrant que la JVM est adapt�e au mobile et � l'embarqu�, que JS est moins adapt� au backend que Python ou Ruby, que des features importantes manquent dans JS, que JS donne une importance particuli�re aux variables globales (point 5 de ton article), que les prototypes ne scalent pas (point 7), que JS n'a rien de commun avec lisp (point 9), etc, etc.
Je suis surpris que la c�te d'Angular d�gringole � ce point !
C'est que c'est un framework exigeant qui demande beaucoup de temps et d'efforts avant de commencer � travailler avec. J'ai d'ailleurs renonc� � l'imposer au sein de mon �quipe pour ne pas gr�ver le projet, on est plut�t parti sur une solution bateau : Spring Java + Thymeleaf + Bootstrap + JQuery. Le projet termin� on ne regrette pas ce choix car tous le monde s'y est senti tr�s � l'aise d�s le d�part et dans ce cas de figure c'est le prinicpal. Apr�s m�me si les autres frameworks JS sont plus int�ressants sur le papier il manquera toujour les nombreuses biblioth�ques de composants d�di�s de qualit� pro dont Angular est richement dot� et �a cel� n'a pas de prix lorsqu'on developpe pour les entreprises.
le probleme c'est que javascript doit �voluer en gardant une compatibilit� avec l'ancien et oui javascript est devenu complexe a cause de personnes comme toi qui veulent le beurre et l'argent du beurre deux exemples setTimeout qui servait a faire le l'asynchrone pour faire bien on a ajouter les promise et comme sa suffisait pas on a rajouter async await. Le deuxieme exemple c'est la poo on avait new une_class puis on a ajouter objet.create et enfin on a ajouter les class et tous �a pour ce retrouver avec du code qui m�lange les class et les prototype (une nouvelle fa�on de faire de la poo qui melange les class et les prototype trop fort) et du coup quand tu veut faire un cours c'est le casse t�te tous �� pour satisfaire la majorit� des gens. J'aime pas les �pinards et les p�tes c'est pas pour autant que je vais dire que c'est de la merde et que l'on doit pas en manger.Citation:
Non, il pointe des subtilit�s absurdes qui peuvent mener � des bugs difficiles � r�soudre, une syntaxe difficile � �crire et � comprendre et surtout non standardis�e puisqu'il y a souvent quatre ou cinq fa�on d'arriver � un m�me r�sultat. Quand il faut conna�tre 300 subtilit�s pour �tre s�r du r�sultat d'une �galit�, je n'appelle pas �a un point de d�tail.
bonne ann�e.
Les mots en question �taient simplement le r�sum� de ta persistance � ignorer aveuglement tous les probl�mes de JavaScript. L'article en question est factuel point par point, avec des exemples concrets et ne contient pas grand-chose qui puisse �tre attaquable.
Donc il faut accabler les utilisateurs pour les errance d'un langage qui ne sait ni d'o� il vient, ni o� il est, ni o� il va ?
Quand le code est d�gueulasse, c'est bien que le langage �volue pour rendre le code plus lisible. Je vais copier-coller des codes de l'article Asynchronous JavaScript: From Callback Hell to Async and Await
que j'aime bien citer.
Code d�gueulasse avec le continuation-passing style :
Code moins d�gueulasse avec les promesses :Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21 const verifyUser = function(username, password, callback){ dataBase.verifyUser(username, password, (error, userInfo) => { if (error) { callback(error) }else{ dataBase.getRoles(username, (error, roles) => { if (error){ callback(error) }else { dataBase.logAccess(username, (error) => { if (error){ callback(error); }else{ callback(null, userInfo, roles); } }) } }) } }) };
Code lisible avec async et await :Code:
1
2
3
4
5
6
7
8
9
10
11 const verifyUser = function(username, password) { database.verifyUser(username, password) .then(userInfo => dataBase.getRoles(userInfo)) .then(rolesInfo => dataBase.logAccess(rolesInfo)) .then(finalResult => { //do whatever the 'callback' would do }) .catch((err) => { //do whatever the error handler needs }); };
Le code souffre toujours du probl�me d�crit dans l'article What Color is Your Function? mais, au moins, par rapport au continuation-passing style, il y a eu du progr�s.Code:
1
2
3
4
5
6
7
8
9
10 const verifyUser = async function(username, password){ try { const userInfo = await dataBase.verifyUser(username, password); const rolesInfo = await dataBase.getRoles(userInfo); const logStatus = await dataBase.logAccess(userInfo); return userInfo; }catch (e){ //handle errors as needed } };
Non pas du tout, c'est un ramassi d'inepties et d'arguments fallacieux. D�j� l'article est publi� sur le blog "JavaScript Non Grata, Just say no to this abomination" par un fanboy de Smalltalk. Autant dire que niveau impartialit� on va �tre servi...
Point 1 : JS n'a pas de type entier. Et alors ? Les flottants ne sont pas suffisants ? Bash ne g�re pas les flottants de base, et c'est bien plus g�nant. Le C g�re des entiers et des flottants : r�sultat quand on travaille avec des entiers les comparaisons ne posent pas de probl�me mais il faut faire attention lors des divisions, mais avec les flottants c'est l'inverse, mais parfois il y a des conversions implicites, et le type int peut �tre 32 bits ou 64 bits selon l'architecture... c'est effectivement beaucoup mieux que JS...
Point 2 : typage faible et conversions automatiques. Ce sont des choix de conception dont je ne suis pas fan personnellement mais qui se retrouvent dans pas mal de langages dynamiques. Une bonne partie des exemples est assez discutable voire franchement malhonn�te. Je vous conseille l'exemple de "arr" qui m�rite � lui seul l'oscar de la mauvaise foi.
Point 3 : ajout automatique du ";". Ok, un d�butant fera l'erreur une fois dans sa vie, et ensuite ? En Python aussi il faut faire attention au d�coupage des lignes... et �galement � l'indentation. Et � peu pr�s tous les langages ont leurs pi�ges de syntaxe.
Point 4 : JS est mal utilis�, "Much of the code in the wild, especially those in commonly used libraries, are very badly written". D'o� vient cette affirmation ? Quelles sont ces libs ? Des stats d'utilisation ? Des rapports d'analyse de code ? Non, il faut croire l'auteur sur parole et admettre que c'est la faute de JS. Avec un autre langage on n'aurait certainement que du code propre et m�me l'ado qui se prend pour un codeur 2h apr�s avoir d�couvert la console de son navigateur produirait magiquement du code parfait...
Point 5 : JS d�pend fortement des variables globales. Et alors ? Les variables globales sont d�conseill�es dans quasiment tous les langages. Le C poss�de encore "goto" mais quasiment personne ne l'utilise pour autant; qu'il soit bien impl�ment� ou pas tout le monde s'en fout.
Point 6 : " JavaScript code can fail silently due to syntactical slip-ups. It has happened to me several times, and tracking down the reason can be most exasperating." Encore des d�tails de syntaxe mais cette fois on ne sait m�me pas lesquels. Mais on peut croire l'auteur sur parole car �a lui est arriv� plusieurs fois et c'�tait exasp�rant...
Point 7 : les prototypes ne conviennent pas pour des grosses applications. Pas d'argument ni de source concr�te. L'auteur �tant un fan de Smalltalk, on ne doute pas de l'objectivit� de son analyse... Il arrive m�me � citer C++ comme exemple de langage objet; mais il ne parle pas de l'h�ritage de classes en diamant ni de la gestion des exceptions lev�es dans un destructeur... �tonnant...
Point 8 : la programmation asynchrone est compliqu�e en JS. Ben c'est surtout la programmation asynchrone en g�n�ral qui est compliqu�e et comme JS est l'un des rares langages mainstream � l'utiliser autant alors forc�ment... En fait, la critique porte essentiellement sur la syntaxe et n'a plus vraiment lieu avec les promise et les async/await.
Point 9 : JS n'est pas comme Lisp. Et pour cause, JS a �t� inspir� par Scheme et non Lisp. Et apparemment c'est suffisamment bien fait pour que certains cours d'algorithmie migrent de Scheme � JS: https://en.wikipedia.org/wiki/Struct...ipt_Adaptation
Point 10 : le seul avantage de JS tient dans des frameworks comme Node.js et AngularJS. Bon l� c'est carr�ment du d�lire, l'auteur a compl�tement craqu�. Admirez : "Everyone understood that JavaScript was a terrible language, and so it was used only sparingly. But then, someone thought it was a good idea to put this awful language on the server."
"factuel point par point, avec des exemples concrets et ne contient pas grand-chose qui puisse �tre attaquable"...
En voil� un joli d�montage partial en r�gle rappelant l'analyse des discours scientifique par des climatosceptiques ;)
Je ne vais pas m'amuser � d�monter tes propos un par un, je n'ai pas que �a � faire et �a n'a aucun int�r�t. Ca se r�sume en gros � "ouin, il dit du mal de mon langage pr�f�r� et c'est un m�chant parce que c'est pas vraiiiiiiiiiiiiiii"
Le "ben oui c'est normal c'est JavaScript qui est pens� comme �a" n'est pas un argument non plus. Ca a �t� mal pens�, c'est tout.
j'ai test� React et Angular, je pr�f�re Angular.
Je trouve qu'Angular est injustement troll� comme le fait principal qu'on lui reproche est qu'il soit ferm�.... c'est faux.
Ensuite les versions, tous les 6 mois il y a une nouvelle version .... c'est exact, mais cela ne casse pas la compatibilit� entre les versions 4, 5, 6, 7, 8, 9....
(avec une commande, on upgrade facilement et si jamais il y a une chose � modifier, c'est indiqu� en warning...)
avec Angular 9 et le nouveau moteur ivy qui va permettre des performances au top et une taille minimale optimis� aux petits oignons j'esp�re que �a va reprendre du poil de la bete ....
sinon, je trouve path�tique la gueguere genre mon framework, mon langage est mieux que le tiens...
pour moi, tous les framework et langages se valent.
bien sur, il y a des petites diff�rences, certains sont plus destin�s dans un domaine que d'autres.
bien sur, certains ont des avantages ou inconv�nients
MAIS AU FINAL, ils font tous le job. C'est bien l� le principal, non ?
mais bon.... je vous laisse vous chamailler comme des gamins
Encore un d�bat aussi constructif qu'un avis sur la meilleure voiture du moment...
Dommage qu''on ne voie pas de spots publicitaires sur Javascript � la t�l�, ce serait dr�le de voir ce que les marketeux pourraient nous pondre ...
Une voiture, chacun prend celle qu'il a envie et c'est marre.
Au niveau des langages, les erreurs de conception nous impactent tous au quotidien, rendant notre travail beaucoup plus difficile que ce qu'il ne devrait l'�tre, il y a donc de quoi susciter des d�bats passionn�s.
Pour la voiture le choix n'est pas uniquement issu de l'envie, loin de l�, c'est bien plus complexe, il y a bien d'autres facteurs qui entrent en ligne de compte.
Un choix n'est pas toujours issu d'une logique implacable. Chacun sa "strat�gie" de choix.
Il n'y a plus qu'� cr�er une AI pour d�terminer quel est le meilleur langage :ptdr: vu que visiblement l'humain n'est pas capable d'arriver � un consensus, mais du coup il aurait sans doute un parti pris :ptdr:
le but d'une voiture c'est d'aller d'un point A � un point B
toutes les voitures offrent se service.
le but d'un langage ou framework est de concevoir une application
tous les langages/framework offrent ce service
Venant d'Angular je trouve � titre personnel que c'est enfin le moment o� le framework atteint une p�riode de maturit� et qu'il devient accessible (doc au top) � tous... qu'il est d�laisse. Alors qu'il y a encore quelque temps tout le monde se jetait dessus alors qu'il y avait des patchs majeurs tous les 6 mois qui impliquaient toujours des incompatibilit�s de code qui �taient assez insupportable pour une mont�e en comp�tences sereine sur le framework. C'est un peu �trange et �tonnant de mon point de vue mais le fait que je maitrise d�sormais bien l'environnement doit forc�ment biaiser mon opinion.
L'avantage certain que je vois avec React c'est une int�gration au top sur le mobile avec React native qui fait du natif justement alors qu'on ne peut en dire autant sur ionic pour angular... qui pour le coup est assez incontestablement derri�re son concurrent.