IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Non, Microsoft n'a pas abandonné C++, C#, etc. pour réécrire ses outils et logiciels en JavaScript :
Un développeur de la firme fait des précisions

Le , par Patrick Ruiz

593PARTAGES

6  0 
Un développeur de Microsoft a, il y a quelques jours, fait une apparition sur Twitter pour passer le message selon lequel Microsoft est en train de réécrire ses outils et logiciels en JavaScript. Le tweet n’a pas manqué de générer de nombreux questionnements sur les objectifs poursuivis par l’entreprise. Il y a en effet que les écarts en matière de performances entre des langages de programmation comme le C++ et JavaScript sont importants pour ne pas appeler à une telle posture. Mais 280 caractères peuvent s’avérer très insuffisants pour traduire le fond d’une pensée. Sean Thomas Larkin a fait une nouvelle sortie pour apporter des précisions.

L’entreprise n’est pas en train de laisser tomber tous les autres langages pour JavaScript comme le laissait penser le précédent message de Larkin : « je n'ai jamais été capable de le dire jusqu'à maintenant. Eh bien, en fait, tout Office 365 est en train d'être complètement réécrit (et c'est presque terminé) dans ce petit langage de script appelé #JavaScript. Et Skype, et Microsoft Teams, et Visual Studio Code, et tout le protocole de débogage de Microsoft Edge (au lieu de C ++). »

« Nous ne sommes pas en train de laisser tomber C++, C# ou tout autre langage, API et outils dont nous faisons usage au sein de Microsoft », écrit-il. À la réalité, JavaScript est beaucoup plus utilisé par les équipes de développement de Microsoft pour monter des interfaces utilisateur. À propos de la suite bureautique Office 365 par exemple, Larkin indique que Microsoft s’appuie sur le framework React Native (Windows) pour l’UI, mais pas dans son entièreté. « Les API et services continuent d’être développés en C++, C# ou tout autre langage jugé le plus approprié », précise-t-il. Même son de cloche pour le moteur de rendu EdgeHTML que Larkin dit être développé en C++ dans sa quasi-totalité. Là encore, JavaScript revient pour certains éléments d’interface utilisateur en s’appuyant sur React ou webpack.


Pourquoi le choix de JavaScript pour le développement d’interfaces utilisateur ?

Parce que cette approche permet de mettre le pied dans pratiquement toutes les maisons (entendez ici plateformes). Il y a en effet que le langage JavaScript est vu comme le langage de demain parce qu’il bénéficie d’un vaste écosystème. Sur un PC ou sur un ordinateur monocarte comme le Raspberry Pi on peut lancer un navigateur web. Or, JavaScript est « la star » sur ces derniers, ce qui veut dire qu’avec des compétences en développement web ces plateformes constituent des bastions qu’on peut conquérir. Ajoutez des composants comme les WebView à la sauce et il est possible de mettre sur pied une application pour Android et iOS sans compétence extrêmement pointues en déveleppement pour ces systèmes d'exploitation. Maintenant, quand on connaît les possibilités d’interfaçage de JavaScript avec des langages comme C++ on ne peut qu’en profiter comme Microsoft.

Source : Twitter

Et vous ?

Que pensez-vous de l’approche adoptée par Microsoft ?

Quels pourraient être les bénéfices pour toutes les parties prenantes de l’univers du logiciel Microsoft ?

Voir aussi :

Quel est l'intérêt d'écrire ou réécrire un logiciel en JavaScript ? Partagez votre expérience

Excel : Microsoft ajoute la possibilité d'écrire des fonctions personnalisées en JavaScript, mais également des fonctions d'apprentissage automatique

Hyperapp, une bibliothèque JavaScript de 1 ko pour la création d'applications Web front-end, en quoi diffère-t-elle des bibliothèques existantes ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de ijk-ref
Membre éclairé https://www.developpez.com
Le 15/06/2018 à 5:34
Citation Envoyé par Marco46 Voir le message
Tu peux mais c'est de l'overkill. Tu as seulement besoin d'une fonction de validation.
Pour moi l'overkill c'est surtout s'amuser à perdre inutilement plus de 20% de puissance pour des vérifications de types à l'exécution et se rajouter de potentiels ambiguïtés et bugs facilement évitables avec des vérifications de type à la compilation.
12  0 
Avatar de Pongten
Membre expert https://www.developpez.com
Le 15/06/2018 à 12:48
Allez, je rentre dans la mêlée

Citation Envoyé par Marco46  Voir le message
C'est une mauvaise pratique que de faire faire autre chose à un constructeur que de l'assignation de valeurs. Pour plein de raisons à commencer par une toute simple, c'est que le code ne fait pas strictement ce qu'il dit. Comment je sais à la lecture d'un tel code const url = new Url('http://www.domain.tld') que je suis entrain de vérifier la validité de l'url ? C'est écrit explicitement où ? Qu'est-ce qui me garanti que je ne fais que ça et pas autre chose ?

C'est une mauvaise connaissance de la POO que de croire que le but du constructeur est de ne faire que de l'assignation de valeurs. Le but d'un constructeur est, comme son nom l'indique, la construction de l'objet. Et un objet est considéré comme construit quand il est valide. Dans l'exemple qui nous occupe, un objet valide représente une url valide et donc il est normale que la vérification ait lieu dans le constructeur.

Citation Envoyé par Marco46  Voir le message
Je ne vois pas en quoi les tests sont inutiles, il faut bien tester la logique de vérification de l'url. Que tu implémentes la vérification dans ton constructeur ou que tu passes par une fonction n'y change rien. Ou bien tu envisages de ne pas tester ta logique de vérification ?

Il n'est pas dit ici que les tests sont inutiles, mais juste que l'intérêt d'utiliser des types du genre Url est que les tests de vérification / validation / etc. ont été effectués par le concepteur de la classe et que donc pas besoin de les refaire.

Pour en revenir au débat plus global, je trouve ça amusant.. Chaque langage, chaque paradigme a ses forces et ses faiblesses.. mais venir dire le JS c'est dégueulasse parce que je sais pas écrire du C++ en JS ou inversément, c'est comme si on venait à dire le français, c'est dégueulasse parce que je ne peux pas utiliser la même construction grammaticale qu'en allemand ou en néerlandais !!

Mais bon, le problème avec des langages qui prennent subitement un coup de projecteur, c'est le même qu'avec un marteau.. Quand on en trouve un beau, on voit des clous partout !
5  0 
Avatar de fredoche
Membre extrêmement actif https://www.developpez.com
Le 17/06/2018 à 10:51
C'est bizarre cette propension à voir débarquer des commentateurs "complaining" dès qu'un sujet évoque le javascript, ses évolutions, ses usages ou ses succès

Je ne sais pas mais les mecs qui font du C/C++ débarquent régulièrement dans les forums Java pour dire à quel point c'est nul et lent, et qu'ils n'ont aucune envie de l'utiliser ?
Ou dans les forums Python ? Haskell ? D ? PERL ... ?

Ca fait des dizaines d'années que des gens font des programmes qui sont utilisés quotidiennement et intensément en production, qu'est ce qu'il y a besoin de prouver ?
Et quand on parle de production, c'est à l'échelle mondiale, internet et le web c'est mondial.
Quelqu'un se pose les mêmes questions sur le PHP ? Il reçoit les mêmes critiques le PHP ?

Je veux dire on pourrait dire la même chose du VBA ou du VBscript, il y a des gens qui gagnent leur vie et bien à faire des applications avec ces outils. Est-ce qu'il existe des gens qui perdent leur temps à critiquer ces langages dont on connait tous les forces et les faiblesses, les pourquoi ils sont utilisés ?
6  1 
Avatar de Sodium
Membre extrêmement actif https://www.developpez.com
Le 15/06/2018 à 15:28
Et pour moi, c'est juste pour répondre à une demande absurde de ceux qui veulent que ce soit le langage qui s'adapter à leur façon de travailler plutôt que l'inverse…
Si tous les développeurs qui ne sont pas des fanboys de JavaScript se plaignent de sa syntaxe, c'est qu'il y a un problème avec le langage, pas avec les utilisateurs.
7  3 
Avatar de
https://www.developpez.com
Le 16/06/2018 à 2:41
Cette guerre de chapelle est un peu triste à lire, surtout que hormis quelques attaques ad hominem tout le monde à a peu près raison sur ce topic. A peu près car beaucoup de ce qui est dit peut être valide ou non selon le contexte, par exemple valider l'url dans le constructeur de la classe peut être un choix valide ou très nul selon l'architecture du système.

La POO c'est vraiment génial pour réaliser tout ce qui à des specs de base bien définies. Évidemment aucune application n'a des specs parfaites en amont (imaginez, le rêve !), mais il faut au moins que le cœur de l'application soit stable. C'est du au fait que la POO nécessite pas mal de code boilerplate, rien d'horrible surtout grâce aux IDE, mais ça fait que changer de stratégie en milieu de parcours est vraiment pénible.

Un exemple réel pour illustrer : je bosse pour une boite qui, en très gros, gère des documents légaux et permet à nos clients de s'assurer de la conformité de leurs documents. L'entreprise est historiquement centrée sur tout ce qui est législation environnementale et ce depuis 15 ans, avec aucun signe de changement, on peut donc vraisemblablement lors du design de la nouvelle appli se dire que c'est acquis. Or, 3-4 mois dans le développement, on nous annonce un chamboulement, conquête de nouveaux marchés etc. On passe donc d'une boite environnementale à une boite supportant tous types de documents, qui va implémenter de la gestion opérationnelle, et autres joyeusetés absolument pas au rendez vous initial. Il a fallu réécrire quasiment l'intégralité du code, notre système de base étant devenu un espèce de sous-système du nouveau logiciel.

On aurait très facilement pu ajouter les nouvelles briques (gestion opérationnelle, etc) sur l'existant, mais comme le coeur même du système est chamboulé il a fallu repenser toute l'architecture. Après coup, je suis certain que si on avait eu initialement un code en fonctionnel au lieu de orienté objet on aurait pu réutiliser beaucoup plus de composants.

On pourrait se dire que après cette "mésaventure", on soit passé sur du fonctionnel, un backend type NodeJS, mais non. A mon sens la très grande force de l'OO c'est sa lisibilité, sa facilité à maintenir et la simplicité à construire par dessus SI on comprend bien les concepts. Je ne veux pas parler pour tous les devs mais l'OO chez moi c'est quelque chose qui a fait clic un jour, la veille tu es dubitatif sur la nécessité d'une telle complexité, tu n'es jamais vraiment sur de comment interfacer tes classes ensembles, tu sais qu'il ne faut pas trop coupler ton code mais ça semble tellement pénible, ... et le lendemain tout est clair. Tout ce qui semblait complexe est soudainement clair, simple et compréhensible, c'est même beau. En lisant 2-3 classes d'un projet tu comprends tout de suite comment c'est architecturé, comment construire la suite, etc. A chaque fois que je termine un module, je suis super content car je sais que ce code est capable de survivre facilement à mon départ un jour et que mon successeur sera capable de prendre la suite facilement.

Pour Javascript, je pense que faire de la programmation basé sur les prototypes c'est vraiment passer à côté de la force du langage qui est le paradigme fonctionnel. Si la POO demande pas mal de boilerplate pour fonctionner, les prototypes en JS c'est de loin la taille au dessus. L'exemple en page 2 ou 3 avec Object.defineProperty c'est juste horrible, je n'ose même pas imaginer devoir décrire mes objets par ce biais. A mon avis JavaScript devrait pousser du côté fonctionnel, cette façon de coder compense le manque de typage niveau stabilité et rend les tests unitaires très simples.

Si JS est largement utilisé de nos jours c'est entre autres pour cette grande flexibilité. Le souci c'est que le langage "souffre" de sa simplicité de la même manière que PHP à souffert de la sienne. Comme c'est très simple de faire un truc qui marche dans ces langages, il y a beaucoup de novices, ce qui n'est en soit pas un mal sauf quand ces novices sont propulsés à des postes qui demandent des compétences plus grandes (coucou les SSII) ou pire qu'ils pensent avoir tout compris à l'informatique. On vient de virer un collègue qui après 5 ans d'expérience en front-end ne savait pas sélectionner une div ou utiliser les constructions de base du JS (genre map, filter, for..in), il faisait son taf en abusant des libs type lodash et de stack overflow, et forcément un jour ça se voit.

Bref peace les gars, vous savez tous que chaque langage est mieux adapté à certains cas que d'autres. Cette conversation pourrait être super intéressante comme comparaison de paradigmes basé sur des expériences vécues et tout le monde pourrait en sortir grandi, il suffit de mettre un peu d'eau dans son vin (ne faites pas ca en vrai, c'est dégeu )
4  0 
Avatar de SpaceFrog
Rédacteur/Modérateur https://www.developpez.com
Le 18/06/2018 à 9:09
Quelle joute

Ca fait dix ans que tout le monde tire à boulets rouge sur JS en lui reprochant de ne pas être un véritable langage, d'être permissif, non structuré, d'être un ramassis de bricolages, de ne pas être compilable, mal foutu et que sais-je encore,.
Ca fait dix ans que l'on nous promet des langages qui vont sois-disant balayer JavaScript...
Ca fait dix ans que Javascript résiste...
C'est sans doute que malgré ses faiblesses il doit répondre à certains besoins ?
4  0 
Avatar de fredoche
Membre extrêmement actif https://www.developpez.com
Le 17/06/2018 à 14:33
Donc toi qui connait bien le Javascript et le pratique depuis 10 ans ne sait pas qu'un objet en JS est un tableau associatif ?

Tiens ... tu mourras moins bête ... mais tu mourras quand même... dixit le professeur Moustache
https://developer.mozilla.org/fr/doc...ser_les_objets

On peut aussi définir ou accéder à des propriétés JavaScript en utilisant une notation avec les crochets (voir la page sur les accesseurs de propriétés pour plus de détails). Les objets sont parfois appelés « tableaux associatifs ». Cela peut se comprendre car chaque propriété est associée avec une chaîne de caractères qui permet d'y accéder. Ainsi, par exemple, on peut accéder aux propriétés de l'objet maVoiture de la façon suivante :

maVoiture["fabricant"] = "Ford";
maVoiture["modèle"] = "Mustang";
maVoiture["année"] = 1969;
3  0 
Avatar de valaendra
Membre éclairé https://www.developpez.com
Le 18/06/2018 à 9:24
Citation Envoyé par Sodium Voir le message
1) C'est beaucoup trop lent. PHP est devenu fréquentable depuis sa version 5.4 sortie en 2012 et n'a plus grand-chose à envier à ses concurrents depuis la version 7 sortie fin 2016. JavaScript est encore loin d'être au niveau de PHP 5.4
2) Le langage ne doit pas évoluer mais se transformer. Il faut que son paradigme parte aux oubliettes. Quand il sera enfin à la hauteur de ses concurrents, il ne s'agira plus du tout du même langage et acquérir une expérience dans le JavaScript actuel est donc une perte de temps
3) JavaScript est exécuté côté client et le programmeur est donc dépendant de l'interpréteur. Lorsque qu'il sera devenu un langage réellement intéressant, il faudra au minimum 10 ans pour qu'on puisse l'utiliser tel sans craindre de se couper d'une masse importante d'utilisateurs (et quand tu travailles en entreprise, tu as beau n'avoir que 2 ou 3% d'utilisateurs avec des machines et/ou navigateurs obsolètes, souvent ce sont 2 ou 3% d'utilisateur dont on ne peut pas se permettre de perdre le chiffre d'affaire)
J'ai rarement vu un tel condensé d'arrogance, vos interventions méritent... Heu ben pas grand chose finalement !

1) Pourquoi vouloir absolument comparer PHP et Javascript ? Ils ont tous 2 une philosophie et une histoire bien différente...

2) Apprendre PHP 3 était obsolète puisque le code n'était presque plus utilisable sous PHP5. Apprendre PHP4 était obslolète car une bonne partie du code n'est plus utilisable avec PHP7 (on a même des fonctions PHP5 qui n'existent plus sous PHP7, dingue non ?). Apprendre PHP7 est obsolète car une bonne partie du code ne sera plus utilisable sous PHP9... On continue ? Les langages évoluent et se transforment que vous le vouliez ou non.
Le développeur se doit de s'adapter au langage ou contribue à son évolution (râler sur un forum n'est pas une contribution).

3) Je vous invite à vous documenter sur Javascript... Ne serait-ce que pour votre culture personnelle.

4) Faut-il également qu'on parle de l'incohérence des noms de fonctions PHP (camelCase par ci, underscore par là, "2" et "to" .. etc...) ou de l'ordre de leurs paramètres hasardeux ? PHP est également un langage "bricolé" et qui, à la base, était un langage de templating, rien de plus.
3  0 
Avatar de ijk-ref
Membre éclairé https://www.developpez.com
Le 18/06/2018 à 16:40
Citation Envoyé par fredoche Voir le message
(…) par quel langage tu souhaiterais remplacer Javascript
WebAssembly comme ça tout le monde pourra utiliser le langage qu'il souhaite
3  0 
Avatar de grunk
Modérateur https://www.developpez.com
Le 15/06/2018 à 11:05
Que pensez-vous de l’approche adoptée par Microsoft ?
Peros j'ai déjà eu à écrire des UI en :
- HTML/CSS/JS
- QT
- MFC
- Swing
- JavaFx
- Android

et très clairement le combo html/css est le plus facile à mettre en oeuvre dès qu'on à besoin de personnaliser son UI. On peut aller très loin sans difficulté particulière , là ou d'autre demanderais des surcharge de classe et autre joyeuseté.

Pas étonnant donc que l'accent soit mit sur cette techno quand c'est possible pour réaliser des UI.
2  0