Le langage open source a été créé par Microsoft comme un surensemble syntaxique de JavaScript, avec un typage fort. La version 5.0, disponible depuis peu, est une mouture majeure, avec de vastes travaux de restructuration.
Le plus gros changement dans le langage est donc une restructuration sur la base des modules ECMAScript, qui est un ensemble de normes. Conséquemment, les paquets TypeScript récupérés par npm install sont plus petits de 46 % en moyenne et les temps de construction doivent être réduits de 10 à 25 %.
TypeScript 5.0 introduit également plusieurs nouveautés importantes, comme les décorateurs d’ECMAScript, des fonctions que l’on peut appeler sur des classes, des éléments de classe ou même d’autres formes de syntaxe JavaScript.
Autre ajout significatif, les paramètres de type const. Ils viennent contrebalancer un problème rencontré par certains développeurs avec le langage, quand ils ont besoin d’un type d’objet plus spécifique. Désormais, on peut ajouter un modificateur const à une déclaration de paramètre pour qu’il soit la valeur par défaut.
Commentaires (25)
#1
Je suis dev Java et je dois de temps en temps faire un peu de Typescript avec Angular.
C’est moi ou ce language (Javascript y compris) est super compliqué ? Entre la lib rxjs asynchrone et toutes les tournures syntaxiques moderne du language, je trouve que la courbe d’apprentissage est assez rude au début.
#1.1
Ton problème est très représentatif de tout ceux qui trouve le JS compliqué. Au lieu de juste faire du JS ont leur apprend à faire de l angular / redux / rx / gsap / … C’est n’importe quoi. Demandez à un apprenti charpentier couvreur de refaire Notre Dame avant de savoir poser des ardoises et vous verrez sa tronche.
#1.2
Je ne suis pas de ton avis. Angular est bien documenté et est plutôt un framework assez simple. Les problèmes que je rencontre sont surtout liés aux typages et à l’asynchrone.
#1.3
C’est bien ce que je dis. Il faut apprendre les bases avant d’utiliser tout plein de lib. L asynchrone ne vient pas avec rxjs‚ c’est un concept et une syntaxe à maitriser avant de faire du rxjs (dont en plus 90% du temps on n’a pas besoin)
#1.4
c’est différent.
Les habitués de Java vont trouver le typeScript compliqué, et les habitués de typeScript vont trouver le java compliqué. Personnellement je trouve que Java ne respecte pas ses promesse, essentiellement sur la portabilité (Mac->PC), en tout cas sur le code implémenté.
#1.5
C’est ce que je me dis aussi. Si un dev TS/JS passe sur une application Java EE dans un server d’applications. Il y a tellement de petits trucs à savoir pour que ca marche et qui ne sont pas forcément évident…
Pour la portabilité, je n’ai testé que Linux <-> Windows et jamais ou rarement eu des problèmes. (juste le CRLF qui fait ch*é
)
#2
JavaScript est un langage bâtard entre pet project (javascript) et nécessité industrielle(emascript) et les bibliothèques sont du même acabit, avec un fort relent de brcolage dans les entrailles.
#3
C’était mon ressenti aussi, grosse claque au début pour un projet serverless partant de rien. Agréablement surpris des différentes possibilités offertes par la techno et le language. Après 6 mois, retour dans du vieux Java, et j’avoue que le retour arrière est un peu rude.
#4
rxjs est une lib très puissante et plutôt bien foutue mais elle devrait juste, selon moi, ne pas être utilisée dans l’immense majorité des projets parce qu’elle a tendance à rendre le code inutilement illisible et compliqué.
Le language Typescript en lui même est vraiment plaisant. Son système de type est poussé très loin et, utilisé avec intelligence, permet de se prémunir de tonnes de bugs. Il permet de créer des types assez complexes qui permettent d’ajouter des contraintes très fortes tout en gardant la souplesse des structures de données du JS.
Le langage n’est pas compliqué dans le sens où c’est un superset de JavaScript : du JS valide est automatiquement du typescript valide. Tout ce qu’il ajoute, à l’initiative du développeur, c’est de permettre de modéliser finement tes contraintes métier afin de ne pas pouvoir compiler du code qui n’a pas de sens.
C’est un langage simple et complet qui peut s’apprendre avec le temps, surtout si on connaît JS, mais qui peut vite devenir un enfer si ses fonctionnalités sont mal exploitées, ce qui statistiquement va souvent arriver dans une équipe.
#5
Un petit lien vers une liste des nouveautés : https://devblogs.microsoft.com/typescript/announcing-typescript-5-0/
(pour ceux que ça intéresse)
Je plussoie : surtout quand tu pars de Java, langage fortement typé à JS - langage (trop) faiblement typé, TypeScript est un subtil mélange.
#6
C’est clair que TypeScript sent bon le langage réfléchit à l’avance.
Et que le monde du dev JS nécessite trop souvent d’apprendre plusieurs syntaxes (JS, TypeScript, les librairies) - et non pas juste l’utilisation de librairies depuis un langage.
JS seul, c’est la même expérience que VB6: des promesses, mais au final un travail de titan pour faire des choses qui sont nécessaires (genre gérer correctement les dates, les nombres, formatter le texte…)
Et une gestion des erreurs à imaginer en amont sous peine de faire comme 90% des sites: ne pas gérer les erreurs et laisser les gens râler.
Bref, vive TypeScript.
#7
Pour moi rxjs c’est une librairie de plomberie.
Ce n’est pas fait pour être utilisé tel quel. Hmm… non. C’est p-e un peu abusif.
Je devrais plutôt dire: “c’est une lib qui ne te guide pas implicitement vers une utilisation correcte”.
Donc oui il y a une courbe d’apprentissage, mais pas de la lib en elle-même.
Il y a surtout une courbe d’apprentissage de création d’architecture async.
#8
J’avais effectivement oublié le lien de l’annonce, c’est ajouté, merci
#9
Le JS a quand même bien évolué depuis plusieurs années.
Les Promise, fetch, try/catch, fonctions fléchées, constructeurs d’objets. Tout ça, c’est natif.
TypeScript apporte quand même pas mal de choses et a ouvert la porte a une modernisation du JS lui-même qui finira petit à petit par adopter toutes ces avancées.
#10
Je pense qu’on verra WebAssembly plus fréquemment avant qu’on se fane l’adoption de ces fonctionnalités en profondeur.
Au-delà de JS, c’est tout l’environnement du DOM/HTML qui est mal foutu, suranné, bricolé… et nécessite des tonnes de bidouillage pour avoir un résultat.
#11
C’est le mauvais débat.
HTML n’est pas du tout suranné. C’est un format tres robuste pour faire des documents de toutes sortes, qui soient accessibles, avec une sémantique correcte, et qu’on peut en plus rendre jolis.
Le problème c’est que les GAFAM ont mis tous leur poids pour faire transitionner l’industrie du paradigme « un ordinateur exécute un programme » vers le paradigme « le programme s’exécute à distance et l’ordinateur ne s’occupe que de l’UI ».
Et bien sûr comme c’était à leur avantage, puisque c’est là qu’ils font leur blé, ça s’est fait par le web.
Donc on se retrouve à faire des applications avec un langage conçu pour faire des documents.
C’est pas pour rien que les deux plus gros frameworks front viennent de Google et Facebook. Une appli qui tourne sur le web, c’est une appli qui tourne dans Chrome et c’est une appli sur laquelle tu pourras mettre des scripts de Google et/ou de Facebook.
Ça a aussi tué absolument toute possibilité de concurrence dans le domaine des navigateurs web : bon courage pour créer un moteur de rendu en 2023. Il est maintenant quasi impossible d’utiliser internet sans WebKit/Blink ou Gecko.
Je vois très bien les avantages de la plateforme web en terme de déploiements. Mais le même résultat aurait pu être obtenu en créant une sorte de « browser sandboxé dédié aux applis » avec de quoi faire de vraies UI sans bricolage.
Donc je suis pas d’accord pour dire que HTML est suranné. Laissons le à ce qu’il sait bien faire et passons vite à autre chose.
#12
É que s’apelerio runtime Flash/XUL/Java.
C’est justement le fait d’avoir eu pendant des années une guerre des “sortes de browser sandboxé dédié aux applis” (= des runtime) qui a conduit à l’émergence d’un runtime universel : le navigateur web.
L’alternative qui pourrait pointer son nez c’est que tout le monde passe sur le runtime des smartphone… c’est à dire sur celui d’Android (ART) puisqu’il est open-source. D’autant qu’on a maintenant un “sous-système Android” dans Windows…
#13
Exact. Les principaux reproches que je fais à HTML concernent effectivement la partie “interactive” (les formulaires et leurs champs sont totalement inadaptés actuellement et même pour la fin 90 c’était pas top, et les solutions basées sur “contenteditable” reviennent à réinventer la roue).
Il y a toutefois le problème habituel d’avoir du mal à pouvoir se dimensionner par rapport à l’écran car on ne sait pas quelle taille il a en hauteur -> c’est bien pour du document, pas top pour de l’affichage.
CSS par dessus était une bonne idée à l’époque, mais il a largement dévié et est devenu très lourd (nécessitant d’activer le GPU pour tout rendu de page).
Pour le paradigme, oui on est revenu à un système comme les mainframes (centralisé) mais certaines applis PWA se rapprochent d’un mode hybride “client/serveur | mainframe”
Ce qui est affligeant, c’est la performance nécessaire pour afficher des pages web. Un formulaire PDF interprété par Javascript est plus léger en CPU et RAM que des pages web avec 4 champs!
Ou sur web assembly… Qui reste plutôt lourd à lancer mais a des démos sympa. Et les éditeurs en sont friands: le JS c’est bien mais même obfusqué, ça reste lisible/patchable.
#13.1
récemment, j’ai du suivre un projet d’amélioration d’un formulaire web assez basique et je me suis rendu compte que la norme a beaucoup trop peu évolué, il faudrait beaucoup plus de trucs en natifs pour éviter de devoir passer par du JS
notamment :
je suis sur qu’il y a encore d’autres choses, je trouverais ça bien qu’on puisse se passer un peu plus du JS avec plus de choses natives dans le format
#14
Javascript c’est
Typescript ne fait que masquer le non typage par défaut. Il faut vraiment le vouloir pour faire du typage fort quand on voit la tronche de certaines fonctions, ici une simple recherche avec Elasticsearch
#14.1
Hmm on peut avoir à peu près la même chose en java, n’est -ce pas? 🙃 J’ai déjà vu ce genre de chose plus d’une fois
Les génériques c’est sympa, mais on n’est pas forcé d’en abuser 😉
#15
Les devs java ont aussi RxJava, c’est comme RxJs, c’est juste une lib, libre à chacun de l’utiliser ou pas. Ce n’est pas du tout inhérent à Typescript.
Sinon, les décorateurs…
J’aurais préféré ne pas voir ça dans es/typescript. J’espère que ça ne deviendra pas mainstream et que ça reste cantonné à une “typologie” de projet, type angular. TS a apporté une forme de maturité à l’écosystème javascript sans imposer nécessairement l’approche que je trouve lourde/lourdingue d’un angular, et qui me rappelle en fait Java EE par certains côtés.
#15.1
Ne pas se tromper, il faut savoir utiliser un pattern lorsque c’est adapté. Trop souvent certains devs apprennent un pattern te se mettent à le coller de partout.
On utilise les “anciens decorators” (<TS 5.0), va falloir que l’on regarde ce que ca donne de migrer en 5.0
C’est bien adapté quand tu veux te faire des compositions complexes (ici, composition spécifique à chaque website à parser)
En tout cas je te rejoins sur le fait que nombreux sont ceux qui jugent un langage seulement par la lib qu’ils ont eu à utiliser. Moi en tout cas j’aime bien le TS. Je recommande fortement de jouer avec Svelte en mode TS c’est bien plaisant :)
#15.2
C’est une question de préférence avant tout. Ce que tu fais avec des annotations peut très bien être fait sans. Perso je préfère l’explicite à l’implicite ; savoir exactement quand et comment une fonction dépend d’une autre d’un simple coup d’oeil. Les annotations produisent du code avec beaucoup de choses un peu cachées sous le capot, perso je n’aime pas je préfère la mécanique visible, mais encore une fois c’est question de goût
#16
Les listes de choix arborescentes sont un problème aussi. Pour les emails, les tel, les dates le HTML5 a des outils basiques, mais l’implémentation selon le navigateur varie (notamment la gestion des dates). Et comme tu parles “citoyen”, il faut aussi ajouter l’accessibilité, obligatoire selon les termes du RGAA, et là ça devient drôle… Rien par défaut, des tonnes de choses à ajouter, une syntaxe “parallèle” de description…
Enfin, la gestion des erreurs. Nos pages doivent toutes activer du JS au démarrage ou pour le behavior. Beaucoup de pages n’indiquent pas quand une erreur survient, ou quand tout n’est pas chargé (exemple: Sharepoint Online ne signale pas que le chargement est toujours en cours, les pages admin de Office … c’est pire, certains outils de l’éducation nationale ont considéré que comme ils ne recevaient pas les exercices suivants (pour cause de timeout, car 20mb/s sur un collège pour 100 connexions simultanées c’est trop peu et pas testé par les développeurs) l’examen était fini…)
HTML/Javascript demande un travail phénoménal de développement pour approcher la qualité presque intrinsèque des dev en client lourd ou en formulaire telnet. Typescript améliore la situation pour avoir de plus gros softs gérables, mais le frontend reste technique…