Merci beaucoup pour cet éclairage. Toujours au top avec le goût du code et le sens du partage. Beaucoup trouvent lassant d'apprendre le TypeScript parce que le JavaScript existe déjà. Le TypeScript apporte un plus au JavaScript, et semble bien être une voie royale pour apprendre React ou Angular.
Le Typescript étant assez proche de l'ActionScript 3, je comprends que tu l'aies vite apprécié. Tout comme le Javascript, le Typescript est utilisable coté client et coté serveur (NodeJS). Son gros plus dans ce cas est de permettre de déclarer des entités et dtos typés, une seule fois pour toute la 'stack'.
Merci beaucoup d'affirmer haut et fort que le JavaScript est complètement extra-terrestre. Je croyais que j'avais des problèmes de compréhension mais en fait non, c'est plutôt le JavaScript qui une GROSSE BOULE DE LAINE TOUTE emmêlé.
2:32 attention, pas toujours vrai, si on pense a au prototype .at de l'obj Array, qui a mis beaucoup de temp a arriver en version ts. Une bonne façon de démarrer une transissions facile en ts est de désactiver le mode strict, et activer dans le tsconfig les options que vous ressente avoir besoin durant votre flow de project.
Junior, et ayant de base énormément plus d'affinités avec des langues typés objet (java et C# en particulier), je préfère 100 fois plus développer en Ts qu'en Js.. J'ai comme l'impression que c'est plus propre, plus naturel pour quelqu'un habitué à l'objet, mais ce n'est que mon point de vue
Je trouve qu’on fait un mauvais procès à JavaScript concernant l’opérateur ==. Le but de == c’est de ne pas s’embêter dans des conversions inutiles (exemple "321" vs 321) et c’est là tout son intérêt car ça évite de faire un parseInt pour "321". Si on veut une comparaison stricte on peut toujours utiliser l’opérateur ===.
Pour quelqu'un qui n'a jamais codé, le TS pourrai le rebuté, mais après quelque projet en JS si il découvre le TS il se demande comment il a pu faire sans sa.
Les comparaisons bancales JS sont vraiment des détails, Si on connaît ses variables, je vois pas le souci. On peut même jouer avec ce non typage pour optimiser le nombre d'instructions et de variables. Il faut juste ne pas penser avec le pattern d'un dev C ou Java. Sinon, la vidéo est bien réalisée, c'est ultra propre.
Ben non c'est juste chiant. Si tu as une grosse application avec des tonnes de variables, si tu veux en utiliser une tu vas pas te faire chier a chercher quel valeur correspond.
Salut merci pour ton contenu. Alors tu préconise TS en premier langage ou bien après être passé par JS ? Pour ma part je pense que la difficulté est de passer d une programmation impérative à fonctionnelle.
même si la question ne m'est pas destiné, moi je te préconise d'apprendre le JS en premier, de bien comprendre le fonctionnement des fonctions avec les arguments avant de passé a TS
Perso j’ai appris le JS via le TS, et j’ai des collègues qui de la même façon a galéré sur le JS avant d’apprendre plus facilement via le TS. Mais on savait déjà programmer en C tous les deux avant donc on avait déjà des bases. Ceci étant, oui, je pense qu’il vaut mieux commencer par le TS, parce que ça induit moins de confusion :)
Perso j’ai appris le JS via le TS, et j’ai des collègues qui de la même façon a galéré sur le JS avant d’apprendre plus facilement via le TS. Mais on savait déjà programmer en C tous les deux avant donc on avait déjà des bases. Ceci étant, oui, je pense qu’il vaut mieux commencer par le TS, parce que ça induit moins de confusion :)
Je rejoins @Frakzor, c'est bien de commencer à comprendre ce qu'il y a dessous (JS) avant de passer à une surcouche (TS). Puis ça permet de passer très facilement de l'un à l'autre.
Je suis tellement pas d'accord. On peut très bien coder proprement avec JS/NodeJS. Se tromper de typage revient à faire une erreur en se mélangeant entre ses variables. Contraindre le type ne va pas éviter cette erreur en cas de type identique. On est sur un détail. Une surcouche pour la lubie. Plus on simplifie le traitement (transpilage, compilation, ...) plus le projet est simple à maintenir. Le plus important est d'avoir des devs organisés et structurés dans leur approches. La simplicité avant tout. Arrêtons les surcouches de surcouche et framework monolithique lourd. (c'est juste mon avis, désolé, youtube m'a proposé ta vidéo XD)
ah marrant ton avis! je trouve ca etonnant que tu dise que cest plus facile de maintenir un projet sans TS tu evoques sur c'est important d'avoir des devs organisés et structurés (evidemment), avec du TS ca facilite justement encore plus cela! dans mon boulot on genere a partir d'un swagger un client http avec les requetes typées (payload d'entrée et de retour), cest bien plus simple de construire ca avec du TS plutot que du JS et de tenter de mettre du JSdoc pour avoir un semblant de typecheck (et a utiliser cest cool) jsuis curieux d'avoir un exemple ou 'tas trouvé que TS etait moins pratique que du JS (autre que POC)!
Très bon rythme agréable à suivre, merci.
Merci beaucoup pour cet éclairage. Toujours au top avec le goût du code et le sens du partage. Beaucoup trouvent lassant d'apprendre le TypeScript parce que le JavaScript existe déjà. Le TypeScript apporte un plus au JavaScript, et semble bien être une voie royale pour apprendre React ou Angular.
Merci pour tes encouragements :)
pour moi tu est le numero 1 francophone dans ta categorie
Merci beaucoup ! :)
Superbe vidéo !!
Merci beaucoup pour ton retour simple et efficace sur le Typescript !!
Avec plaisir :)
Merci pour la vidéo, j'aime bien ton style !
Je suis ravi que ça te plaise :)
c'était super agréable à t'écouter!
Merci beaucoup ! :)
Excellente vidéo. C'est rare de voir des français parler aussi bien de développement informatique
Merci beaucoup, ça me touche :)
Le Typescript étant assez proche de l'ActionScript 3, je comprends que tu l'aies vite apprécié.
Tout comme le Javascript, le Typescript est utilisable coté client et coté serveur (NodeJS). Son gros plus dans ce cas est de permettre de déclarer des entités et dtos typés, une seule fois pour toute la 'stack'.
Merci beaucoup d'affirmer haut et fort que le JavaScript est complètement extra-terrestre. Je croyais que j'avais des problèmes de compréhension mais en fait non, c'est plutôt le JavaScript qui une GROSSE BOULE DE LAINE TOUTE emmêlé.
2:32 attention, pas toujours vrai, si on pense a au prototype .at de l'obj Array, qui a mis beaucoup de temp a arriver en version ts.
Une bonne façon de démarrer une transissions facile en ts est de désactiver le mode strict, et activer dans le tsconfig les options que vous ressente avoir besoin durant votre flow de project.
C cc çčç
Merci pour ton avis.
Mais pour le moment, il est difficile de trouver une formation TypeScript sans un pré requis en JavaScript
Je suis en d'apprentissage et pour le moment cela me ralentie ,mais c'est vrai que l'on écrit du code plus propre. ^^
Junior, et ayant de base énormément plus d'affinités avec des langues typés objet (java et C# en particulier), je préfère 100 fois plus développer en Ts qu'en Js..
J'ai comme l'impression que c'est plus propre, plus naturel pour quelqu'un habitué à l'objet, mais ce n'est que mon point de vue
Je trouve qu’on fait un mauvais procès à JavaScript concernant l’opérateur ==.
Le but de == c’est de ne pas s’embêter dans des conversions inutiles (exemple "321" vs 321) et c’est là tout son intérêt car ça évite de faire un parseInt pour "321".
Si on veut une comparaison stricte on peut toujours utiliser l’opérateur ===.
Pour quelqu'un qui n'a jamais codé, le TS pourrai le rebuté, mais après quelque projet en JS si il découvre le TS il se demande comment il a pu faire sans sa.
Les comparaisons bancales JS sont vraiment des détails, Si on connaît ses variables, je vois pas le souci. On peut même jouer avec ce non typage pour optimiser le nombre d'instructions et de variables. Il faut juste ne pas penser avec le pattern d'un dev C ou Java. Sinon, la vidéo est bien réalisée, c'est ultra propre.
Ben non c'est juste chiant. Si tu as une grosse application avec des tonnes de variables, si tu veux en utiliser une tu vas pas te faire chier a chercher quel valeur correspond.
Salut merci pour ton contenu.
Alors tu préconise TS en premier langage ou bien après être passé par JS ?
Pour ma part je pense que la difficulté est de passer d une programmation impérative à fonctionnelle.
même si la question ne m'est pas destiné, moi je te préconise d'apprendre le JS en premier, de bien comprendre le fonctionnement des fonctions avec les arguments avant de passé a TS
@@59140Dunkerque je le pense aussi et merci de prendre le temps de rebondir sur la question.
Perso j’ai appris le JS via le TS, et j’ai des collègues qui de la même façon a galéré sur le JS avant d’apprendre plus facilement via le TS. Mais on savait déjà programmer en C tous les deux avant donc on avait déjà des bases.
Ceci étant, oui, je pense qu’il vaut mieux commencer par le TS, parce que ça induit moins de confusion :)
Perso j’ai appris le JS via le TS, et j’ai des collègues qui de la même façon a galéré sur le JS avant d’apprendre plus facilement via le TS. Mais on savait déjà programmer en C tous les deux avant donc on avait déjà des bases.
Ceci étant, oui, je pense qu’il vaut mieux commencer par le TS, parce que ça induit moins de confusion :)
Je rejoins @Frakzor, c'est bien de commencer à comprendre ce qu'il y a dessous (JS) avant de passer à une surcouche (TS). Puis ça permet de passer très facilement de l'un à l'autre.
Excellente vidéo on sent un profil expérimenté qui s'exprime
Tout dépend son background. Toi tu viens du C et du C++. Le JS pour un dev tel que toi c'est la fête du slip ! MDR.
Je suis tellement pas d'accord. On peut très bien coder proprement avec JS/NodeJS. Se tromper de typage revient à faire une erreur en se mélangeant entre ses variables. Contraindre le type ne va pas éviter cette erreur en cas de type identique. On est sur un détail. Une surcouche pour la lubie. Plus on simplifie le traitement (transpilage, compilation, ...) plus le projet est simple à maintenir. Le plus important est d'avoir des devs organisés et structurés dans leur approches. La simplicité avant tout. Arrêtons les surcouches de surcouche et framework monolithique lourd. (c'est juste mon avis, désolé, youtube m'a proposé ta vidéo XD)
ah marrant ton avis!
je trouve ca etonnant que tu dise que cest plus facile de maintenir un projet sans TS
tu evoques sur c'est important d'avoir des devs organisés et structurés (evidemment), avec du TS ca facilite justement encore plus cela!
dans mon boulot on genere a partir d'un swagger un client http avec les requetes typées (payload d'entrée et de retour), cest bien plus simple de construire ca avec du TS plutot que du JS et de tenter de mettre du JSdoc pour avoir un semblant de typecheck (et a utiliser cest cool)
jsuis curieux d'avoir un exemple ou 'tas trouvé que TS etait moins pratique que du JS (autre que POC)!
plus simple à maintenir, jusqu'à ce que tu doives refacto et que tu te retrouves obligé de chercher à la main la totalité du code impacté 😂
volume sfx trop fort
Mince, désolé :/