Open source et architecture logicielle

Envoyé par autran

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?

Si tu peux exploiter les logs des requêtes effectuées en JavaScript, voire collecter des données en JavaScript, le gros du travail de traitement à peu de chance d'être fait en JavaScript.

Pour ces traitements destinés à tourner sur des serveurs de calcul, on se moque royalement de la possibilité de les exécuter dans un navigateur.

De plus, tu te vois faire des traitements mathématiques (image, signaux, nuage de point, réseau routier/trace GPS, simulation numérique, etc.) en pur JavaScript? D'une part, la chute de performance de 10%, c'est quand tu fais un binding sur une grosse fonction C++. En faisant des boucles et du calcul intensif, tu risques plus de te ramasser des facteurs 10. D'autre part, toutes les bibliothèques de calcul seront dans d'autres langages et l'existant est assez déterminant en matière de choix de langage.

Accessoirement, si JavaScript a désormais des outils de packaging efficaces (NPM) qui pourraient rendre intéressant un binding; c'est loin d'être aussi riche que du Chef, du Ansible ou du Docker pour déployer une infrastructure. Pourquoi se battre uniquement pour le déploiement des traitements quand tu devras te battre pour déployer tous tes composants (stockage distribué par ex)?

A mon goût, on a renoncé au langage idéal pour les traitements et on s'en moque dès lors qu'on automatise le déploiement de chaque composant dans un système unifié. A ce titre, on recherche moins un langage idéal qu'un cadre idéal (ex : hadoop au sens stockage distribué+map reduce).

Envoyé par melka one

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.

JavaScript n'est pas orienté objet comme on peut l'entendre avec C++/Java/C# même s'il tend à l'être de plus en plus avec les nouvelles version d'ecmascript, c'est un langage de programmation orienté prototype, c'est que développer une grosse appli en VanillaJS pur sans utiliser aucun outil supplémentaire faut être maso ...

vanillaJS pur c’est comme monter en haut ou descendre en bas

Mais quel que soit langage que l’on utilise pour faire du front + du back, on travaille toujours avec des Frameworks qui nécessitent un apprentissage. C’est typiquement la raison pour laquelle un développeur JEE full stack est long à former. Il devra probablement connaitre Spring pour développer ex nihilo mais aussi Struts pour faire du MCO ou de l’évol

Et JavaScript n’échappe pas à la règle. L’erreur que font beaucoup de développeurs est de croire que JavaScript permet avec 2 ou 3 instructions de développer un Système d’Information en 5 minutes. Aussi, lorsqu’ils découvrent que la partie Back nécessite de connaitre Node.js et sa gestion de code non bloquante, ils font un rejet massif du langage. Je pourrais dire la même chose du front et d'AngularJS qui poussent certains à faire du bashing systématique.

C'est justement parce que JavaScript est un vrai langage qu'il demande un véritable investissement pour être maitrisé.