IdentifiantMot de passe
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 !

Microsoft serait en train de réécrire certains de ses outils et logiciels en JavaScript :
Office 365, Teams, Skype, VS Code et probablement d'autres

Le , par Michael Guilloux
167 commentaires

827PARTAGES

9  2 
Quel est l'intérêt d'écrire ou réécrire un logiciel en JavaScript ? Voici une question qui a récemment fait couler beaucoup d'encre dans une discussion sur Developpez.com. Si certains considèrent JavaScript comme un cancer qu'il faut éradiquer, pour d'autres c'est plutôt LE langage de demain.

Cette dernière position peut s'expliquer en partie par le fait que le destin des langages de programmation est lié à leur écosystème et JavaScript bénéficie d'un vaste écosystème. D'abord, les navigateurs Web qui ne jurent que par JavaScript sont des plateformes largement déployées. Mais en plus, des plateformes comme Node et Electron - qui reposent sur JavaScript - sont très largement répandues. Ce qui fait qu'avec JavaScript, vous pouvez facilement cibler certains frontends et backends avec le même code. JavaScript aurait également d'autres avantages à en croire le témoignage de mister3957 :

Après avoir refait pas mal de services jusqu'alors écrits en C++ pour les passer en JS, j'y ai vu pas mal d'intérêts :
- Plus facile à maintenir
- Les artefacts sont plus rapides à construire (donc time to market plus intéressant)
- Plus facile à déboguer
- Courbe d'apprentissage largement réduite
- Portabilité (sauf dans de rares cas, quand ça utilise des modules natifs spécifiques)
- Ecosystem riche et ouvert
- Compétences accessibles sur le marché
- Asynchrone

Il y en a juste un qui est resté en C++ car demandant pas mal de puissance et de maîtrise entre la mémoire et le CPU, mais consommé au travers de JS.
Ces avantages semblent l'emporter sur le fait que l'écosystème JS évolue très vite ; ce qui nécessite une veille constante et de s'adapter pour ne pas se retrouver rapidement avec du code périmé.

On peut dire aujourd'hui que JavaScript a aussi de grands fans parmi les géants de la technologie, y compris Microsoft, comme le laisse deviner le titre de cette actualité : Microsoft serait en train de réécrire bon nombre de ses outils et logiciels en JavaScript. L'information provient de Sean Thomas Larkin, Technical Program Manager pour la plateforme Web de Microsoft.

« 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 », a-t-il dit dans un message publié il y a quelques heures sur Twitter. Avant de compléter la liste des outils et logiciels de Microsoft qui sont également en train d'être réécrits en JavaScript : « Et Skype, et Microsoft Teams, et Visual Studio Code, et tout le protocole de débogage de Microsoft Edge (au lieu de C ++) », a-t-il ajouté.


Rappelons également que Microsoft a récemment ajouté à Excel la possibilité d'écrire des fonctions personnalisées en JavaScript, ce qui laisse croire que Microsoft a une politique de plus en plus orientée vers JavaScript. Mais quel est le but ?

Source : Sean Thomas Larkin (via Twitter)

Et vous ?

Que pensez-vous de la réécriture des outils et logiciels de Microsoft en JavaScript ?
Quels pourraient être les bénéfices pour Microsoft, les développeurs et les utilisateurs finals ?

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

167 commentaires
Commenter Signaler un problème
ijk-ref
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 
Pyramidev
Avatar de Pyramidev
Expert éminent https://www.developpez.com
Le 14/06/2018 à 13:48
Citation Envoyé par Marco46 Voir le message
Citation Envoyé par GordonFreeman Voir le message
Mais malgré toutes les 'évolutions' de JS, tu n'as toujours pas (et surement jamais) :
de typage statique correct
Comme je te le disais, son utilité est tout à fait discutable en fonction du projet. C'est une lourdeur souvent inutile dans la plupart des projets de gestion, on peut parfaitement utiliser d'autres outils pour avoir du contrôle de type aux besoins endroits aux bons moments plutôt que de l'avoir partout.
Le typage statique est une bonne chose, surtout quand un langage le supporte correctement.
  • L'intérêt le plus connu du typage statique est de renforcer les contrôles lors de l'analyse statique du code. Dans un article, tu as écrit « Aujourd'hui l'usage d'un linter dans les projets ne fait plus débat, c'est obligatoire. L'absence d'usage d'un linter est un signal fort indiquant un manque de professionnalisme et de sérieux ». Eh bien, le typage statique, c'est un peu pareil : tu peux le voir comme une extension du linter.
  • Un autre intérêt du typage statique est de faciliter l'optimisation quand le code est compilé.
  • Dans certains cas, le type joue un rôle de documentation. Par exemple, quand on code une fonction, on veut souvent signaler à l'utilisateur ce qu'il a le droit de passer en paramètre. Mais c'est encore plus fort que de la documentation, car il s'agit d'une information exploitable par les outils pour analyser le code et éventuellement l'optimiser.
    Dans d'autres cas, on n'a pas envie d'écrire explicitement le type d'une variable. Un bon langage permet alors de faire de l'inférence de type. Certains langages sont plus forts que d'autres à ce niveau. Par exemple, Haskell est excellent en inférence de type. Dans ce langage, dire que le typage statique est lourd serait saugrenu.


Citation Envoyé par Marco46 Voir le message
Citation Envoyé par GordonFreeman Voir le message
de pas de compilation -> ça pète au runtime.
Quand on dev en amateur c'est possible. Si tu testes sérieusement tes applis ça ne peut pas arriver avec une bonne couverture.
Il n'est pas toujours souhaitable d'obliger le client à attendre que le réusinage de code et les tests unitaires soient terminés avant d'utiliser une certaine fonctionnalité. Parfois, le client a vraiment besoin d'utiliser une fonctionnalité à une certaine date avant que le travail ne soit fini, même s'il y a un risque de bogues. Alors, on finit le travail pendant que l'utilisateur a déjà accès à la fonctionnalité.

De manière générale, il est souhaitable de pouvoir écrire un programme fiable même avant d'avoir le temps et les moyens d'effectuer une couverture à 100% de tests unitaires.
8  0 
Avatar de
https://www.developpez.com
Le 13/06/2018 à 22:45
Ce tweet a pas mal buzzé et si vous allez le lire et sa suite vous y trouverez des réponses à vos questions. L'auteur a également posté un commentaire sur Reddit pour expliquer plus en détail (https://www.reddit.com/r/programming...debug/e0ll1dt/)

En gros :
- Il parle bien d'utiliser TypeScript.
- Ils ne réécrivent pas tout, en gros si je comprend bien ils partent sur une architecture de microservices et lient le tout avec du JavaScript.
- Ils utilisent React Native adapté pour toutes les plateformes pour ce faire.
7  0 
Sodium
Avatar de Sodium
Membre extrêmement actif https://www.developpez.com
Le 14/06/2018 à 9:53
Le mot clé class c'est du sucre syntaxique (créer uniquement pour faire plaisir a ceux qui refuse d'apprendre le fonctionnement des prototype), qui au final n'a pas sa place en JS vue que c'est de la POO orienté Prototype et non par Class.
En arrière plan le mot clé class sera toujours convertie en Prototype.
https://developer.mozilla.org/fr/doc...érateurs/class
Si l'on veut utiliser des classes, ce n'est pas que l'on refuse d'apprendre la programmation par prototype, c'est que :
1) La programmation par prototype est dégueulasse et ton exemple montre bien à quel point même un code très simple devient difficilement lisible.
2) Un développeur est forcément au cours de sa carrière amené à travailler avec de multiples langage et devoir utiliser un syntaxe particulière juste pour UN langage qui ne fait rien comme tout le monde est pénible.
7  0 
GordonFreeman
Avatar de GordonFreeman
Membre éclairé https://www.developpez.com
Le 13/06/2018 à 17:08
Citation Envoyé par psychadelic Voir le message
Non c'est pas une blague, et peut être qu'a la longue tout ceux qui ont des préjugés négatifs sur JavaScript vont peut-être se rendre compte que c'est un langage comme un autre avec lequel on peu tout faire, et même beaucoup mieux dès lors qu'on est dans des systèmes répartis, etc...
Pourquoi des préjugés ? Tu es sûr que ce n'est pas toi qui fait fait un préjugé!
Peut-être que les personnes qui émettent des critiques sont des personnes qui connaissent le langage, ses avantages (..) et ses faiblesses tout simplement.
Perso je déteste Javascript (pour X et Y raisons) et ça fait 15 ans que j'en fait...

Citation Envoyé par psychadelic Voir le message

PS: et on peu t'ajouter à la liste de ceux s'imaginent que TypeScript et JavaScript sont dans des mondes séparés...
Perso je vois pas ou tu veux en venir avec tes différents posts à ce sujet (J'ai peut-être pas compris ).
Si j'écris une appli en C++ et que je la compile vers telle ou telle plateforme il en résulte de l'assembleur, mais ça reste une appli écrite en C++.
Si j'écris une appli en Java, elle est pré-complié en bytecode, mais ça reste une appli Java.

Au final peu importe le langage vers laquelle est transpilé ton code pour être exécuté, la maintenance, l'évolution et l'écriture se fera dans le langage source.
6  0 
psychadelic
Avatar de psychadelic
Expert confirmé https://www.developpez.com
Le 13/06/2018 à 15:14
Citation Envoyé par Chuck_Norris Voir le message
Ils réécrivent leurs logiciels en JavaScript...
Et il y a pas si longtemps, ils ont quand même créé TypeScript parce que JavaScript ne leur convenait pas.
La question que je me pose, c'est si la girouette de Microsoft est elle aussi codée en JavaScript ?
SVP Arrêtez de croire que TypeScript et JavaScript soient 2 langages completement distincts

Les programmes écrits en TypeScript doivent être "traduits" en JavaScript pour être exécutable. transcompilé)
cette opération est faite automatiquement dans les EDI (comme VisualStudioCode), et en général on y ajoute aussi un minification)

Rien n'interdit dans un même projet de faire coohabiter du code TypeScript et JavaScript, (des librairies JavaScript principalement).

CoffeScript et d'autres langages sont aussi tranpilables vers Javascript, il doit y en avoir une douzaine.

Le système de transpilation est aussi utilisé pour faire du code CSS (SASS ou LESS, ...) et même du HTML (Jade...)

Bref quand Microsoft parle de tout réécrire en JavaScript, il parlent bien sur du langage ciblé, mais j'imagine que leur équipes travaillent plutôt en TypeScript.

Microsoft a énormément amélioré Electron (un truc dans NodeJS) pour faire tourner Visual Studio Code (entre la premiere version et l'actuelle c'est le jour et la nuit point de vue vitesse et fonctionnalités).
6  1 
Sodium
Avatar de Sodium
Membre extrêmement actif https://www.developpez.com
Le 14/06/2018 à 6:55
J'ai plutôt eu l'impression qu'il s'agissait surtout ici de JavaScript Bashing mené par des FanBoys C / C++ ...
Encore une fois il est stupide de parler de bashing de la part de fanboys de tel ou tel langage.
Il faut arrêter de prendre les gens pour des neuneus, nous sommes nombreux ici à détester JavaScript justement parce que nous le connaissons (trop) bien.
5  0 
Avatar de
https://www.developpez.com
Le 14/06/2018 à 9:57
Citation Envoyé par psychadelic Voir le message
J'ai plutôt eu l'impression qu'il s'agissait surtout ici de JavaScript Bashing mené par des FanBoys C / C++ ...
Oui ce doit être le complot franc-maC++, en aucun cas une réaction à un troll "Microsoft serait en train de réécrire certains de ses outils et logiciels en JavaScript" (à la place de C++) qui vanterait les merveilleux avantages du JS (à la place de C++) et que seul JS, qui est le meilleur langage du monde, possède (à la place de C++).
5  0 
Sodium
Avatar de Sodium
Membre extrêmement actif https://www.developpez.com
Le 14/06/2018 à 12:44
Comme je te le disais, son utilité est tout à fait discutable en fonction du projet. C'est une lourdeur souvent inutile dans la plupart des projets de gestion, on peut parfaitement utiliser d'autres outils pour avoir du contrôle de type aux besoins endroits aux bons moments plutôt que de l'avoir partout.
Une première utilité commune à tout projet, c'est déjà de voir en direct quand l'on fait des conneries dans son code.
En TypeScript si tu envoies une variable du mauvais type à une fonction l'ide le souligne tout de suite et ça évite d'avoir à s'en rendre compte au moment de l'exécution du programme.

Osef. C'est une excellente chose de ne pas avoir ce gloubi boulga inutile de classes. La bonne brique de base pour programmer c'est la fonction, pas la classe.
Désolé mais c'est juste de l'argumentation de développeur débutant.
Effectivement, les classes, l'héritage, l'injection de dépendances, le typage fort etc ça ressemble à des contraintes ou à de la complexité inutile ... et puis on prend de l'expérience et l'on commence à comprendre l'intérêt de la chose.
Je vois que tu es inscrit à ce forum depuis 2005, si ça fait plus de 10 ans que tu codes et que tu en es encore à dire que la programmation à base de classes ça ne sert à rien, je trouve ça triste et je n'aimerais pas être ton employeur.
7  2 
Pongten
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 
Commenter Signaler un problème