Discussion :

[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]

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.