Discussion :

[Paleo]

il s'agit donc simplement d'utiliser les outils java avec les concepts java pour produire des applications JS.
je réponds donc à la personne qui dit que ces développeurs java on envie de rester dans leur univers que jsweet est une solution pour eux.

Ah, effectivement, j'aurais dû mieux lire le sous-titre, j'avais compris de travers qu'il s'agissait d'un site d'évangélisation pour aider à passer à la programmation JS les développeurs Java.

[yahiko]

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

Selon le nouveau classement de Redmonk du mois de juin 2017, il apparaît que TypeScript, le langage open source, surensemble typé de JavaScript, développé initialement par Microsoft, semble avoir gagné sa légitimité dans le paysage concurrentiel des langages Web.

Il est désormais et durablement installé dans le top 20 du classement de Redmonk, à la 17^e place pour être précis.

Cette progression, on ne peut plus remarquable, est très certainement à mettre sur le compte de son association avec le framework Angular 2 développé par Google.

En complément à cette vue d'ensemble, on trouvera ci-dessous un focus sur la progression sur l'année des principaux langages liés au Web. Le départ d'une flèche indique la position du langage un an auparavant, et l'arrivée d'une flèche, la position actuelle du langage concerné.

Évolution sur un an des principaux langages Web

Quelques précautions avant d'interpréter les progressions. Il faut noter que la méthodologie de Redmonk a changé durant l'année écoulée. Ces changements n'impactent que la composante horizontale des progressions puisque Redmonk ne prend plus en compte le nombre de dépôts sur GitHub, mais le nombre de pull requests (il se pourrait que votre humble serviteur a peut-être pu contribuer à ce changement, qui sait...). Ceci limite l'influence des dépôts « morts », sans activité, et tend à mieux refléter la dynamique des langages.

La composante verticale, relative à Stackoverflow, n'a pas été impactée par le changement de méthodologie et les évolutions sur cet axe peuvent être interprétées sans précaution particulière.

On peut par exemple supposer que la progression, assez modérée, du langage Dart essentiellement sur l'axe horizontal, est en partie due au changement de méthodologie du classement Redmonk.

Par contre, on notera une légère baisse, principalement sur la composante verticale, celle qui peut être interprétée sans restriction, du langage JavaScript. Est-ce là les premiers signes d'un essoufflement de la popularité du langage phare des développeurs Web au profit des nouveaux arrivants ? Il y a tout de même un gouffre que peu de personnes oseront franchir. Il est plus sage de voir si cette tendance se confirme ou pas à l'avenir.

On constatera à titre d'anecdote le fort décrochage sur un an du langage ActionScript d'Adobe. Il est probablement promis à la marginalité dans les années à venir, sauf révolution chez l'éditeur de Photoshop.

Comment interprétez-vous ce classement ?
Les positions et les évolutions vous surprennent-elles ?

[koyosama]

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.

[codec_abc]

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.

[kilroyFR]

Je trouve ca vraiment merité pour TypeScript car c'est un reel progres pour faire du javascript. Jamais compris comment un langage aussi degueulasse que js puisse avoir autant de succes et etre aussi laborieux a utiliser.
Une telle permissitivité dans un langage est pour moi un anti pattern absolu (le mot clé var etant le summum) car ca autorise a faire tout et n'importe quoi sans aucun controle.
Depuis que je fais du typescript je prends vraiment plaisir a coder en javascript. Merci a M$ pour ça, enfin quelque chose d'utile et vraiment productif.

[yahiko]

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.

[koyosama]

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 ^^.

[codec_abc]

J'ai pas l'impression que tu sais que vraiment de quoi tu parles.

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.

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.

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.

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.

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.

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.

[yahiko]

1. Concernant la programmation concurrente en JavaScript, à noter qu'une fonctionnalité permettant de dépasser les limitations des WebWorkers est à l'étude au sein du comité ECMAScript. Il s'agit du SharedArrayBuffer.

2. TypeScript propose le paradigme OO classique, mais ne l'impose pas comme en Java. Rien n'empêche d'écrire un programme TypeScript comme on écrit un programme JavaScript (c'est d'ailleurs la recommandation officieuse de l'équipe Microsoft qui n'encourage pas l'utilisation des classes) en mentionnant juste le typage lorsque cela est nécessaire. Il convient de rappeler que l'inférence automatique des types évite de tout typer explicitement. Si le code TypeScript côtoyé ressemble à du C#, c'est sans doute que les personnes qui ont codé viennent de cette culture, mais ce n'est pas un impératif du langage en lui-même. C'est un avantage à mon sens. Cela permet à la fois aux programmeurs venant du fonctionnel et à ceux venant de la POO d'appréhender facilement ce langage.

3. Les programmes codés dans des langages à typage statiques sont statistiquement moins sujets à bugs que ceux codés dans des langages à typages dynamiques. Voir l'étude à ce sujet menée sur la plateforme GitHub :

For those with positive coefficients we can expect that the language is associated with, ceteris paribus, a greater number of defect fixes. These languages include C, C++, JavaScript, Objective-C, Php, and Python. The languages Clojure, Haskell, Ruby, Scala, and TypeScript, all have negative coefficients implying that these languages are less likely than the average to result in defect fixing commits.

Néanmoins, ceux qui souhaitent continuer à programmer en JS sont toujours libres de le faire, mais il n'est pas exact d'affirmer que le typage statique n'apporte rien en terme de fiabilité.

[codec_abc]

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.

[koyosama]

J'ai pas l'impression que tu sais que vraiment de quoi tu parles.

Marrant, beaucoup de personne me dit sa et au final la plupart des choses que j'ai predit sont arrives ^^.

Oui justement, C# a (majortairement) un système de type statique alors que Js est dynamique.

Il y a utilisattion et technicite, d'ou ce qu'on appelle les bonnes pratique et le permissif.

Les 2 langages sont multi-paradigme et tu peux très bien faire de la programmation fonctionnelle en Ts.

Sa contredit le message d'au dessus.

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.

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.

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.

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.

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.

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.

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.

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 ><.

[yahiko]

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.

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. Avec les WebWorkers qui permettent le parallélisme, l'introduction du SharedArrayBuffer est une étape supplémentaire vers la concurrence. Ton affirmation

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.

est à mon sens excessive puisqu'à partir du moment où JavaScript dispose d'un mécanisme de mémoire partagée entre threads, il est possible de développer des bibliothèques avec les primitives que tu cites. L'obstacle ne me paraît pas du tout insurmontable. D'ailleurs, dès que les SharedArrayBuffer seront supportés par les navigateurs, il sera tout à fait possible de faire de la programmation concurrente en compilant du code concurrent C++ en WebAssembly (ou asm.js).

3. La citation choisie avait surtout pour intérêt de faire apparaître TypeScript. Pour le reste, il suffit de lire l'abstract et la conclusion pour voir que les langages à typage statique sont dans cette étude plus fiables que ceux à typage dynamique. Après, il est toujours possible de critiquer une étude, mais il me semble que c'est celle qui est la plus aboutie à ce jour sur le sujet. Après, il est un peu curieux de qualifier la méthodologie d'approximative quand on a soit même fait une lecture "approximative" (en "diagonale" si je reprends tes mots). N'hésite pas à exposer plus en détail tes reproches néanmoins. Il n'en reste pas moins qu'il s'agit d'une étude sérieuse, scientifique, même si probablement perfectible, comme tout, et que je ne connais pas de meilleur argument sur un tel sujet que la démarche scientifique.

[codec_abc]

Il y a utilisattion et technicite, d'ou ce qu'on appelle les bonnes pratique et le permissif.

Tu veux dire quoi par la ?

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.

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).

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....

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.

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.

[ludojojo]

Jamais compris comment un langage aussi degueulasse que js puisse avoir autant de succes et etre aussi laborieux a utiliser.
Une telle permissitivité dans un langage est pour moi un anti pattern absolu (le mot clé var etant le summum) car ca autorise a faire tout et n'importe quoi sans aucun controle.
Depuis que je fais du typescript je prends vraiment plaisir a coder en javascript. Merci a M$ pour ça, enfin quelque chose d'utile et vraiment productif.

Quand je lis un commentaire de ce type, je me dit que la population des développeurs à bien changé, et que c'est dommage.
Si tu ne comprends pas un langage, la puissance des prototypes, la puissance du non "typage fort" (car oui c'est quand même typé !) c'est simplement par ce que tu n'as pas de recule et que tu ne maitrise pas non plus les mécanismes interne de la POO !
La souplesse de JavaScript est l"une de ses forces.
TypeScript te permet seulement avec sa propre écriture, de générer le code JS que tu n'es pas capable de faire correctement.

Depuis que je fais du typescript je prends vraiment plaisir a coder en javascript

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.

[SylvainPV]

@ludojojo: +1, sans oublier que JavaScript a déjà ses propres armes pour ajouter du typage fort sans recourir à un autre langage. C'est l'objet d'un article que j'ai écrit hier soir (en anglais): https://medium.com/@SylvainPV/type-s...s-eee8fbbbd600

[Paleo]

Ah, je mettrais plutôt un "-1" pour ses arguments approximatifs.

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 - Visualiser dans une fenêtre à part

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 - Visualiser dans une fenêtre à part

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.

[SylvainPV]

@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.

[Paleo]

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.

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.

[SylvainPV]

Ah, ça c'était plus une attaque personnelle de bas étage qu'un vrai argument de la part de ludojojo. Je n'y ai même pas prêté attention, je plussoyais uniquement sa phrase en gras.

Oui les bundlers sont toujours nécessaires comme dit dans mon dernier paragraphe. Qui sait, ça changera peut-être un jour avec HTTP2 Push et un serveur web capable de résoudre l'arbre de dépendances. Mais il reste la minification à prendre en compte. Quoi qu'il en soit, ça ne pose aucun problème pour le mode développeur où les ressources sont chargées localement et donc quasi instantanément.

[yahiko]

Alors que je faisais des recherches pour autre chose, je suis tombé sur un article au sujet de la concurrence en JavaScript, et qui documente une discussion un peu plus haut :
ES proposal: Shared memory and atomics

Les SharedArrayBuffers seront donc à priori disponibles avec ES2017, plus tôt que ce que j'avais en tête. Ça va commencer à devenir intéressant...