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 !

TypeScript entre dans le top 20 des langages les plus populaires
D'après le classement Redmonk de juin 2017

Le , par yahiko
79 commentaires

1KPARTAGES

16  0 
L'adoption de TypeScript poursuit son bonhomme de chemin
et progresse significativement


Le rapport semestriel RedMonk sur la popularité des langages publié en février dernier montre une progression significative du langage TypeScript dans la communauté des développeurs, notamment via les sujets postés sur StackOverflow.

À comparer avec sa position à la même période en 2015
[spoiler]
[/spoiler]

La synthèse du rapport mentionne d'ailleurs TypeScript comme l'un des langages en dehors du top 10 ayant réalisé une performance notable au semestre passé.

L'un des langages intéressants à suivre, bien que bénéficiant d'une faible promotion, est TypeScript. Citoyen de premier ordre relativement nouveau dans la galaxie Microsoft, ce surensemble (open source) de JavaScript gravit tranquillement les échelons. Dans son classement, TypeScript est monté de deux crans, de la 33e à la 31e place, dépassant ASP au passage. Évidemment, il est loin d'arriver au niveau de JavaScript, mais la liste des technologies qu'il dépasse ne cesse de s'allonger : ASP (32e), OCaml/TCL (33e), Cold Fusion/DART (37e), entre autres, ainsi que les autres langages en progression comme Elixir, Julia ou Rust. Il n'est pas raisonnable de s'attendre à une croissance explosive de TypeScript, mais il ne serait pas surprenant de le voir atteindre la 20e place, et devenir bien plus visible. Quoi qu'il en soit, il est devenu un langage à suivre.
Source : RedMonk

Et vous ?

Utilisez-vous TypeScript ? Qu'en pensez-vous ?
Vous avez lu gratuitement 642 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.

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

79 commentaires
Commenter Signaler un problème
koyosama
Avatar de koyosama
Membre éprouvé https://www.developpez.com
Le 22/06/2017 à 19:37
Citation Envoyé par codec_abc Voir le message
Le principal avantage de Typescript c'est le typage statique (ie, détecté les erreurs - au moins une partie - avant l’exécution) et à moins d'avoir raté un épisode je crois pas que les prochaines versions de Js s'orientent dans cette voie. Donc il y a aura toujours quelque chose que Ts fera que Js ne fera pas. Après, libre à chacun d'estimer le gain ou la perte d'un système de type statique vs dynamique. Pour moi le choix est vite fait, à partir de plus de 20 lignes de code je vois déjà l’intérêt.
Je ne pense pas que c'est que statique vs dynamique. Je travaille avec JS / C# et Typescript. Je peux te dire que le typescript ressemble plus a C# que Javascript.
La facont dont tu ecris le code est completement different.

Apres les erreurs avant et apres, tu les auras forcement dans tous les language, c'est pour sa qu'on se fait chier a faire des logs, des try-cactch, des proxy pattern, etc ...
Javascript est plus proche du fonctionnal programming, alors que typescript est plus proche de l'imperative.

Pour avoir essayer de creer une framework sous Javascript et sous Typescript, il y a une *** grosse difference. Dans Typescript tu as cette motion d'encapsulation alors que Javascript c'est derisoire. La syntax est aussi un peu different quand on regarde bien. Et la compilation joue un mega role super important qui permet a un developpeur de pouvoir regler les erreurs basique de programmation tel que la syntax ou le type. Mais le type tu peux tricher. C'est justte que c'est plus simple que le compilateur me crache a la geule que je fasse des erreurs d'utilisation de mes fonctions. Et puis le compilateur joue un autre role que le developpeur ne voit pas souvent, il optimise ton code a mort. Par exemple, imaginons que ce projet (prepack) marche, il peut tres bien etre integrer au compilateur typescript. Le compilateur c'est pas que verifie les erreurs. Google par exemple ompile different versions de Chrome pour differentes platforme car tu as besoin d'optmiser la memoire pour cetaine machine, mais d'autre la performance. Voir cette video lighthouse. Et le compilateur tyepscript fera sa dans le futur pour cibler quel type d'optimisation tu as besoin.

Apres ES6 a apport e le sugar syntax de la creation de classe, c'est avoir PHP 4 avec le systeme de classe qui est apparu mais n'est pas encore totalement bien foutu. Par example mettre en private les variables dans une classe c'est chiant.
Tu vas me dire qu'on a pas besoin de l'encapsulation dans un code Javascript puisque de toute facon a acces au code et on doit toujours proteger les transaction clients / serveur par de meilleurs controle cote serveur.
Sauf que cette reflexion ne s'applique pas que je fais un jeu mobile ou un RPG avec RPG maker MV par exemple, j'ai besoin de cacher des information pour eviter que le joueur cheat par exemple ou encore avec Electron, les applications offline en gros.

Je me rappelle encore des gens qui me disaient il y a 5 ans que c'etait une heresie de voir le terme class dans Javascript ou encore PHP 6 avait ete anule parce que le comite ne voulait pas de typage fort, ben il est dans PHP 7 pas grave.
ES8 n'est pas encore sur papier et ES7 n'est pas encore termine ou meme pas commence. Et quand tu regardes les propositions de ES7, surtout celui la, tu vois qu'il devient, sur certains aspects, le meme que les autres langages.

Javascript evolue plus dans le sens de NodeJS pour servir NodeJs que pour servir Javascript Client. Parce que demain on va faire des software avec electron, des jeux en Javascript pour les plateformes. Le single thread principle de NodeJS va peut etre disparaitre. D'ailleurs Google a choisi Typescript parce que la syntax actuel de Javascript est super complique pour faire ce qu'il veut faire avec angular JS 2 et 4.

En fait, on te l'a pas dit mais Javascript c'est le nouveau Java ^^.
1  0 
codec_abc
Avatar de codec_abc
Membre confirmé https://www.developpez.com
Le 22/06/2017 à 23:54
1. La fonctionnalité est assez pauvre. C'est juste un partage d'un tableau de bytes avec des opérations atomiques dessus. On est loin des primitives de la programmation concurrente d'un langage haut niveau (mutex/sémaphore, queue thread-safe, etc..). En l’occurrence c'est plutôt ce que l'on retrouve quand on fait de la programmation sur GPU.

2. C# est pas mal orienté coté fonctionnel. Les classes Func<T> et Action<T> permettent de retourner ou passer en paramètres des fonctions. Linq a bien poussé C# du coté fonctionnel aussi. Certes on pas du niveau de F#/Haskell/Idris/.... mais c'est pas si mal. Après les gens qui le pratique depuis longtemps ont surement un état d'esprit très "OO" s'ils ont pas fait l'effort de se tenir à jour des évolutions du langage.

3. Même si je préfère de loin les langages typés statiquement le passage cité de l'étude est étrange. Ruby et Clojure sont typés dynamiquement et Scala est bourré de "gotcha". En plus python est très similaire à Ruby et j'ai du mal a concevoir comment l'un peut-être dans une catégorie et l'autre dans celle opposé. Pour avoir regarder le papier en diagonale la méthodologie me parait approximative. D'ailleurs la phrase qui suit ta citation est la suivante : "One should take care not to overestimate the impact of language on defects". Bref on est d'accord sur le fond mais c'est clairement pas le meilleur argument pour les langages à typage statique.
1  0 
codec_abc
Avatar de codec_abc
Membre confirmé https://www.developpez.com
Le 23/06/2017 à 11:34
Citation Envoyé par koyosama Voir le message


Il y a utilisattion et technicite, d'ou ce qu'on appelle les bonnes pratique et le permissif.
Tu veux dire quoi par la ?

Citation Envoyé par koyosama Voir le message

Sa contredit le message d'au dessus.
Pas du tout, déja il n'y a aucun rapport entre le paradigme d'un langage et son système de type. Erlang est fonctionnel et dynamique. Haskell fonctionnel et statique. Ruby est OO et dynamique alors que Java est OO et statique.

Citation Envoyé par koyosama Voir le message

En fait je partais dans l'hypothese d'un interet futur. Typescript est tres tres jeune encore. Je regarde aussi par rapport sur quoi il est succeptible de copier et le plus proche est peut etre GCC a mon sens. Sans compte que j'ai vu le code qui generait derriere, et me demande si c'est pas plus simple de voir un intermediaire genere du code a ta place. Tu as raison sur Transpileur et Compilateur.
J'ai pas vraiment compris ce que tu veux dire mais comparer Ts à GCC c'est quand même le jour et la nuit. Le premier est un transpileur vers Js le deuxième un compilo qui génère du code natif (souvent pour des langages sans GC en plus).

Citation Envoyé par koyosama Voir le message

Mouais et alors. Apres j'ai appris que google etait un bon magicien quand ile le voulait. Et en plus j'ai entedu les meme arguments sur Ruby et bizrrement cette annee, il y a le hype de la programmation concurrente sur Ruby en ce moment.
Magicien ou pas le Js est quand même un mauvais langage pour faire de la prog très performante en termes de vitesse d'éxécution. D'ailleurs Google pousse aussi wasm. Ensuite pour Ruby tu parles de programmation concurrente ou parallèle ? Parce que il me semble que Ruby souffre aussi d'un Global Interpreter Lock. Et puis Ruby niveau perf....

Citation Envoyé par koyosama Voir le message

Non je voulais jsute blaguer un peu. Je voulais dire que le nouveau truc hype avec un system de module sur module comme Java et aussi qu'il evolue a la vitesse que Java prenait a l'epoque. En fait Java est le language le plus demande dans les entreprise selon le parametre de TIOBE.
Qui aurait pu penser que firefox aurait ete battu par chrome, ou encore que IE6 par firefox.

^^ Tu as peu etre raison. Je ne sais pas de quoi je parle. Comme indique en haut, on s'est bien foutu de ma geule avec typescript, je m'attendais a ce qu'un gars sur developpez me fasse la meme reflexion.
Apres je peux comprendre avec le flop de dart et durant ce flop, je me souviens de la conference microsoft qui disait qu'il faut pas creer un nouveau language mais ameliorer et supporter Javascript.
Je me fous pas de ta geulle comme tu dis mais je pointe juste les incohérentes qu'il y a dans tes propos. Je considère Ts comme un pas en avant par rapport à Js.

Citation Envoyé par koyosama Voir le message

Assembly c'est pas pour maintenant et c'est pas encore stable, c'est aussi affirmatif de dire que dart allait remplacer Javascript ^^ ou d'attendre que les entreprises arrent d'utiliser Objective-C pour la programmation IOS. C'est une migration c'est pas 5 minutes ><.
Certes mais pour les besoins de perf c'est le jour et la nuit avec Js. Les premières démo qui sont sorties permettent d'avoir un gain de x2-x10 par rapport à Js.
1  0 
Paleo
Avatar de Paleo
Membre éclairé https://www.developpez.com
Le 30/06/2017 à 16:40
Ah, je mettrais plutôt un "-1" pour ses arguments approximatifs.

Citation Envoyé par ludojojo Voir le message
TypeScript te permet seulement avec sa propre écriture, de générer le code JS que tu n'es pas capable de faire correctement.

C'est improbable de dire ça, du TypeScript n'est pas du JavaScript. C'est un langage qui à été introduit par Microsoft dans le but d'offrir aux développeur de son écosystème VB.Net de se reconvertir tant ce dernier est en perte de vitesse. C'est pour cela que le style d'écriture en est si proche.
Un exemple de code en TypeScript :

Code : Sélectionner tout 
1
2
3
4
5
6
7
8
9
10
interface Options {
	upperCase?: boolean
	author?: string
}
function makeMessage(content: string, options: Options = {}) {
	let m = options.author ? `${options.author}> ${content}` : content
	if (options.upperCase)
		m = m.toUpperCase()
	return m
}
Le même code en JavaScript :

Code : Sélectionner tout 
1
2
3
4
5
6
function makeMessage(content, options = {}) {
	let m = options.author ? `${options.author}> ${content}` : content
	if (options.upperCase)
		m = m.toUpperCase()
	return m
}
Il faut expliquer comment un développeur serait capable de préciser le typage à la sauce TypeScript mais incapable de le retirer ?
Et on cherche où se trouve le rapport avec du code VB.net.
1  0 
SylvainPV
Avatar de SylvainPV
Rédacteur/Modérateur https://www.developpez.com
Le 01/07/2017 à 14:21
@Paleo: Pas sûr de comprendre la question, mais ce qu'il veut dire, c'est que tout ce qui est fait en TypeScript peut également être fait en JavaScript puisque c'est le langage cible du compilateur. Les extensions du langage fournies par TypeScript ne sont que des aides de développement pour améliorer l'analyse statique et expliciter le typage et les structures de données. On pourrait imaginer faire la même chose avec uniquement des commentaires, c'est d'ailleurs ce que peut faire Flow avec Flow Comments.

Ça me paraît important à rappeler car beaucoup ont tendance à voir TypeScript comme un nouveau langage alors qu'il s'agit seulement d'une série de contraintes et de verrous que le développeur ajoute lui-même par-dessus son code JavaScript pour en limiter la permissivité. Je ne dis pas que c'est un bien ou un mal, ça me paraît utile dans les projets à grande équipe ou avec des débutants, ou alors pour fiabiliser les développements critiques et produire des indicateurs qualité. Mais objectivement, on peut s'en passer si on sait ce qu'on fait et qu'on veut aller plus vite.

Ce qui me dérange également, c'est qu'on a banalisé le fait que ce soit "normal" d'avoir une phase de compilation pour le code front-end, même en mode développeur. Alors que clairement tous les problèmes (bug de source maps, performance, limitations des compilateurs...) ne sont pas résolus. A l'époque où on a commencé à généraliser le code en ES6 et l'utilisation de Babel, l'argument phare était qu'on pourrait retirer cette phase de compilation plus tard quand ES6 serait supporté nativement sur les navigateurs. Et ben voilà on y est, >80% de support ES6 natif dans les navigateurs, mais on a rien retiré pour autant: pire, maintenant on écrit du code non standard avec TS/Flow ou des plugins Babel pour des specs abandonnées ou qui n'existent pas du tout.

Sur mon dernier side project, je code directement en ES6+ et avec les modules ES. J'ajoute par ci par là du typage fort au runtime avec ObjectModel. J'utilise les dernières features CSS comme les Grid ou les variables CSS. Eh bien tout ça fonctionne parfaitement sur Chrome sans aucune compilation ! Et c'est un bonheur d'avoir zéro temps d'attente au hot reload, de ne pas avoir à galérer avec les source maps buggées, de ne pas se poser la question si le compilateur est lancé et a bien fait son boulot. J'ai l'impression qu'on a tellement été dans notre bulle Babel/TS/Gulp/Webpack/[ajouter un énième outil intermédiaire] qu'on a oublié à quel point le process de dev pouvait être simple en front-end.

Bien sûr, on a encore besoin de tout l'attirail pour générer le bundle de production: conversion ES5, ajout des polyfills, module bundling, minification etc... mais je trouve très libérateur le fait de savoir que tout ça est facultatif, et ne sert qu'à étendre le support et augmenter les perfs.
2  1 
Paleo
Avatar de Paleo
Membre éclairé https://www.developpez.com
Le 01/07/2017 à 18:06
Ludojojo prétend qu'un développeur en TypeScript serait incapable d'écire du JavaScript. C'est juste faux, puisque TypeScript c'est JavaScript (tout le langage : la syntaxe, les API, les bonnes pratiques) plus des informations qui sont au fond les héritières des annotations JSDoc. Qui peut le plus peut le moins. Celui qui sait écrire du TypeScript sait aussi écrire du JavaScript.

Citation Envoyé par SylvainPV Voir le message
Sur mon dernier side project, je code directement en ES6+ et avec les modules ES. J'ajoute par ci par là du typage fort au runtime avec ObjectModel. J'utilise les dernières features CSS comme les Grid ou les variables CSS. Eh bien tout ça fonctionne parfaitement sur Chrome sans aucune compilation ! Et c'est un bonheur d'avoir zéro temps d'attente au hot reload, de ne pas avoir à galérer avec les source maps buggées, de ne pas se poser la question si le compilateur est lancé et a bien fait son boulot. J'ai l'impression qu'on a tellement été dans notre bulle Babel/TS/Gulp/Webpack/[ajouter un énième outil intermédiaire] qu'on a oublié à quel point le process de dev pouvait être simple en front-end.
Ah, intéressant. Avec les modules ES6 activés par le flag qui va bien alors ? J'ai lu à plusieurs reprises que les gros projets SystemJS souffrent de temps de latence en mode développement justement. Le chargement d'un arbre de dépendances n'est pas très parallélisable. Il me semble que la solution native ne fera pas forcément mieux. Ce qui serait un avantage intrinsèque pour les bundlers.

J'ai l'impression que les modules ES6 natifs pourraient à terme servir à charger des bundles composés eux-mêmes de modules "privés". J'ai l'impression que Webpack s'orientera par là, l'option "libraryTarget" sert à cela même si elle ne génère pas encore le format ES6.
1  0 
koyosama
Avatar de koyosama
Membre éprouvé https://www.developpez.com
Le 21/06/2017 à 8:45
Quand j'ai commencé typescript avec les premières versions et l'ai mis sur CV. Les recruteurs, les tech leaders se sont bien foutus de ma gueule. Après avec ce classement, ça fait extrêmement bizarre d'entendre cette soudaine popularité.
Maintenant, je suis revenu à la mode Vanilla JS car je suis déjà en train d'estimer que tout ce qui va apparaître dans typescript va apparaître avec ES6, 7 ou même 8 dans le futur. Je m'attendais pas du tout à ce que les initiatives d’évolution de Javascript aient eu lieu.
0  0 
codec_abc
Avatar de codec_abc
Membre confirmé https://www.developpez.com
Le 21/06/2017 à 13:07
Le principal avantage de Typescript c'est le typage statique (ie, détecté les erreurs - au moins une partie - avant l’exécution) et à moins d'avoir raté un épisode je crois pas que les prochaines versions de Js s'orientent dans cette voie. Donc il y a aura toujours quelque chose que Ts fera que Js ne fera pas. Après, libre à chacun d'estimer le gain ou la perte d'un système de type statique vs dynamique. Pour moi le choix est vite fait, à partir de plus de 20 lignes de code je vois déjà l’intérêt.
0  0 
yahiko
Avatar de yahiko
Rédacteur/Modérateur https://www.developpez.com
Le 21/06/2017 à 18:30
Citation Envoyé par sitexw Voir le message
Et ce, via le "strong mode", un sous ensemble de JavaScript dans le même genre que le "strict mode" mais en plus hard. L'objectif est de retirer tous les éléments de javascript qui le ralentissent ou qui le rendent trop permissif. Et dans la même continuité, un autre sur ensemble optionnel au "strong mode" permettant le typage static que l'on connaît aujourd'hui avec typescript est aussi dans les cartons.
En tout cas, JavaScript est très loin d'être sur ça fin, je dirais même qu'il en est qu'au début de son aventure et ce, même après 20 ans d'existence.
Tout d'abord le "strong mode" est une notion assez indépendante de la question du typage.
Types: We also intend to propose a (sound) gradual type system for JavaScript. This addresses similar goals, and can benefit significantly from some of the restrictions we propose here. However, it is a much more complex feature, and potentially interesting independent of strong mode. We hence defer such a type system to a separate proposal. Strong mode can be viewed as a transition path to such a typed JavaScript.
La réflexion de Google au sujet d'un "strong mode" est assez ancienne, de 2015 pour être précis. Un petit billet à ce sujet avait été publié sur developpez.com d'ailleurs où Google mentionnait explicitement vouloir s'inspirer de TypeScript : https://javascript.developpez.com/ac...le-JavaScript/

Depuis 2015, absolument aucune avancée ou réflexion supplémentaire sur le sujet n'a été publiée par Google, autant que je sache. A tel point que la page sur le sujet a disparu du site dédié au moteur V8...

Il est possible que le typage statique arrive officiellement dans JavaScript, mais autant se l'avouer tout de suite, ce n'est pas demain la veille, pour diverses raisons dont certaines relativement polémiques sur lesquelles j'ai déjà pu échanger avec des membres de ce forum et sur lesquelles je ne reviendrai pas. Donc en attendant ce jour tout à fait hypothétique, TypeScript peut tout à fait convenir à des personnes préférant travailler avec un langage proposant un typage statique, tout en étant très proche de JavaScript.
0  0 
codec_abc
Avatar de codec_abc
Membre confirmé https://www.developpez.com
Le 22/06/2017 à 20:03
J'ai pas l'impression que tu sais que vraiment de quoi tu parles.

Citation Envoyé par koyosama Voir le message
Je ne pense pas que c'est que statique vs dynamique. Je travaille avec JS / C# et Typescript. Je peux te dire que le typescript ressemble plus a C# que Javascript.
La facont dont tu ecris le code est completement different.
Oui justement, C# a (majortairement) un système de type statique alors que Js est dynamique.

Citation Envoyé par koyosama Voir le message

Apres les erreurs avant et apres, tu les auras forcement dans tous les language, c'est pour sa qu'on se fait chier a faire des logs, des try-cactch, des proxy pattern, etc ...
Javascript est plus proche du fonctionnal programming, alors que typescript est plus proche de l'imperative.
Les 2 langages sont multi-paradigme et tu peux très bien faire de la programmation fonctionnelle en Ts. Quant aux erreurs, plus le langages est strict moins tu aura d'erreurs au runtime. De plus, certains languages n'ont pas de système de try-catch et les logs n'ont pas pour but de gérer les erreurs mais de d'avoir une idée de l'état du système a posteriori.

Citation Envoyé par koyosama Voir le message

Pour avoir essayer de creer une framework sous Javascript et sous Typescript, il y a une putain grosse difference. Dans Typescript tu as cette motion d'encapsulation alors que Javascript c'est derisoire. La syntax est aussi un peu different quand on regarde bien. Et la compilation joue un mega role super important qui permet a un developpeur de pouvoir regler les erreurs basique de programmation tel que la syntax ou le type. Mais le type tu peux tricher.
Tu te contredis par rapport au début. Un compilateur/transpileur a 2 rôles : Garantir une certaine cohérence des sources et/ou générer du "code" de plus bas niveau (et peut-être l'optimiser au passage). En Ts, on a que le premier cas qui est uniquement utile grâce au fait que Ts est a typage statique.

Citation Envoyé par koyosama Voir le message

Apres ES6 a apport e le sugar syntax de la creation de classe, c'est avoir PHP 4 avec le systeme de classe qui est apparu mais n'est pas encore totalement bien foutu. Par example mettre en private les variables dans une classe c'est chiant.
Tu vas me dire qu'on a pas besoin de l'encapsulation dans un code Javascript puisque de toute facon a acces au code et on doit toujours proteger les transaction clients / serveur par de meilleurs controle cote serveur.
Sauf que cette reflexion ne s'applique pas que je fais un jeu mobile ou un RPG avec RPG maker MV par exemple, j'ai besoin de cacher des information pour eviter que le joueur cheat par exemple ou encore avec Electron, les applications offline en gros.
Comme Ts te génère du code Js je vois pas comment tu va protéger quoi que soit au runtime si l'utilisateur décide d'ouvrir la console (de chrome, FF ou autre) et de faire ce qu'il veut.

Citation Envoyé par koyosama Voir le message

Je me rappelle encore des gens qui me disaient il y a 5 ans que c'etait une heresie de voir le terme class dans Javascript ou encore PHP 6 avait ete anule parce que le comite ne voulait pas de typage fort, ben il est dans PHP 7 pas grave.
ES8 n'est pas encore sur papier et ES7 n'est pas encore termine ou meme pas commence. Et quand tu regardes les propositions de ES7, surtout celui la, tu vois qu'il devient, sur certains aspects, le meme que les autres langages.

Javascript evolue plus dans le sens de NodeJS pour servir NodeJs que pour servir Javascript Client. Parce que demain on va faire des software avec electron, des jeux en Javascript pour les plateformes. Le single thread principle de NodeJS va peut etre disparaitre. D'ailleurs Google a choisi Typescript parce que la syntax actuel de Javascript est super complique pour faire ce qu'il veut faire avec angular JS 2 et 4.
Js ne dispose pas de features dans le langage qui permet de faire du multi-thread. La seule chose qui s'en rapproche ce sont les web-workers qui sont des solutions du pauvre par rapport aux autres langages. De plus, j'ai pas l'impression que Js évolue plus pour une plateforme (le browser) que l'autre (NodeJs). En plus, pour le browser wasm arrive tranquillement donc ca m’étonnerai que Js et les VMs Js (V8, Chakra,...) évoluent pour faire de Js un langage qui supportent la programmation concurrente alors que son système de type est moisi. Le multi-thread ça sert avant tout à gagner en perf (et aussi bloquer le thread UI lors des longs calculs, mais pour le reste Js est asynchrone donc la programmation concurrente n'est pas utile). Sauf qu'en Js tous les nombres sont représentés par des doubles (ie nombre flottant sur 64 bits) ce qui est stupide quand on sait qu'ils sont beaucoup plus lent que les nombre entier ou flottant sur 32 bits. Bref, Js n'aura probablement jamais de programmatation concurrente car ce n'est utile que pour les langages qui peuvent offrir des performances correctes ce qui n'est pas son cas.

Citation Envoyé par koyosama Voir le message

En fait, on te l'a pas dit mais Javascript c'est le nouveau Java ^^.
Java est assez lourd à utiliser mais le comparer à Js c'est le dénigrer. Pour un langage sorti après Java, Js est assez mauvais et fait pas mieux voire souvent pire que Java dans tous les domaines.
1  1 
Commenter Signaler un problème