Open source et architecture logicielle

@Sodium
Affirmer comme tu le fais que la simple existence de jQuery ou AngularJS est un aveux d'échec pour JavaScript est complètement stupide.
Cela prouve juste ton ignorance du développement et de l'architecture logicielle.

C'est exactement comme si l'on disait que JEE était une preuve d'échec pour Java.

Il est normal qu'un langage durant son évolution génère des API et des Frameworks. Tous les langages l'ont fait. On pourrait commencer par citer le langage C pour les bases de données avec la DBLib sous SqlServer, la CTLib sous sybase ou le pro*C sous Oracle. Je ne parlerai même pas de C++ avec les célèbres MFC de Microsoft ou maintenant Qt. Et la liste serait encore longue si on évoquait les framework comme Django pour python ou symfony pour PHP.

Alors tu peux continuer de compter le nombre de mots dans mes billets. Mais va prendre des cours avant de parler de langage de développement.

Un framework ne doit pas avoir pour but de transformer la manière dont on travaille avec un langage, voir remplacer celui-ci. C'est une trousse à outils permettant de gagner du temps et de cadrer le développement en équipe.
Dans le cas de JavaScript, la plupart des frameworks ne sont pas là pour améliorer la manière de travailler avec le langage mais bien pour le remplacer, souvent à travers une syntaxe complètement différente. La meilleure preuve en est qu'une bonne partie des développeurs travaillant avec JavaScript ne connaissent pas le JavaScript. Ils connaissent jQuery et c'est marre.

Alors tu es gentil avec tes insultes à deux ronds mais je travaille quotidiennement avec JavaScript et ai de bonnes notions de ses spécificités, notamment son modèle à base de prototypes. Cela n'empêche pas que si je pouvais travailler avec autre chose, je n'hésiterais pas.

Envoyé par SylvainPV

On ne doit pas fréquenter les mêmes sphères Voilà de quoi ouvrir tes horizons : il existe bel et bien un grand nombre de passionnés de JS ...

C'est pour ça je dis à part pour certains, mais j'ai fais 5 boites différentes et à chaque fois qu'il est question de JS les gens râlent, après certains aspect sont géniales comme l'absence de typage, on peux appeler un WebServices et afficher le résultat sans passer par plusieurs étape comme la désérialisation et autre pour afficher directement le résultat à l'écran, son plus gros problème c'est ses fonctionnalités de base qui sont trop pauvre et la nécessité d'y adjoindre de nombreuse librairie qui peuvent vite rentrer en conflit ou poser des problèmes suivant la version des navigateurs, ça aurait été plus agréable si de base on aurait eu un framework avec de nombreux outils mais bon ça aurait été compliqué de mettre ça en place dès le départ sur les navigateurs pour qu'il soit compatible.

Oui tu as raison il serait intéressant dans l'absolu de différentier les différents types de Big Data. Mais j'ai peur qu'un tel découpage ne soit d'une part un peu arbitraire, et d'autre part ne colle pas à la réalité des besoins.

Arbitraire car il faut se choisir des axes de différentiation. Alors certains diront que l’élément discriminant est le volume des données, d'autres penseront que c'est multiplicité des sources (et les données multimodales !)
De ce classement, on essaiera de définir des architectures, des plateformes et bien entendu des langages. Mais comme le Big Data est vraiment le domaine où les exigences changent à la vitesse de la lumière, j'ai peur que l'architecture idoine en juin ne soit plus en adéquation avec les nouveaux besoins de septembre.

D'autant qu'il existe suivant les problématiques et le résultat recherché différentes manières d'exploiter les données : http://www.kdnuggets.com/2015/09/fre...nce-books.html donc autant de choix de solutions plus ou moins adéquates. Le premier job du data scientist est de faire du data mining sur la palette d'options qui s'offrent à lui puisque comme tu le soulignes aucune n'est encore la panacée.

Envoyé par Sodium

Cela n'empêche pas que si je pouvais travailler avec autre chose, je n'hésiterais pas.

Ha excuse-moi pour la tournure conflictuelle qu’a prise notre relation. Mais je croyais que tu m’en voulais personnellement.
Mais là je comprends mieux, tu es frustré et tu souffres.
Il ne faut pas rester comme ça. Alors je vais me permettre 3 conseils amicaux :

• Manger équilibré et bien dormir (pas d’ordi ni internet après 18.00)
• Faire du sport pour expulser ton agressivité, peut être même un sport de combat.
• Mais surtout faire la paix avec le gentil JavaScript.

@autran

Comment veux-tu que l'on te prenne au sérieux si tu écrit ce genre de chose ?
Personnellement, je n'y connais pas grand chose en Javascript, mais si l'un dit qu'un framework n'est pas censé changer la syntaxe d'un langage et que l'autre répond qu'il faut bien manger et dormir, je considère cela comme un aveux de faiblesse dans les arguments de l'autre.

Et je ne pense pas être le seul à voir cela de cette manière.

Donc, je pose la question (car n'étant pas Sodium, tu y répondras sans doute) :

Pour toi, est-il possible qu'un framework d'un langage change la syntaxe du langage ?
Hormis les framework JS, y-a-t-il d'autre framework de n'importe quel langage qui fasse cela ?

Je pose la question par curiosité, car comme je l'ai dit avant, je n'y connais pas grand chose en JS.

C'est exactement comme si l'on disait que JEE était une preuve d'échec pour Java.

Il y a tout de même une différence entre le ressenti JEE et vanilla JS-front, c'est qu'on peut à la limite se passer des frameworks web Java (tels que Spring ou autre) pour créer une application potable (bien sur il n'y aura pas d'API pour faciliter la création d'objet à partir d'un formulaire envoyé par le client http, la validation CSRF par défaut, ou d'autres trucs comme ça), mais un vanilla JS-front sans jQuery ou Angular c'est difficile.

Je ne comprendrai jamais les gens qui défendent JavaScript bec et ongles comme si la critique de ce langage était une atteinte personnelle à leurs compétences. Travailler, voir être expert d'un langage dont les qualités laissent à désirer ne fait pas de vous des gens incompétents ou stupides, ça s'appelle juste s'adapter aux réalités du marché. S'obstitiner dans l'erreur en prétendant qu'il est hyper performant, pratique, qu'il fait le café et qu'à la limite il code tout seul en vous passant du Vivaldi pour la détente par contre, c'est déjà beaucoup plus le cas.

Analysons JavaScript objectivement sur quelques points :

JavaScript a-t-il un passé, muri, réfléchi, a-t-il jamais été mature ?
NON. JavaScript est issu d'années de bidouillages des premiers navigateurs (Netscape, Internet Explorer) souhaitant ajouter de l’interactivité aux pages. Chacun tritouillait son propre langage dans son coin et il a fallu des années pour que naisse le JavaScript que l'on connaît aujourd’hui et pour avoir un minimum de standards entre les différents navigateurs.

Le modèle objet de JavaScript est-il optimal ?
NON. Le modèle à base de prototypes est contre-intuitif et même lorsque l'on en acquière une certaine maîtrise, de nombreux outils chers aux programmeurs tels que l'héritage ou tout bêtement accéder à l'objet this référant l'instance en cours passent obligatoirement par de la bidouille prise de tête et compliquant inutilement le code.

La manière de travailler avec JavaScript est-elle standardisée ?
NON. Pratiquement personne ne travaille avec du JavaScript out of the box. Il existe des pétra-chiées de surcouches et comprendre l'une d'entre-elles ne signifient absolument pas que l'on aura ne serais-ce qu'une compréhension basique d'une solution concurrente pour récupérer rapidement le travail d'un autre développeur. En PHP, passer de Symfony à CakePHP, de Zend Framework à Laravel, de Wordpress à Joomla! etc ne sera pas des plus intuitif mais dans tous les cas, on fait toujours du PHP. Au final, s'il y a un bug à corriger ou un petit changement à implémenter, au final le plus difficile sera de trouver où l'on doit placer le code, pas comment l'écrire. Avec les Frameworks et langages alternatifs à JavaScript, on ne fait plus du JavaScript, impossible donc de passer facilement d'une solution à une autre.

Le Canvas HTML 5 dispose-t-il d'une API JavaScript exhaustive et performante ?
NON. On peut faire des trucs fantastiques avec le Canvas HTML5, mais l'API qui va avec n'offre que des fonctionnalités bas niveau. Animer un sprite, gérer différentes couches, déplacer un élément à l'écran, il n'existe aucune fonctionnalité de base pour faire ce genre de choses. On dessine des pixels et c'est tout. Pareil, il faudra ici choisir l'un des multiples frameworks comme createjs à la doc incomplète et à l'avenir incertain.

JavaScript est-il standard entre les navigateurs ?
NON. JavaScript garde encore et toujours des spécificités propres à chaque navigateur.

On pourrait continuer des heures comme ça, mais ça me paraît déjà pas mal pour démontrer que l'on peut difficilement considérer JavaScript comme un "bon" langage.

@SofEvans

Ta question est excellente elle ouvre de nouvelles perspectives. Et pour ce qui nous occupe, une nouvel angle d'attaque du sujet.
C'est avec joie que je te répondrai comme j'ai répondu à tout ceux qui ont voulu dialoguer sur l'aspect technique.

Mais en préambule je dois avouer que ma réponse ne sera basé que sur mon expérience des langages C++ et Java donc elle ne vaut pas un avis d'expert omniscient comme il en existe plusieurs sur DVP. Et j'ajouterai qu'en JavaScript mon expérience se réduit à quelques mois sur AngularJS et node.js

Pour que ma réponse comporte une thèse et une antithèse, voici mon plan d'argumentation :

• Thèse : oui les frameworks peuvent modifier le langage dans son acception générale mais pas forcément sa syntaxe.
• Antithèse : le langage répond aux stimuli (les frameworks structurant) en évoluant

Un framework modifie forcement un langage. Pas nécessairement sa syntaxe mais la façon de développer ou de conduire la fabrication d'un logiciel. Pour Java je citerai Maven qui impose la connaissance de la syntaxe XML. Ou encore JUnit qui nécessite quelques @annotations.
Pour en revenir au coeur du sujet, lorsque j'utilise Angular ou node, j'ai vraiment l'impression de faire du JavaScript. Simplement on l'utilise peut être différemment (fonctions de callback, recours systématique à Json...) de ce que l'on faisait historiquement
Néanmoins comme je viens de Java et que j'y suis encore un peu par la force des choses (les projets pro) et surtout par gout (car j'aime beaucoup ce langage), je pense développer plus comme quelqu'un du monde C-like que comme un expert du JavaScript (qui ont toute mon admiration). Donc j'affirme que l'on peut faire de l'AngularJS de façon conventionnelle. Tu trouveras d'ailleurs dans le magazine d'avril-mai 2015 un article page 15 qui illustre mon affirmation. L'auteur de cet article n'est pas une lumière, mais il se tient à ta disposition pour te faire partager le peut qu'il sait.

Comme je le disait plus haut sur ce fil les frameworks valorisent le langage qui en reste le vecteur. Et comme cette dynamique est vertueuse. Donc bien souvent le langage évolue pour intégrer ces frameworks structurants. Par exemple dans les années 90 quand je faisais du C++ j'utilisais des librairies qui implémentaient la STL. Et en 2000 j'ai découvert qu'elle était partie intégrante de C++. Java a également intégré JPA en réponse au besoin d'un ORM qui à l'origine nous venait d'Hibernate.

Voila, j'espère que cette réponse t'éclairera un peu.
Si tu souhaites d'autres informations, je reste disponible dans la mesure de mes capacités.

Envoyé par Sodium

Je ne comprendrai jamais les gens qui défendent JavaScript bec et ongles comme si la critique de ce langage était une atteinte personnelle à leurs compétences. Travailler, voir être expert d'un langage dont les qualités laissent à désirer ne fait pas de vous des gens incompétents ou stupides, ça s'appelle juste s'adapter aux réalités du marché. S'obstitiner dans l'erreur en prétendant qu'il est hyper performant, pratique, qu'il fait le café et qu'à la limite il code tout seul en vous passant du Vivaldi pour la détente par contre, c'est déjà beaucoup plus le cas.

Amen.
J'ai connu un animal de cette espèce l'an passé en licence pro : parce qu'il a décroché un job (c'était une lp en alternance) sur une app Sails.js, il ne jurait que par Js et pouvait vous expliquer que Js répondait à tous les besoins. Au final, c'était assez amusant de l'écouter et "débattre" avec lui.

Envoyé par autran

Mais en préambule je dois avouer que ma réponse ne sera basé que sur mon expérience des langages C++ et Java donc elle ne vaut pas un avis d'expert omniscient comme il en existe plusieurs sur DVP. Et j'ajouterai qu'en JavaScript mon expérience se réduit à quelques mois sur AngularJS et node.js

Par cette citation, toute crédibilité que tu peux avoir est détruite : La pique est absolument pas nécessaire vis à vis des autres (l'expert omniscient) et en plus tu admets que tu n'y connais rien alors que tu publies des articles creux en boucle, presque parce qu'il te faut publier, pendant que ton argumentaire est détruit systématiquement par les autres intervenants.
Au lieu de lire les conseils qui te sont donnés pour améliorer les qualités de tes publications, tu prends la mouche et tombe dans des argumentaires ridiculement inutiles, comme ci bien dit par SofEvans:

Envoyé par SofEvans

Comment veux-tu que l'on te prenne au sérieux si tu écrit ce genre de chose ?
Personnellement, je n'y connais pas grand chose en Javascript, mais si l'un dit qu'un framework n'est pas censé changer la syntaxe d'un langage et que l'autre répond qu'il faut bien manger et dormir, je considère cela comme un aveux de faiblesse dans les arguments de l'autre.

C'est dommage car, à vouloir défendre une technologie qui te plait (et qui a des arguments légitimes, d'où sa popularité actuelle), tu nuis à cette technologie et tu peux rebuter certains amateurs intéressés par le Js.

@Mouke

Oui, j'ai dit qu'il existait des experts omniscients sur DVP. Je pense à des gens qui ont conçu des frameworks ou qui sont des experts reconnus de tous. Je parle de gens avec qui je mène des projets ouverts sur DVP et qui ont une réponse à toutes les questions ou difficultés que nous y rencontrons. L'un d'entre eux a d'ailleurs posté quelques réponses sur ce fil. Et je persiste dans mes propos car j'en connais également quelques autres en Java et C++ sur DVP qui ont effectivement toute mon admiration.
Donc je n'ai pas compris ta prose qui prétend que je les insulte.

Et tant que nous sommes dans les insultes, je ne comprends pas trop la violence de ton attaque dans la mesure où il ne me semble pas m'en être personnellement pris à toi ni à l'un de tes avis techniques. Peut être la joie de la lapidation collective!

Et puisque tu me m'accuses d'incompétence, je pense qu'il serait plus courageux de ta part de m'opposer des arguments techniques. Or tu n'en a pas émis l'ombre d'un seul dans les 2 réponses que tu as faites sur ce fil. Pourtant il te serais si facile de venir critiquer mes sources disponibles sur DVP.

Puisque les réactions épidermiques déclenchées par ce sujet semblent épuisées, j'en profite pour faire une petite mise au point à froid.

Il m'est arrivé de répondre à certains sur ce fil en utilisant l'ironie.
Je ne l'ai fait que pour rendre ce fil un peu plus gai au milieu des insultes que j'y ai reçues.

Ceux qui s'en plaignent, et montrent leur imperméabilité à l'humour, ne font que démontrer leur étroitesse d'esprit. Ils y gagneraient à pratiquer en retour la dérision à mon endroit, s'ils s'en estiment la victime.

Envoyé par Gugelhupf

...mais un vanilla JS-front sans jQuery ou Angular c'est difficile.

Oui tu as raison, d'ailleurs jQuery est embarqué dans AngularJS. Et pour en revenir à jQuery qui est un standard de fait, peut être devrait on le considérer comme une extension implicite de JavaScript (en tout cas pour le front). Peut-être même qu'un jour il fera partie du langage.

@Autran : Tu as tellement tendance à utiliser du sarcasme qu'on ne sait plus si tu es sérieux ou sarcastique. De là ma réflexion sur les omniscients, je pensais que tu balançais une x-ième pique envers tes détracteurs.

Et tant que nous sommes dans les insultes, je ne comprends pas trop la violence de ton attaque dans la mesure où il ne me semble pas m'en être personnellement pris à toi ni à l'un de tes avis techniques. Peut être la joie de la lapidation collective!

Et puisque tu me m'accuses d'incompétence, je pense qu'il serait plus courageux de ta part de m'opposer des arguments techniques. Or tu n'en a pas émis l'ombre d'un seul dans les 2 réponses que tu as faites sur ce fil. Pourtant il te serais si facile de venir critiquer mes sources disponibles sur DVP.

Il m'est impossible de critiquer tes publications quelques sur le plan du javascript : Mes compétences se limitent à un peu de jQuery basique pour agrémenter des app Zend/Symfony. C'est pour ça que je n'entre pas dans le débat technique et c'est pour ça que je suis très intéressé par des articles sur Js : Je suis curieux et souhaite m'améliorer.
Je critique la forme de tes articles : malgré un sujet intéressant, on n'apprend rien. J'ai posté une première fois pour essayer de t'aider à améliorer la forme de tes billets, ce qui serait mutuellement bénéfique. Mais dès que tu es "attaqué", tu veux automatiquement te défendre de manière brutale.
Oui, j'ai dit ton article est trop "Pro-Js", comme tous tes articles. Ca me rappelle celui où tu parlais de convaincre un DSI à migrer d'une app Java à une app Js (j'ai plus le détail en tête et j'ai la flemme de chercher) genre c'était une formalité et tout bénef.

C'est dommage que tu réagisses aussi agressivement, je suis sur que tes sujets pourraient être intéressant.

Envoyé par Sodium

On pourrait continuer des heures comme ça, mais ça me paraît déjà pas mal pour démontrer que l'on peut difficilement considérer JavaScript comme un "bon" langage

Sachant que tu n'utilises JavaScript que pour la partie front, je vais pousser ton raisonnement jusqu'au bout, c'est à dire ne plus utiliser un langage que tu détestes. Alors, je suis obligé de te demander ce que tu utilises pour faire de l'asynchrone entre le serveur web et le navigateur. Parce-que je ne sais pas faire d'AJAX sans JavaScript. Et aujourd'hui, recharger toute la page web chaque fois que j'interagis avec le serveur, heu c'est pas très professionnel.

Envoyé par autran

Sachant que tu n'utilises JavaScript que pour la partie front, je vais pousser ton raisonnement jusqu'au bout, c'est à dire ne plus utiliser un langage que tu détestes. Alors, je suis obligé de te demander ce que tu utilises pour faire de l'asynchrone entre le serveur web et le navigateur. Parce-que je ne sais pas faire d'AJAX sans JavaScript. Et aujourd'hui, recharger toute la page web chaque fois que j'interagis avec le serveur, heu c'est pas très professionnel.

C'est justement ce qu'il se tue à t'expliquer : Il n'utilise Js que par obligation. Y'a pas d'alternative.... Ca ne permet en aucun cas de juger de la qualité de Javascript.
Donc oui tu fais ton Js parce que t'as pas le choix, pas parce que c'est la meilleure option à ton problème.

C'est ce paradoxe qui ressort de votre lecture du développement web qui m'interpelle.
Aujourd'hui la production de logiciel web impose pour la partie front l'utilisation de JavaScript. C'est une contrainte du moment.
Pour ma part, je trouve que JavaScript est un langage qui en vaut un autre donc cette exigence de l'utiliser ne me gène pas. Je devrais plutôt dire ne me gène plus car ce langage est arrivé à un niveau de maturité tout à fait suffisant pour faire du développement professionnel.
J'ajoute également que si cela ne m'avait pas convenu j'aurais abandonné le front pour me consacrer à du back ou à un domaine adressé par un langage qui me convient.

Envoyé par autran

J'ajouterai que si un calcul met 11ms au lieu de 9 ça n'est pas très important.

Pas très important pour qui ?
On parle de big data, si tu perds 2ms à chaque calcul, sur 1million d'occurences tu perds déjà plus d'1/2h de calcul.

Envoyé par autran

Aujourd'hui les performances du hard et la chute des couts CPU et RAM sur le cloud relèguent au second plan les exigences de célérité et de consommation mémoire des compilateurs.

Aujourd'hui les performances sont tout autant importantes pour faire transiter plus de données plus rapidement et dépenser moins d'énergie. Et ne parlons même pas du marché du mobile qui, même s'ils sont désormais puissants, sont contents de pouvoir faire la même opération en dépensant moins d'énergie de leur batterie.

l'implémentation des modèles de conception big data, voire machine learning, sont largement aussi faciles à implémenter en JavaScript qu'en C++ et Java.

Et donc, pourquoi le faire en javascript et sacrifier les performances au lieu de le faire en Java ou C++ ? Mis à part l'amour du langage de la personne qui le fait, y'a un vrai choix ou bien ?

Merci Bousk pour recentrer le débat sur le cœur du sujet : le Big Data.

Comme toujours, tes arguments sont inattaquables. En effet, JavaScript n'est pas le langage le mieux placé en termes de performances pour traiter d’énormes volumes de données. D'ailleurs je l'ai affiché en toute transparence sur mon Blog dès le début de la discussion sur ce fil. J'ai fait un comparatif entre Java et JavaScript, mais j'ai bien précisé que je prendrai toute les autres propositions de langages en réponse (python R ....).

Quant à élire le langage le plus performant en terme de vitesse d’exécution et d’élégance du code je pense que la médaille reviendrait à C++. Mais cette analyse ne risquerait elle pas de renvoyer le nouveau chouchou des mathématiciens (langage R) aux oubliettes ? Idem pour Python non ? C'est pour cela que je souhaitais faire rentrer d'autres critères dans le processus de sélection du langage.

Pour produire un système d'information ou un tableau de bord qui s'appuie sur le web, on sait que JavaScript est incontournable et même qu'aujourd'hui c'est un langage full stack. Donc en termes d'ingénierie des ressources humaines, il serait intéressant d'utiliser aussi ce langage.

Un autre axe de réflexion s'offre à nous si l'on considèrent que les terminaux mobiles sont l'ultime niveau de capillarité d'internet permettant de collecter et générer des données. Comme JavaScript est exécutable sur toutes ces plateformes, ne pourrait on pas considérer ce langage comme un vecteur de collecte de données?

Voici donc quelques pistes qui me poussent à dire que JavaScript à un rôle à jouer dans le Big Data

jour

la philosophie de javascript est basé sur la poo refuser javascript c'est refusé le concept de la poo et entendre de la part de soit disant professionnel du web dire que les frameworks sont la pour modifié la syntaxe de javascript c'est hallucinant les framework javascript sont la soit pour modifié la syntaxe du DOM et de api qui dit en passant n'ont rien a voir avec javascript soit pour enrichir le langage mais en aucuns cas on modifie la syntaxe.

une boucle reste une boucle une condition reste une condition une variable reste une variable ...etc et ce quelle que soit le langage un langage est ce que l'on en fait.