Discussion :

[RPGamer]

Commence par lire la documentation de TypeScript, ce que je t'explique y est �crit en gros d�s la home du site de TypeScript.

Comme le dit tr�s justement defZero, TS est bien un superset de JS, �a signifie que �a n'est justement pas du JS, mais que tout code JS est en principe du code TS valide, c'est tout.

Angular n'a rien avoir avec angular.js => oui en effet, mais c'est juste parce que angular est diff�rent, rien � voir avec le changement de langage. Angular aurait pu tout aussi bien �tre �crit en JavaScript.

La mani�re dont la team Angular utilise TS, et qui est fortement discutable, est propre � cette team. Ce n'est pas n�cessairement de cette mani�re qu'il faut utiliser TS.

Les d�corateurs ont �t� ajout� par le team TS � la demande de la team Angular pr�cis�ment, marquant la fin pr�matur�e du projet AtScript et ce qui rend sont approche compl�tement diff�rente de JS d'ailleurs.

Il ne restera plus rien comme petit avantage concurrentiel � Angular, d'o� l'�norme gamelle qu'il se ramasse.

Angular propose d�j� tous les outils et l'architecture �l�gante d'une app out of the box en TS justement, c'est en �a qu'il est le seul r�el framework, qui se suffit � lui-m�me. React n'est qu'une biblioth�que. Ils ne jouent donc pas du tout dans la m�me cat�gorie, et c'est la confusion que tu fais et qui est faite dans cet article.

[Marco46]

D'apr�s le site "TypeScript is a typed superset of JavaScript that compiles to plain JavaScript." donc non, du TypeScript n'est pas du JS puisqu'un sur-ensemble devant �tre compil� / transpil�.

[...]

Enfin, j'ai lu la doc et ne trouve aucune mention du fait que TypeScript ne serait pas un langage � part.

T'es quand m�me capable d'�crire que TS = types + JS et quelques lignes plus loin que c'est un langage part. C'est tellement un langage � part que la team g�rant TSLint a d�cid� de fusionner avec ESLint en y ajoutant simplement un plugin. A ce stade de mauvaise foi je ne peux plus rien pour toi.

mais je n'est vue nul part o� il est dit qu'un fichier ".ts" normale �tait compatible ".js" sans passer par la case compilation.

C'est pourtant comme �a que �a fonctionne. Si tu �cris du TS sans notion de type tu n'as rien d'autre que du JS. Inutile de transpiler quoi que ce soit. Ce que fait tsc c'est d'analyser les types, de lever les erreurs, puis de transpiler en JS dans la version voulue de JS en enlevant la totalit� des informations de type.

Donc concr�tement si tu �cris ton code en ayant comme target la version courante de JS tu verras que rien ne change entre le code TS et le code JS, tu auras juste les informations de typage en moins. C'est tout.

D'ailleurs �tant donner que le compilo TS peut g�n�rer des modules JS selon les diff�rentes norme (AMD, CommonJS, ...etc) je ne voit juste pas comment ce serait possible qu'un runtime JS comprenne le syst�me de module natif de TS qui lui est de bien plus haut niveau.

De quel myst�rieux "syst�me de module natif de TS de bien plus haut niveau" parles-tu ?

[Marco46]

Comme le dit tr�s justement defZero, TS est bien un superset de JS, �a signifie que �a n'est justement pas du JS, mais que tout code JS est en principe du code TS valide, c'est tout.

C'est pas "en principe", c'est une r�gle. Et la seule chose qui diff�re entre JS et TS c'est le syst�me de typage.

Les d�corateurs ont �t� ajout� par le team TS � la demande de la team Angular pr�cis�ment, ce qui rend sont approche compl�tement diff�rente de JS d'ailleurs.

Les decorators sont en stage2 au TC39. �a finira par devenir du JS vanilla. �a arrive r�guli�rement qu'une feature qui n'est pas encore termin�e pour JS soit int�gr�e en avance de phase. Dernier exemple en date l'optionnal chaining.

tsc fait aussi le boulot de Babel, c'est peut �tre �a qui cr�e la confusion dans votre esprit. Tu peux retrouver les d�corateurs dans un code JS avec Babel et le plugin qui va bien. Mais tu vas peut �tre tenter de m'expliquer que du JS g�n�r� par Babel "n'a rien � voir" avec JS ?

Angular propose d�j� tous les outils et l'architecture �l�gante d'une app out of the box en TS justement, c'est en �a qu'il est le seul r�el framework, qui se suffit � lui-m�me. React n'est qu'une biblioth�que. Ils ne jouent donc pas du tout dans la m�me cat�gorie, et c'est la confusion que tu fais et qui est faite dans cet article.

Oui l'�cosyst�me React est un peu bord�lique et il faut assembler brique par brique pour avoir l'ensemble de l'�quivalent des features propos�es out of the box par Angular, mais on parle de seulement 3 ou 4 briques. Pour avoir l'�quivalent d'un Angular t'as besoin du core, d'un routeur, d'un state manager et basta dans 95% des cas. Et apparemment c'est cette approche qui est privil�gi�e par la communaut� JS puisque c'est Angular qui se casse la gueule, React qui a gagn� et Vue qui creuse gentiment son trou.

Apr�s le d�bat framework vs lib, j'ai eu ce genre de questionnements il y a quelques ann�es, j'en arrive � la conclusion que c'est une question sans importance parce que la communaut� a tranch�. Vue a pris la m�me approche que React, tu tires les d�pendances dont tu as besoin plut�t que de te retrouver avec une usine gaz qui contient plein de choses inutiles pour toi.

[RPGamer]

Et la seule chose qui diff�re entre JS et TS c'est le syst�me de typage.

La diff�rence est colossale.

Apr�s le d�bat framework vs lib, j'ai eu ce genre de questionnements il y a quelques ann�es, j'en arrive � la conclusion que c'est une question sans importance

Il n'y a pas de d�bat, ce sont bien deux concepts d�finis et diff�rents et la question est fondamentale et globale (bien au-del� de TS ou JS). L'approche framework permet justement de tenir des projets importants de fa�on coh�rente, auto-document�e, etc. et m�me si l'approche bord�lique de React ou NPM s'est beaucoup d�velopp�e r�cemment (� cause du sentiment de libert� produit par ce bordel justement), il ne s'agit que d'un effet de mode. On ne peut rien construire de p�renne et fiable sur du bordel et de la confusion. Ca rejoint l'un des premiers commentaires qui questionne o� en serons-nous dans 5 ans.

Et apparemment c'est cette approche qui est privil�gi�e par la communaut� JS puisque c'est Angular qui se casse la gueule, React qui a gagn� et Vue qui creuse gentiment son trou.

Tu continues � confondre TS et JS, framework et biblioth�que, AngularJS et Angular. Ces concepts sont totalement distincts. Ses outils ne sont pas comparables. React ne gagne rien et Angular ne se casse rien. Angular reste le framework le plus plebiscit� par la communaut� (notons quand m�me la confusion AngularJS/Angular de l'article), tout domaine de d�veloppement confondu et n'a aucun rapport avec l'abandon d'AngularJS faisant chuter son usage.

tsc fait aussi le boulot de Babel, c'est peut �tre �a qui cr�e la confusion dans votre esprit. Tu peux retrouver les d�corateurs dans un code JS avec Babel et le plugin qui va bien. Mais tu vas peut �tre tenter de m'expliquer que du JS g�n�r� par Babel "n'a rien � voir" avec JS ?

Pourquoi des outils et des plugins additionnels tiers alors qu'on peut l'avoir de facto? Encore du bordel en plus.

[Marco46]

La diff�rence est colossale.

Elle est importante mais faut pas charrier non plus, �a n'est jamais qu'une grosse fonctionnalit� en plus. En l'�tat c'est juste Babel + Flow, en beaucoup mieux r�alis�. Mais bon, avec plusieurs types pay�s full time par Microsoft depuis presque 8 ans c'est pas �tonnant. Et faut voir le pedigree de certains membres de la team. Ya quand m�me le principal concepteur de C# rien que �a.

L'approche framework permet justement de tenir des projets importants de fa�on coh�rente, auto-document�e, etc.

Absolument aucun rapport avec le fait d'utiliser un framework au lieu de 3 ou 4 d�pendances. Et encore tu parles d'un framework pour Angular mais techniquement tu te retrouves avec autant de bordel dans ton package.json. La diff�rence c'est surtout que Angular fait plein de choix pour toi.

et m�me si l'approche bord�lique de React ou NPM s'est beaucoup d�velopp�e r�cemment (� cause du sentiment de libert� produit par ce bordel justement), il ne s'agit que d'un effet de mode.

Mais oui �videmment, 6 fois + de DL, 3 fois + de stars sur les d�p�ts GitHub et en tendance constante depuis 2 ans au moins (npm trends ne va pas plus loin) mais c'est une mode

On ne peut rien construire de p�renne et fiable sur du bordel et de la confusion. Ca rejoint l'un des premiers commentaires qui questionne o� en serons-nous dans 5 ans.

Question confusion et bordel Angular est champion du monde.

Tu continues � confondre TS et JS, framework et biblioth�que, AngularJS et Angular. Ces concepts sont totalement distincts.

Pourquoi tu me parles de AngularJS ? Quand je dis que Angular se casse la gueule, je parle bien de Angular et pas de AngularJS. AngularJS est une techno morte elle est en LTS.

Quand t'as presque 70% des sond�s qui te disent qu'ils ne veulent pas entendre parler de cet outil apr�s l'avoir utilis� ou non c'est bien qu'il y a un �norme probl�me avec.

Ses outils ne sont pas comparables. React ne gagne rien et Angular ne se casse rien. Angular reste le framework le plus plebiscit� par la communaut� (notons quand m�me la confusion AngularJS/Angular de l'article), tout domaine de d�veloppement confondu et n'a aucun rapport avec l'abandon d'AngularJS faisant chuter son usage.

Ah mais �a ne fait que confirmer ce que je disais dans un post pr�c�dent. �a c'est le point de vue franco-fran�ais. Avec ses quelques ann�es de bourre comme sur toutes les tendances. D'ailleurs c'est entrain de se retourner depuis un an environ. Je t'invite � check les offres d'emploi dans les startups fran�aises, c'est massivement du React et un peu de Vue. Il y a tr�s peu d'Angular. C'est un signal faible tr�s important pour la suite.

Pour ce qui est de la confusion AngularJS/Angular, j'ai envie de te dire la faute � qui ? C'est une des nombreuses erreurs commises sur cet outil. Un nommage pourri pour d�marrer �a ne pouvait que mal se passer.

Sinon la question avait d�j� �t� lev�e lors du SoJS de l'an dernier et la r�ponse des auteurs est claire, il s'agit de Angular, pas de AngularJS. Apr�s si les personnes qui r�pondent se plantent qu'ils se plaignent � Google.

Pourquoi des outils et des plugins additionnels tiers alors qu'on peut l'avoir de facto? Encore du bordel en plus.

Tu me dis que l'ajout des d�corateurs dans TS pour Angular fait que c'est "compl�tement diff�rent" pour �tayer le fait que TS et JS seraient "compl�tement diff�rents". Je te r�ponds que cette feature existe aussi pour JS en stage 2. Quel rapport avec le fait que tsc est plus simple � utiliser que Babel ?

[RPGamer]

Elle est importante mais faut pas charrier non plus, �a n'est jamais qu'une grosse fonctionnalit� en plus. En l'�tat c'est juste Babel + Flow, en beaucoup mieux r�alis�. Mais bon, avec plusieurs types pay�s full time par Microsoft depuis presque 8 ans c'est pas �tonnant. Et faut voir le pedigree de certains membres de la team. Ya quand m�me le principal concepteur de C# rien que �a.

OK le typage statique est "juste" une grosse fonctionnalit� d'un langage

Et encore tu parles d'un framework pour Angular mais techniquement tu te retrouves avec autant de bordel dans ton package.json.

Non, c'est rang�.

Mais oui �videmment, 6 fois + de DL, 3 fois + de stars sur les d�p�ts GitHub et en tendance constante depuis 2 ans au moins (npm trends ne va pas plus loin) mais c'est une mode

Oui, d'ailleurs des outsiders pointent le bout de leur nez en permanence. Vue.js n'est pas tr�s vieux. Tous vont mourrir, mais c'est un probl�me li� � la techno et non � l'outil.

Question confusion et bordel Angular est champion du monde.

Non, il suffit de lire la doc. C'est un des principes du framework.

Pourquoi tu me parles de AngularJS ?

Car si on me lis, ce qui n'est pas ton cas visiblement, la confusion des genres et des technos faites (volontairement ou pas) dans les articles, c'est le sujet inital de mes commentaires

Quel rapport avec le fait que tsc est plus simple � utiliser que Babel ?

A quel moment je dis que c'est plus simple ou plus compliqu�? Il est juste inutile avec TS. Mais aussi avec Scala.js, etc...

[Sodium]

Je ne comprendrai jamais cet engouement pour React, sa syntaxe est totalement immonde.

Oui, JavaScript est complexe, car on lui greffe tellement de trucs et de machins pour lui faire faire des choses pour lesquelles il n'a pas �t� pens� � la base qu'il faut une veille technologique permanente juste pour se tenir au courant des nouvelles librairies.

Le d�bat prototype/classes il faut arr�ter. Le prototypage est illisible, les devs de JavaScript l'ont compris en incluant les classes et les devs utilisant JavaScript l'ont compris puisqu'ils sont pass�s sur TypeScript.

On peut tirer d'ailleurs le chapeau � JavaScript, il parvient � �tre tellement mal foutu que personne n'a envie de travailler avec sans passer par un langage interm�diaire, mise � part les masochistes et les gens trop incomp�tents pour se rendre compte qu'ils tiennent au prototypage pour une question d'ego (Moa j'ai pass� des ann�es � ma�triser la syntaxe pourrave de JavaScript donc je vous suis s�perieur) que de pragmatisme.

[frfancha]

Je ne comprendrai jamais cet engouement pour React, sa syntaxe est totalement immonde.

Excellent, si Sodium n'aime pas c'est bon signe, content d'avoir choisi React.

[Sodium]

M�me les utilisateurs React admette pour la plupart que sa syntaxe de templating est immonde.
Apr�s pour les puristes de JavaScript je comprends qu'une syntaxe immonde les ravissent...

[RPGamer]

Il est vrai que la syntaxe de template React est assez laide mais je ne pense pas qu'il existe de vraies puristes JavaScript. Le JS n'est qu'une contrainte li�e au legacy d'un langage � script c�t� client, pas un choix. Le langage est bourr� de bugs et de d�fauts que cherchent � combler de plus en plus de technos, avec le d�veloppement du Web et des natives apps sur mobile. Ainsi JS n'est plus qu'un moyen standard d'ex�cution du code. Probablement que JS disparaitra totalement au profit de solutions plus performantes comme un bytecode WebAssembly. Une standardisation du W3C de ce que voulait proposer Sun avec les applets Java au fond. La boucle est boucl�e.

[redbullch]

Probablement que JS disparaitra totalement au profit de solutions plus performantes comme un bytecode WebAssembly.

Malheureusement, on ne peut toujours pas manipuler le DOM en WebAssembly. On voit �merger deux solutions pour l'instant pour un front-end wasm:

1. Cr�er un pont avec du code JS
2. Dessiner la GUI dans un canvas

J�esp�re qu'ils ajoutent la manipulation du DOM rapidement car la solution 2 n'est pas optimal, ni pour les d�veloppeurs, ni pour les utilisateurs (sauf pour des niches comme le jeux-vid�o).

[RPGamer]

JS ne disparaitra pas du jour au lendemain et WebAssembly n'est peut-�tre pas le candidat pour le remplacer. En revanche il est clair que les nombreux d�fauts de JS pourrait �tre supprim�s, les performances augment�es et la standardisation assur�e par cette approche, avec un bytecode qui puisse �tre produit par des langages qui transcompile d�j� en JS (TypeScript, Scala, Kotlin, etc.) et ex�cut� au sein de navigateurs Web.

[Invit�]

Probablement que JS disparaitra totalement au profit de solutions plus performantes comme un bytecode WebAssembly.

J'en doute. WebAssembly n'a pas les m�mes objectifs ni la m�me mise en oeuvre. Il n'est pas fait pour manipuler le DOM mais au contraire il s'y int�gre via du... JS. Et surtout, actuellement, WebAssembly se code en C, C++ ou Rust, donc je vois mal tous les dev frontend passer � ce genre de langage. Au contraire, la tendance est plut�t de faire du JS sur le backend.

[nouknouk]

mise � part les masochistes et les gens trop incomp�tents pour se rendre compte qu'ils tiennent au prototypage pour une question d'ego

Dis autrement, soi on pense comme toi, soit on est forc�ment un incomp�tent bourr� d'�go.

Moi j'adore le prototypage. Et tout le monde aussi

Sauf bien s�r les incomp�tents incapables de penser en dehors de leurs maigres acquis, et donc incapables de remettre leurs 'certitudes' en question de temps en temps, pour sortir de leurs formatage � la POO orient�e classes.

[RPGamer]

J'en doute. WebAssembly n'a pas les m�mes objectifs ni la m�me mise en oeuvre. Il n'est pas fait pour manipuler le DOM mais au contraire il s'y int�gre via du... JS. Et surtout, actuellement, WebAssembly se code en C, C++ ou Rust, donc je vois mal tous les dev frontend passer � ce genre de langage. Au contraire, la tendance est plut�t de faire du JS sur le backend.

JavaScript n'a pas pour objectifs d'�tre ex�cut� sur un serveur, pourtant certains essaient de le faire. Il y aura �galement du front sans JS car il y a toutes les bonnes raisons pour �a.

[Invit�]

JavaScript n'a pas pour objectifs d'�tre ex�cut� sur un serveur, pourtant certains essaient de le faire.

En 1995, Java n'avait pas pour objectifs de faire des applis android, et pourtant... En quoi JS est moins adapt� au backend, que python, ruby ou m�me java ? J'ai plut�t l'impression que certains y arrivent assez bien : https://www.simplytechnologies.net/b...rely-on-nodejs

Il y aura �galement du front sans JS car il y a toutes les bonnes raisons pour �a.

Lesquelles par exemple ? Vu le temps qu'il a fallu pour se d�barrasser de flash, je doute que JS disparaisse des navigateurs de sit�t.

[Sodium]

[...]En revanche il est clair que les nombreux d�fauts de JS pourrait �tre supprim�s [...]

Sauf que ce que tu appelles "d�fauts" les fanatiques de JavaScript appellent �a des features.

[RPGamer]

En 1995, Java n'avait pas pour objectifs de faire des applis android, et pourtant...

Et pour cause : Android n'existait pas. Mais sa JVM est parfaitement adapt� � ce type d'usage, il a d'ailleurs �t� largement adopt� sur mobile bien avant l'invention du smartphone car les architectures et les syst�mes �taient plus divers.

J'ai plut�t l'impression que certains y arrivent assez bien

Les traditionnelles liste de r�f�rences sans pr�cisions des usages sont valables pour tous types de techno. Les listes serait bien plus longues sur des technos plus matures �videmment, sans plus de signification pour autant...

Lesquelles par exemple ?

Syntaxe, performances, quelques d�fauts, features mal ou pas impl�ment�es, monopole historique, etc. Le d�veloppement de TypeScript et d'autres alternatives le met en lumi�re.

[Sodium]

Things like the module pattern and other attempts to create private scopes with localized state and reasoning that use closures and functions wrapped in functions, wrapped in functions, are just crazy. It becomes a mess of implicit reasoning, i.e., "if you wrap a bunch of functions this way it's implied that the scope is as such and these variables belong to this part of the code, and you shouldn't touch these variables and you shouldn't call this method like this because it will break." You must read the code very carefully and follow all of the functions and closures to know the programmer's implied meaning.

Compare this to something like Java where you have explicit language elements like classes to denote local scope, methods with method scope, blocks with block scope, and access modifiers for controlling privacy. The language makes it very clear what the programmer's intent is, and it's immediately recognizable.

People argue that complaining JS doesn't have classes is a bias from using class-based, compiled OO languages, but it's not about classes. It's about clear, explicit language elements, allowing programmers to read code and quickly understand it.

On ne peut pas mieux dire

[dfiad77pro]

а по французски что это дает? Конечно, ИТ-специалисты говорят по-английски, но стараются переводить �

Je fait comme Sodium, je vous laisse traduire (russe)