Pour moi, les 4 éléments les plus importants utiliser au quotidien serait plus : - les types (primitif, class) "j'utilise très peux les array[] ou object{}" - les Map/Sets - les promise - les proxies Et sur le plan théorique, comprendre les optimisations polymorphiques du moteur V8 des functions, ainsi que les notions de scope et de closures et tous le concept décorateur.
Map et Set sont des objets très peu utiles à pars dans certains cas. Si c'est votre utilisation de Javascript aux quotidiens, je suis intrigué pars le travaille que vous faite 🙂.
Superbe vidéo!! Je te suis depuis quelques temps et j’apprécie les différents sujets que tu traites comme le clean code, design pattern, les best practices… Cela m’a servi durant mon apprentissage qui arrivent à sa fin et je pourrai les revoir (notamment les vidéo TypeScript) lors de mon premier poste en CDI 😊 Stéphane
Salut Stéphane, merci d’avoir pris le temps d’écrire un commentaire, ça fait toujours plaisir de lire des messages comme le tiens. Bon code pour la suite !
Salut encore une vidéo conseil de très bonne qualité je t en remercie beaucoup et merci pour ta vidéo formation JavaScript ça m’a beaucoup aider pour les fondamentaux cdt
Merci pour ton retour. Je suis content que le workshop sur JavaScript t’ai permis d’aller plus loin pour approfondir les fondamentaux. 👍 Bon code pour la suite et à bientôt !
Salut Simon ! Je vais et j'espère de même chez vous ! Vraiment désolé, je ne vous ai pas remercié pour les newsletters et l'invitation par rapport aux mises à jour dans Angular Senior Workshop. Je gérais des embrouilles par ci par là, mais maintenant ça va 🤣. Merci pour le travail !
Super vidéo! Le seul truc qui me chiffonne c est que j ai qd meme l impression que les observable sont plus une implementation d un concept via des libraries comme rxjs et ne font pas partie de javascript en tant que tel.
Bonjour, Vidéos de qualité qui explique de bon concept :) Je suis votre formation sur Angular 15, et vous aviez parlé de faire une formation sur la version 18. Je suis impatient de pouvoir la suivre, et me demandais si elle sera prévue dans les semaines à venir? Sébastien
Salut, merci pour ton retour sur la vidéo. 👍 La formation pour Angular 18 est déjà disponible gratuitement sur angularsenior.fr. Il suffit de vous inscrire à la Newsletter. Le format vidéo disponible sur RUclips, ce ne sera pas avant 6 mois je pense. Le tournage et montage prennent toujours beaucoup de temps. Le workshop est au format texte actuellement.
@@codeursenior ooohhhhh mais c'est super ça!! je fonce voir ce qu'il en est, et à bientôt si j'ai des questions :D, merci pour toutes ces connaissances
Ah oui ce serait top d’avoir accès à cette primitive réactive gratuitement avec le langage. Cependant, le processus d’acceptation par le TC39 prends généralement des années. Un peu de patience encore 👍
1 + "1" = "11" et non 11 ... JS va appliquer un toString sur le number afin d'avoir les mêmes types et ensuite il va concaténer le tout, d'où "11" et non 11. ;)
Le jour où les différents languages utiliseront le même dictionnaire de mots pour les mêmes conceptes/fonctions, on ferra un grand pas. Tous ce qui est présenté ici n'est qu'un renommage de predicate, iterator, lambda, callback (func ptr), etc. (je ne critique pas la vidéo, elle est très bien. Et merci 😊) Inventer une terminologie pour ne pas dire qu'on réinvente la roue, c'est à mon sens le 1er problèmes des "languages". Ce qu'apport réelement un language, c'est le sucre syntaxique qui va faire appel à des conceptes avancé. Qu'ils soient codé dans le moteur (vm) ou le compilateur. Si j'invente un language avec un sucre syntaxique appelé "rpc(xxx)", je n'invente rien. Je rend juste plus simple l'utilisation de rpc/marshaling (proxy). si maintenant je l'appel "PubSub"... bah j'ai juste changé le nom, pas le concepte. Ca reste mon appréciation 😊
Hello, je vous rejoint sur un point : il y a un problème de nommage dans cette industrie. Il faut parfois 15min pour comprendre que 2 hommages différents désignent le même concept !
Pour la première partie, est-ce que le problème n'est pas pris à l'envers ? Est-ce que le bon choix ne serait pas plutôt d'expliquer que "le typage dynamique" peut créer tous ces comportements peu intuitifs et qui risquent de créer des bugs, donc en javascript il vaut mieux utiliser tel outil de vérification de typage statique dans des projets professionnels (sans pour autant passer au typescript). Cela me semble être beaucoup plus intéressant de montrer que cette absent de contrat sur les types va créer énormément de problème dans la gestion des opérations (mais pas que, puisque qu'une variable peut passer du int au string ou au bool alors que l'on s'attend par exemple à avoir un float). Ne pas exprimer ces contrats et le marteler me donne l'impression que ça va amener des débutants à avoir une mauvaise approche logiciel, à base de tests et d'l'intuition sur les résultats d'expressions en javascript. Le problème n'est pas que le débutant va m'expliquer qu'il sait ce que va créer l'opération, le problème c'est que son code soit à ce point peu safe qu'il permette ce type de bizarreries, je me dirais au contraire qu'il ne maitrise rien du tout 😅 Je vois en cherchant rapidement sur internet qu'il existe un outil comme flow et j'imagine que des IDE doivent proposer certaines solutions équivalentes pour de la vérification de typage statique. À moins que je sois complètement dans le faux et que ce genre d'outils n'a pas pris dans le monde professionnel en javascript ? (et si ce n'est pas le cas, pour quelles raisons ? 🥲)
J'interviens car je suis assez surpris de l'argument énoncé vers la 3ème minute qui laisse entendre que ce que reprochent les gens au JS c'est : "Non, les types sont importants en JS car si vous additionnez un nombre et une chaine il faut savoir que l'opérateur va fonctionner bizarrement car dans ce contexte l'opérateur d'additions sera une concaténation". Or, ce n'est évidemment pas ce qui est reproché à JS au travers de son manque de typage, c'est que justement le langage nous laisse faire une additions pareille (et les exemples de ce genre sont légions). De nombreux développeurs préfèrent être arrêtés avant même l'exécution quand il font une telle chose plutôt que d'avoir des comportements "étranges" (même si ils paraissent logique une fois qu'on a mis le nez dedans). Oui, une fois qu'on comprend comment fonctionne JS on apprend soit à ne plus utiliser ces comportements étranges et à les éviter. Soit on s'en sert à bon escient. Mais qu'on les connaisse ou pas en profondeurs ces comportements "étranges" il reste qu'on peut légitimement les considérer comme problématiques et dangereux pour la qualité du code produit. D'ailleurs le problème se voit bien avec ce qui vient juste après, à savoir "Bombardez typeof et regardez comment JS fonctionne avec tel ou tel type". Oui mais si on est obligé de faire ça c'est bien qu'à la base il y a un manque de clareté. Le langage est très peu intuitif et même un expert finira par se faire avoir et ferra une erreur. Plus le langage est léger avec nous en terme de verifs plus on a de risque de se planter. Pareil avec le "Il existe aussi le type fonction mais on le manipule pas avec des opérateurs + ou des - car ça donne des choses très étranges". Oui, je suis d'accord, sauf qu'on manipule et stocke relativement souvent des callback qu'on met dans des variables. Si l'utilisation de la variable est loin de son affectation le développeur peut vite oublier qu'il n'a pas un nombre mais un type (même en nommant bien la variable), et puis de toute façon, qu'il oublie ou pas le langage nous laisse faire cette opération, donc on est toujours dans la même problématique. Pour résumer, le langage a clairement des faiblesses, c'est pas nouveau tout le monde le dit et on s'est pas mal adapté ces dernières années (typescript en tête) pour mitiger ces problèmes. Mais pour un débutant je ne pense pas qu'on devrait lui conseiller de "manipuler les types et voir comment les opérateurs fonctionnent entre plusieurs types" ça devrait je pense être une mauvaise pratique ce genre de choses dans TOUS les langages, il en va de l'apprentissage du développeur. Et malheureusement en JS on ne pourra pas lui dire "N'additionne que des variables d'un même type", car en JS il y a pas vraiment de vérification de type, à moins de mettre un commentaire au dessus de chaque variable ou d'avoir un bon IDE écrire du code mélangeant les types sera trop facile et un débutant ferra l'erreur car aucun système ne bloquera l'exécution si il fait ce genre d'erreurs. Sinon la vidéo est sympa
Chaque techno a ses raisons tout simplement. Perso j’ai bossé dans des sociétés où il était obligé d’utiliser certaines techno pour leur performances par exemples. Certain secteurs sont incompatibles avec du Js par exemple et d’autre y sont parfaitement adaptés. Mais dans certains secteur et besoin, JS est juste no way
Bonjour, je comprends bien qu’en fonction des secteurs d’activité, les langages ne sont pas du tout les mêmes. (Embarque C++, frontend JavaScript pr exemple) Cependant il y a bien souvent des guerres de chapelle à l’intérieur d’un écosystème donné. C’est là-dessus que porte ma réflexion.
Je vois pas en quoi le C++ serait meilleur que javascript sur un site web ça ne fonctionnerait pas, comparer des langages qui n'ont pas le même objectif j'ai jamais compris pourquoi certains font ça, y'a pas de sens. C'est comme dire "mon avion va plus vite qu'un sous marin lolilo" Un no sens.
Comme d'hab, la vignette m'a attiré et le contenu m'a fait rester.
Mon plan machiavélique pour répandre le code propre a fonctionné !
Pour moi, les 4 éléments les plus importants utiliser au quotidien serait plus :
- les types (primitif, class) "j'utilise très peux les array[] ou object{}"
- les Map/Sets
- les promise
- les proxies
Et sur le plan théorique, comprendre les optimisations polymorphiques du moteur V8 des functions, ainsi que les notions de scope et de closures et tous le concept décorateur.
Map et Set sont des objets très peu utiles à pars dans certains cas. Si c'est votre utilisation de Javascript aux quotidiens, je suis intrigué pars le travaille que vous faite 🙂.
@@mathieucampani5023 moteur et éditeur de jeux
Top Simon ! J'aime beaucoup l'exemple de Netflix pour comprendre les observables 😊
Oui, l’analogie est pas mal. 😅
Superbe vidéo!!
Je te suis depuis quelques temps et j’apprécie les différents sujets que tu traites comme le clean code, design pattern, les best practices…
Cela m’a servi durant mon apprentissage qui arrivent à sa fin et je pourrai les revoir (notamment les vidéo TypeScript) lors de mon premier poste en CDI 😊
Stéphane
Salut Stéphane, merci d’avoir pris le temps d’écrire un commentaire, ça fait toujours plaisir de lire des messages comme le tiens. Bon code pour la suite !
Salut encore une vidéo conseil de très bonne qualité je t en remercie beaucoup et merci pour ta vidéo formation JavaScript ça m’a beaucoup aider pour les fondamentaux cdt
Merci pour ton retour. Je suis content que le workshop sur JavaScript t’ai permis d’aller plus loin pour approfondir les fondamentaux. 👍
Bon code pour la suite et à bientôt !
J'ai terminé le workshop. Ce serait bien que les vidéos soient disponible pour téléchargement. Ainsi, je pourrais y retourner si besoin.
Merci !
Avec plaisir, bon code !
Salut Simon ! Je vais et j'espère de même chez vous ! Vraiment désolé, je ne vous ai pas remercié pour les newsletters et l'invitation par rapport aux mises à jour dans Angular Senior Workshop. Je gérais des embrouilles par ci par là, mais maintenant ça va 🤣. Merci pour le travail !
Au top, content de savoir que ça va mieux pour vous. J’espère pouvoir terminer le workshop dans les semaines à venir. Bon code !
Super vidéo! Le seul truc qui me chiffonne c est que j ai qd meme l impression que les observable sont plus une implementation d un concept via des libraries comme rxjs et ne font pas partie de javascript en tant que tel.
Bonjour,
Vidéos de qualité qui explique de bon concept :)
Je suis votre formation sur Angular 15, et vous aviez parlé de faire une formation sur la version 18. Je suis impatient de pouvoir la suivre, et me demandais si elle sera prévue dans les semaines à venir?
Sébastien
Salut, merci pour ton retour sur la vidéo. 👍
La formation pour Angular 18 est déjà disponible gratuitement sur angularsenior.fr. Il suffit de vous inscrire à la Newsletter. Le format vidéo disponible sur RUclips, ce ne sera pas avant 6 mois je pense. Le tournage et montage prennent toujours beaucoup de temps.
Le workshop est au format texte actuellement.
@@codeursenior ooohhhhh mais c'est super ça!! je fonce voir ce qu'il en est, et à bientôt si j'ai des questions :D, merci pour toutes ces connaissances
Toujours aussi clair !
Merci ! Bon code !
Les signals vont probablement arriver aussi dans des prochaines spec JS, et ce serait cool :)
Ah oui ce serait top d’avoir accès à cette primitive réactive gratuitement avec le langage. Cependant, le processus d’acceptation par le TC39 prends généralement des années. Un peu de patience encore 👍
La notification qui fait plaisir 🎉
Et le commentaire qui fait plaisir ! 🔥
1 + "1" = "11" et non 11 ... JS va appliquer un toString sur le number afin d'avoir les mêmes types et ensuite il va concaténer le tout, d'où "11" et non 11. ;)
avec les promises il faut a minima voir await sinon on rate la meilleure partie
Oh même sans async/await ça reste du sérieux.
Cette nouvelle syntaxe est d'ailleurs construite par dessus la Promise API pour venir l'enrichir.
Le jour où les différents languages utiliseront le même dictionnaire de mots pour les mêmes conceptes/fonctions, on ferra un grand pas.
Tous ce qui est présenté ici n'est qu'un renommage de predicate, iterator, lambda, callback (func ptr), etc.
(je ne critique pas la vidéo, elle est très bien. Et merci 😊)
Inventer une terminologie pour ne pas dire qu'on réinvente la roue, c'est à mon sens le 1er problèmes des "languages".
Ce qu'apport réelement un language, c'est le sucre syntaxique qui va faire appel à des conceptes avancé. Qu'ils soient codé dans le moteur (vm) ou le compilateur.
Si j'invente un language avec un sucre syntaxique appelé "rpc(xxx)", je n'invente rien. Je rend juste plus simple l'utilisation de rpc/marshaling (proxy). si maintenant je l'appel "PubSub"... bah j'ai juste changé le nom, pas le concepte.
Ca reste mon appréciation 😊
Hello, je vous rejoint sur un point : il y a un problème de nommage dans cette industrie. Il faut parfois 15min pour comprendre que 2 hommages différents désignent le même concept !
@@codeursenior Un point c'est déjà pas mal 😁
@@BrainStroming1789 😅
Pour la première partie, est-ce que le problème n'est pas pris à l'envers ? Est-ce que le bon choix ne serait pas plutôt d'expliquer que "le typage dynamique" peut créer tous ces comportements peu intuitifs et qui risquent de créer des bugs, donc en javascript il vaut mieux utiliser tel outil de vérification de typage statique dans des projets professionnels (sans pour autant passer au typescript).
Cela me semble être beaucoup plus intéressant de montrer que cette absent de contrat sur les types va créer énormément de problème dans la gestion des opérations (mais pas que, puisque qu'une variable peut passer du int au string ou au bool alors que l'on s'attend par exemple à avoir un float). Ne pas exprimer ces contrats et le marteler me donne l'impression que ça va amener des débutants à avoir une mauvaise approche logiciel, à base de tests et d'l'intuition sur les résultats d'expressions en javascript. Le problème n'est pas que le débutant va m'expliquer qu'il sait ce que va créer l'opération, le problème c'est que son code soit à ce point peu safe qu'il permette ce type de bizarreries, je me dirais au contraire qu'il ne maitrise rien du tout 😅
Je vois en cherchant rapidement sur internet qu'il existe un outil comme flow et j'imagine que des IDE doivent proposer certaines solutions équivalentes pour de la vérification de typage statique. À moins que je sois complètement dans le faux et que ce genre d'outils n'a pas pris dans le monde professionnel en javascript ? (et si ce n'est pas le cas, pour quelles raisons ? 🥲)
3:07 ...mais si 1 + 1 = 1 ou 1 + 1 = 11, là c'est beau !
Si 1+1 vaut 2 et que 1+1 vaut 3 en binaire, bah 1 + 1 = 1 + 1 =
Tout s’éclair, merci !
J'interviens car je suis assez surpris de l'argument énoncé vers la 3ème minute qui laisse entendre que ce que reprochent les gens au JS c'est : "Non, les types sont importants en JS car si vous additionnez un nombre et une chaine il faut savoir que l'opérateur va fonctionner bizarrement car dans ce contexte l'opérateur d'additions sera une concaténation". Or, ce n'est évidemment pas ce qui est reproché à JS au travers de son manque de typage, c'est que justement le langage nous laisse faire une additions pareille (et les exemples de ce genre sont légions). De nombreux développeurs préfèrent être arrêtés avant même l'exécution quand il font une telle chose plutôt que d'avoir des comportements "étranges" (même si ils paraissent logique une fois qu'on a mis le nez dedans).
Oui, une fois qu'on comprend comment fonctionne JS on apprend soit à ne plus utiliser ces comportements étranges et à les éviter. Soit on s'en sert à bon escient. Mais qu'on les connaisse ou pas en profondeurs ces comportements "étranges" il reste qu'on peut légitimement les considérer comme problématiques et dangereux pour la qualité du code produit.
D'ailleurs le problème se voit bien avec ce qui vient juste après, à savoir "Bombardez typeof et regardez comment JS fonctionne avec tel ou tel type". Oui mais si on est obligé de faire ça c'est bien qu'à la base il y a un manque de clareté. Le langage est très peu intuitif et même un expert finira par se faire avoir et ferra une erreur. Plus le langage est léger avec nous en terme de verifs plus on a de risque de se planter. Pareil avec le "Il existe aussi le type fonction mais on le manipule pas avec des opérateurs + ou des - car ça donne des choses très étranges". Oui, je suis d'accord, sauf qu'on manipule et stocke relativement souvent des callback qu'on met dans des variables. Si l'utilisation de la variable est loin de son affectation le développeur peut vite oublier qu'il n'a pas un nombre mais un type (même en nommant bien la variable), et puis de toute façon, qu'il oublie ou pas le langage nous laisse faire cette opération, donc on est toujours dans la même problématique.
Pour résumer, le langage a clairement des faiblesses, c'est pas nouveau tout le monde le dit et on s'est pas mal adapté ces dernières années (typescript en tête) pour mitiger ces problèmes. Mais pour un débutant je ne pense pas qu'on devrait lui conseiller de "manipuler les types et voir comment les opérateurs fonctionnent entre plusieurs types" ça devrait je pense être une mauvaise pratique ce genre de choses dans TOUS les langages, il en va de l'apprentissage du développeur. Et malheureusement en JS on ne pourra pas lui dire "N'additionne que des variables d'un même type", car en JS il y a pas vraiment de vérification de type, à moins de mettre un commentaire au dessus de chaque variable ou d'avoir un bon IDE écrire du code mélangeant les types sera trop facile et un débutant ferra l'erreur car aucun système ne bloquera l'exécution si il fait ce genre d'erreurs.
Sinon la vidéo est sympa
Chaque techno a ses raisons tout simplement. Perso j’ai bossé dans des sociétés où il était obligé d’utiliser certaines techno pour leur performances par exemples. Certain secteurs sont incompatibles avec du Js par exemple et d’autre y sont parfaitement adaptés. Mais dans certains secteur et besoin, JS est juste no way
Bonjour, je comprends bien qu’en fonction des secteurs d’activité, les langages ne sont pas du tout les mêmes. (Embarque C++, frontend JavaScript pr exemple) Cependant il y a bien souvent des guerres de chapelle à l’intérieur d’un écosystème donné. C’est là-dessus que porte ma réflexion.
mec t'habite pas à Marignane par hasard Parc saint Louis/saint georges ?
Holà, non pas du tout. La piscine ressemble à celle de la bas ? La c’est en Espagne à Malaga 🇪🇸
Je vois pas en quoi le C++ serait meilleur que javascript sur un site web ça ne fonctionnerait pas, comparer des langages qui n'ont pas le même objectif j'ai jamais compris pourquoi certains font ça, y'a pas de sens. C'est comme dire "mon avion va plus vite qu'un sous marin lolilo" Un no sens.