On remarque pas que ce mec nous pond des videos de 15 minutes sans aucun cut aucun begaiement aucun blanc. C'est la preuve que tu est un bon pédagogue et que tu connais parfaitement ton sujet
J'ai commencé Vue en 2015 et je dois avouer qu'avec Vue 3, je partage entièrement ton analyse qui est juste sur tous les points - quand je passe de Next à Vue, j'ai toujours ces vieux réflexes de .value ou de décorateurs qui reviennent et je me dis: quelle perte de temps parfois. Il faut nous laisser le temps, à nous les contributeurs de Vue, d'améliorer le framework car nous avons toujours eu un temps de retard sur React, il faut l'avouer (force du nombre peut-être).
C'est sympa d'avoir ton avis sur le sujet. Ça fait un bail que j'utilise vue donc rien de tout ça ne me gêne. Au contraire, j'adore la composition api car ça permet de se rapprocher plus du javascript natif et de pouvoir mieux structurer et réutiliser son projet. Après, je viens de vue 2, donc j'ai ce discours. (Je comprends les choix fait). C'est vrai qu'on s'éloigne du concept original (dev friendly, simple etc) et on sent qu'ils veulent se rapprocher de react.
Super cool avis :) Perso on utilise vue 3 au taff c'est vraiment un plaisir avec la composition api. En revanche mon problème est avec volar où c'est carrément énervant le support qui est un peu pété :/ Bon après je sens vraiment une maturité qui ne fait que grandir c'est super satisfaisant en plus avec nuxt qui pousse avec les innovations et le typage des routes de la base de donnée jusqu'au composant c'est génial ! En somme vraiment pressé que Volar arrive a maturité ! et ps je crois que tous les frameworks passent a la reactivité fine avec les proxies donc svelte et angular vont aussi avoir une syntaxe qui ressemble ^^
Wao ! Très belle video. On eu presque le même parcours avec les frontend, sauf qu'au moment ou j'ai touché vue.js, j'ai zappé React. Personnelement j'ai trouvé vue.js beaucoup plus simple , (Svelte aussi mais..) J'avoue qu'avec l'API Composition on se perd au debut mais cela devient très vite naturel. Ils sont au courant, une version est à l'éssai qui nous simplifira la tâche en nous permettant de plus utiliser les "variable.value" sur des ref ainsi que d'autre simplications sur les ref().
Enfin, une vidéo tel que je le concevais de ta part sur l'utilisation de différentes technologies et leurs abandons ou de leurs adoptions. Une technologie, si tu n'as pas d'affinité avec elle, tu ne la comprends pas. Et je m’efforce chaque jour, d'être le plus compatissant possible et d'apprendre à la connaitre. Qui tu es ? Quelles sont tes origines ? Je ne connais, peux-tu m'expliquer, m'instruire ? Est-ce que le schéma de compréhension est adapté à ma personne ? Une personne, peut-elle me faire switch et m'éclairer ? Aucune technologie n'est *nulle*, toutes se valent dans leur domaine respectif. C'est notre méconnaissance qui nous freine, le changement des habitudes. En somme, l'adaptation aux paradigmes, à des modèles de pensées. Et ce qui freine, c'est pas le technologie, mais ta façon de penser.
C'est bien argumenté :) Je te rejoins sur certain points, de l'autre il n'y a pas de framework parfait et si on est pas freelance, enfin de compte pas de stress, les entreprises/projets ne s'effacent pas du jour au lendemain, tout comme les évolutions :)
J'ai touché un peu à tout ces 10 dernieres années. Là ça fait 1 / 2 ans que j'fais du React hooks j'me vois plus utiliser autre chose pour du front applicatif.
Je me retrouve pas mal dans les problèmes 2 et 4. Avec le peu d'xp que j'ai sur VueJS et React, je trouve ça cool du coup d'avoir un comparatif de ta part sur les points qui te gênent (ça m'aide à comprendre les faiblesses et forces de chacun)
Je trouve ça un peu curieux cette histoire avec n à 8:30 Non, n ne sera pas automatiquement mis à jour puisqu'il ne s'agit pas d'un pointeur sur n mais d'une assignation qui est figée. Si tu faisais const getN = () => props.n Puis que tu cherchais à obtenir n en faisant getN() (donc obtenir la valeur courante de n avec une callback afin de garantir un accès frais à "n"), qu'est-ce que ça donnerait, du coup ? Je ne dis pas que c'est plus pratique, juste que techniquement, je ne suis pour ma part absolument pas surpris du comportement que ça a au runtime.
Bonne vidéo, j'avoue que j'ai beaucoup ragé au passage vers la Composition API, mais j'aurais tendance à dire que c'est vraiment pas mal quand on commence à avoir l'habitude. - La direction vers Vapor est un bon choix, ça pourrait reprendre un paradigme assez similaire à Svelte et nous offrir d'excellentes perfs - Les galères d'usage sur les Refs, et particulièrement sur la destructuration vont être corrigées, l'équipe est au courant de ce pb - Nuxt offre un environnement surpuissant pour développer à peu près tout, avec des avantages assez imbattables sur les performances pour du SSR - Pinia est par contre un très mauvais outil, qui pousse à créer des singleton un peu partout, partagés par les composants. La logique peut très vite devenir très complexe lorsque l'on utilise des stores, et Vue devrait vivement proscrire ces derniers
Pour Pinia, je pense que le problème que tu décris est un faux-problème. Si tu fais une distinction entre state client et state serveur, que tu utilises les bons outils pour chaque responsabilité : @tanstack/query pour le server state Pinia pour le client state Tu te retrouves au final avec assez peu de state client, car la majorité des applications ont essentiellement du state server Du coup, les problématiques de sur-utilisation de Pinia ne se font pas sentir
Hello @Conobipe, Merci pour ton partage d'expérience. Peux tu en dire plus sur cette phrase: 'Les galères d'usage sur les Refs, et particulièrement sur la destructuration vont être corrigées, l'équipe est au courant de ce pb' Il y a t'il une RFC, un article, une annonce dans Vue comme solution à ce problème spécifique ??
Vue 3 n’est pas parfait mais c’est quand même un écosystème bien plus productif que React (et j’ai bossé en entreprise avec les deux) Pas de perte de temps à comprendre tout ce clusterfuck de rerender avec useMemo, useCallback, useEffect, etc Pas de perte de temps à débattre de quel système css on va adopter : styled components, CSS modules, tailwind, pandaCSS, etc… Pas de perte de temps à débattre quel système de state manager on va adopter: Redux? Mobx? Zustand? Etc C’est fou le temps qu’on peut perdre en entreprise à débattre ces trucs.
Ouai, l'un des avantages de vue c'est que ça diminue la fatigue décisionelle mais au final je trouve React hooks > Vue composition en terme de flexibilité et de DX. Après ce que je n'aime pas avec React c'est l'emprise qu'a Vercel dessus et la direction qu'ils sont entrain de prendre.
@@georgezimmer5622 Oui toute cette fanfare autour de NextJS c’est fatiguant quand tu bosses pour un éditeur de logiciel. Tu t’en fous du SSR quand ton app est derrière un login, t’as pas de contraintes SEO ni de contraintes fortes niveau performances. Tu t’en fous des server actions quand ton app est de base assez complexe pour justifier un split entre responsabilités client / server
Vue est clairement plus simple à apprendre que React à l’heure actuelle. La déstructuration des props fonctionne bien, il suffit juste de l’autoriser 😂. Pour moi c’est clairement le framework le plus intelligent car il reprend les bonnes idées des autres frameworks et les rend simples. Bref en terme de productivité et pour bosser en équipe c’est super.
Bon pour le CSS ça ne résoud pas grand chose à part que ça offre un style scoped. Le CSS reste bordelique, tu redeclare très souvent la même chose etc ... Donc la discussion se pose aussi, j'ai jamais vraiment utiliser le CSS avec VueJS directement
@@ZeldriFR ça offre un style scoped et aussi une solution de css dans le même fichier donc qui bénéfice de la colocation. Ça évite les alternatives à la styled-components
Cette vidéo est intéressante car elle me permet de mieux comprendre sur moi-même. À la base, c'est ta chaîne qui m'a fait découvrir Vue 2. J'aimais beaucoup cette façon de concevoir les choses. Mais surtout, je ne connaissais même pas l'existence de React. Donc, à l'arrivée de Vue 3, j'ai été plutôt surpris par cette nouvelle façon de voir les choses. Et personnellement, j'ai accroché. La décomposition des props peut sembler bizarre, mais j'ai trouvé ce concept très pratique. Mais aujourd'hui, j'ai changé ; je ne me vois plus vraiment utiliser Vue comme ma solution par défaut, dans le sens où mon intérêt s'est davantage recentré sur le serveur. Et maintenant, je ressens tous ces points que tu as évoqués. Aujourd'hui, Vue ne représente plus vraiment ce que je souhaite qu'Internet soit, de même pour React. Je suis plus intrigué par HTMX, Solid ou Svelte par exemple. En tout cas, cette vidéo est très intéressante et j'espère qu'on arrêtera de te demander une formation sur Vue 3 ^^
Pour qui aime faire du React et du JSX, Solid.js est sympa également. L’écosystème est jeune mais je trouve que la technologie est aboutie et fait le choix d’intégrer des choses qui ne sont pas présentes par défaut dans React (comme les stores ou l’ajout de classes conditionnelles sur un élément du dom facilement), ce qui est appréciable. Ce n’est pas parfait notamment sur certains points techniques comme la déstructuration des props et ce genre de choses, mais je pense que la lib vaut le détour malgré tout. Et merci pour ta vidéo, tu as mis des mots sur mon ressenti de VueJS par rapport aux autres frameworks. ❤
Super intéressant comme point de vue car contrairement à beaucoup de personnes qui s'expriment sur le sujet, on sent que tu as réellement essayé et expérimenté vueJS et d'autres frameworks ! J'adorerai voir une vidéo comparative (une vidéo par framework) ou on expose les forces et faiblesse du framework pour une app real world simple (exemple: une app gestion de contacts avec les opérations CRUD, la validation des forms, l'internationalisation, ...) Les frameworks sont des outils mais on défend souvent notre opinion de manière subjective et biaisée. Je trouve que sur ce sujet glissant, la vidéo est intéressante et bien faite car c'est argumenté et plustot objectif ! Merci pour le contenu :)
Si je résume, ce sont avant tout des détails ce qui montre que React et Vue sont tous les deux des bons choix. Les défauts de Vue : - moins adopté que React - les dernières versions rajoutent une complexité, Vue s'éloigne de ses qualités originales qui sont d'être developer-friendly Et Vue devient moins friendly, autant passer sur React quitte à se prendre la tête 😂 ça fait sens ! Néanmoins ça ne disqualifie pas Vue selon moi car reste bien plus simple que React, on est pas obligé d'utiliser les nouvelles fonctionnalités ! Conduit à un code bien plus maintenable, bien plus facile d'onboarder des juniors... Bon je dis ça mais j'utilise React à cause du point 1 😂
J'ai un peu le même ressenti. Au final pour le moment à choisir, je préfère Svelte. Mais pareil, je tourne beaucoup d'années en années et le choix des frameworks / librairies front ou back m'importe beaucoup moins que les pratiques et architectures en place. Etant plus back que front, de toute façon React, Vue ou Svelte c'est kif kif. De manière générale je tends vers le moins verbeux j'ai l'impression.
Je suis Full Stack, l’écosystème Frontend est aujourd'hui dans beaucoup de situation expérimental. Les Primer Adopters ne sont pas les grands groupes, tout du moins tant qu'ils ne sponsorisent pas la dite technologie, et encore... Quand au choix, je suis comme toi, la verbosité, je veux du concis que l'on comprend sans artifice problématique comme les refs dans vue. C'est fou, mais en fait, c'est réglable en ajoutant une couche de Strategy Design / Interface, c'est fou, hein ?
Je te rejoins sur la complexification de Vue, mais c'est pourquoi je continue d'utiliser l'API options. En effet, les devs ont indiqué que celle-ci est facile à maintenir et ne sera donc pas dépréciée de sitôt. Quant à Svelte, je suis tellement impressionné par l'efficacité de leurs choix jusqu'ici que j'ai beaucoup d'espoir que ça continue dans la bonne direction, mais évidemment, c'est pas garanti.
Sympa, je partage pas mal ton avis, au début je pensais que la composition API serait bien, mais j'ai l'impression que c'est de plus en plus compliqué. Et j'aimerais pas Angular et je commence à le préférer juste parce qu'il a Typescript obligatoire et que je suis sûr d'avoir aucun problème de typage.
Tu peux tout à fait utiliser Vue3 avec typeScript dès l'initialisation du projet. Quant à la compo c'est dommage car c'est la meilleure chose qui existe en comparaison à l'option qui est juste imbuvable. Rien de compliqué, la grande satisfaction est lorsque tu comprends que tes variables sont d'office réactives. La décomposition des props dans l'exemple que prend Grafikart n'est clairement pas conseillé et n'apporte rien d'ailleurs. Comme je l'ai dit plus haut, le problème ici est de vouloir faire du React sur du Vue. Ca n'a littéralement aucun sens. Décomposer ses props n'a pas d'intérêt. Quant au .value, tu t'y fais et il existe des plugins VsCode qui facilitent l'autocompletion.
@@MrJohAA Le problème c'est que ce n'est pas pensé Typescript, donc le typage est hasardeux comme en React. Oui la syntaxe est meilleure mais je trouve l'approche svelte mieux car c'est verbeux d'accéder à l'état.
@@rawz06Je comprends. Je trouve également qu'Angular propose une réelle structure de projet. En revanche Ts est un langage de typage qui vient en surcouche d'un autre langage. Partir sur du Angular juste parce qu'il supporte nativement Ts n'est pas si pertinent au fond sachant qu'à l'heure actuelle Angular a perdu en popularité et est surtout utilisé par les grosses entreprises type ESN. La courbe d'apprentissage reste raide. Il n'en reste pas moins un choix de framework intéressant. Tout dépendra de l'affinité que tu as avec le framework. Si tu aimes faire du TS et qu'utiliser des classes javascript te plait dans ce cas Angular me parait être un bon choix. Quant à svelte je trouve que c'est un paris risqué pour l'instant. Pour le state il y a Pinia qui fait largement l'affaire. Finis les mapGetters et autres. Mais bon, mon avis n'est peut être pas si objectif que ça 😁
Merci ! Je suis plutôt d'accord avec tes points mais pour moi de mon experience le principal est la complexité de l'écosystème vue de nos jours. En 2016-2018 tout était encore rose, une seule version vue2 et tout roulait maintenant entre vue2, vue 2.7 et vue3 avec donc certains module de la communauté compatible , d'autres non mais pas forcément indiqué comme tel. Les migrations sont complexes , parfois impossible, le liens entre typescript et vue2/vue3 et les IDE (volart) pas forcément facile ou 100% fonctionnels. Le temps qu'a mis vu a passé officiellement la 3 par default et la doc qui a changé plusieurs en par défaut sur vue3 puis re-vue2 .. 😖
J'utilise Vue et React depuis quelques années. Pour Vue, je te rejoins totalement sur la perte de réactivité lors d'une déstructuration d'une ref/reactive, c'est agaçant, MAIS rapidement maîtrisable. Les autres points énumérés me paraissent très peu impactant. Je préfère aujourd'hui encore Vue à React. La maintenance sur les projets avec par exemple la gestion du store (très pratique avec Vue Composition API) me parait plus simple que React avec Redux où le côté synchrone est un peu gênant. En soit, il est juste question de préférence. React et Vue restent top ;)
C'est justement le propos de la vidéo : Utiliser des outils tiers qui ne sont pas forcément à jour car manque de popularité et que même si tu installes l'extension tiers, tu n'es pas à l'abri de la latence d'implémentation du tiers.
Tout à fait d'accord avec API composition, personnellement je le trouve absurde je kiff la logique en option API qui est simple et qui est commune à tous projets inferieur à vue 3, ne pas utiliser l'option api c'est ce tirer une balle dans le pieds dés le départ, sauf si vous aimez vous faire mal au crane
Petite astuce pour différencier les références des autres variables / props, toujours les préfixer par "Ref". Exemple : maVariableRef. Cette logique peut aussi être appliquée au computed. En utilisant le participe passé (en anglais) ou un verbe comme tu l'as fait pour le "isPair". On pourrait donc avoir des variables computed comme : isPair, isLoading, disabled, hasRoles etc... Avec ce nommage on remarque d'un coup d'oeil à quoi correspond la variable. Édit : suffixer
Je me forme actuellement à Vue aussi et je comprends assez bien tes pain points, particulièrement sur le prop destructuring. Bon à savoir, il est déjà possible depuis la 3.3 de déstructurer ses props en rajoutant une ligne sur la config, comme pour le defineModel. Ce sera probablement disponible sans changer la config dans le futur
Est ce qu il y aura un framework qui répondrait à tout ?Non bien entendu ,apprenons donc continuellement et apprécier selon vos goût voilà ce qu il faut retenir avec tout ces outils
Pour ne pas se mélanger les pinceaux avec le ".value" On peut utiliser "unref", une méthode propre à l'API Reactive de VueJS. Ce qui permet d'utiliser la variable directement.
Ca ça ne résoud pas vraiment le problème car il faut rajouter cette méthode sur chaque utilisation de variable au cas où ça soit une ref si on veut garantir de ne pas faire d'étourderie.
@@skybluFr Pas du tout. Unref permet d'afficher la valeur de la variable, qu'elle soit réactive ou pas. Mais on continue de garder la réactivité de la variable originale. Exemple : if(unref(myValue) === "VueJS"){} N'empêche en rien de continuer à faire myValue.value = "ReactJS"
@@auredud461 Oui ça ne résout pas intégralement le problème. Mais cela a le mérite d'éviter d'utiliser ".value" partout. En plus, cela permet de garder la réactivité et cela affiche la valeur de la variable, qu'elle soit réactive ou non.
@@thehikarilab Alors ... oui mais qui va ajouter cette surcouchr juste pout avoir accès a une valeur ? Je pensais que tu disais : const maValeur = unref(autreRef)
Je dirai tout de même que Vue est "mieux" que React dans la majorité des cas... plus pragmatique et plus complet OOTB. Pas essayé Svelte mais Vue / React ne m'ont pas posé suffisamment problème pour que j'ai envie de m'intéresser à YAJSF.
Perso j'ai arrêté VueJs, car j'en ai un peu marre qu'ils changent d'approche tous les 18 mois et que toutes les librairies derrières peine à suivre leurs approches. Je trouve la composition API super flexible et extensible, mais je trouve presque un peu trop compliqué pour en tirer profit. Je trouve un peu moyen ton argument concernant l'extension, ca n'a rien à voir avec le fait que ce soit une extension inconnue, mais au fait que react est plus populaire et que les outils la comprennent plus facilement. J'aurais même tendance à dire que les outils peuvent plus facilement comprendre les fichiers vue que react, c'est mieux séparé entre logique et html
C'est bien VUE, sans être REACT les arguments pourrait s'appliquer à celui-ci, je préfére rester SVELTE pour réduire la charge mental, ou à la limite HTMX, le "html" à la Elon Musk , d'ailleur celui-ci pourrait le racheter le 1 avril 2024 pour l'intégrer à X 🙂🙂🙂.
J'ai toujours trouvé que VueJs est une mauvaise évolution anachronique d'AngularJs. Soit ça n'apporte pas grand chose de plus que l'ancienne librairie soit ca apporte bien plus de complication que les concurrents modernes. Il est aujourd'hui tellement simple que créer un front dissocié du back que je peine à trouver des cas d'usage non-marginaux a de telle technologie. Personnellement j'oscille selon les besoins entre React, Angular et le Js native. Je ne ferme pas la porte à de la concurrence (je garde par exemple un oeil attentif sur SolidJs) mais je doute que mes choix futurs aillent dans la direction de VueJs.
Mon historique est vraiment très similaire au tient, je partage complètement ton point de vue et j'ai arrêté de l'utiliser à partir de la v3 avec l'apparition des ref qui complique énormément les choses. J'ai pourtant adoré la v1 et la v2, super dommage ... C'est à ce moment là que j'ai décidé de me tourner vers React et de partir sur une nouvelle mission. Aujourd'hui je ne regrette absolument pas mon choix 😇
Mouif enfin, quitter Vue pour aller sur du React c'est un peu comme quitter un étron pour prendre une bouse. Pour du travail propre, Angular reste la valeur sûre.
J'avoue ne pas avoir compris l'intérêt de la composition API, perso j'utilise l'option API qui est top et j'arrive a faire ce que je veux sur tous mes projets
Maintenant les développeurs react sont allés vers Next.js hhhh par rapport à l'optimisation di référencement la simplicité des routes l'optimisation des images et encore possibilité de faire rendu serveur et rendu client. Ça ne s'arrête pas l'évolution du développement web mdr
ça me fait trop rire le disclaimer pour éviter d'utiliser cette vidéo "contre" Vue.js, d'habitude c'est plutôt les youtubeurs qui ont des petites embrouilles avec d'autres "influenceurs" qui font une vidéo en mode "n'allez pas le troller, ou l'insulter sur ses lives, on a fait la paix" ;D
Justement, c'est pas pcq il ne fait plus rien sur cette techno que tu dois l'arrêter. Si tu aimes travailler avec Vue c'est pas pcq Grafikart arrête de suivre cette techno que tu dois l'arrêter comme il a dit C'est stupide car y a toujours moyen d'apprendre en dehors de Grafikart (malgré que j'avoue, avoir du contenu français et de qualité fait la différence)@@nicolaslachise4187
On remarque pas que ce mec nous pond des videos de 15 minutes sans aucun cut aucun begaiement aucun blanc. C'est la preuve que tu est un bon pédagogue et que tu connais parfaitement ton sujet
Tu en doutai encore xD
c'est clair le mec je les connus depuis 2015 ou 16, il a surement su s'ameliorer avec le temps
La base c'est de préparer son texte comme une présentation en publique classique même si il ne manque pas de compétences pour expliciter tout ça
il fait des. videos depuis 20 ans
J'ai commencé Vue en 2015 et je dois avouer qu'avec Vue 3, je partage entièrement ton analyse qui est juste sur tous les points - quand je passe de Next à Vue, j'ai toujours ces vieux réflexes de .value ou de décorateurs qui reviennent et je me dis: quelle perte de temps parfois. Il faut nous laisser le temps, à nous les contributeurs de Vue, d'améliorer le framework car nous avons toujours eu un temps de retard sur React, il faut l'avouer (force du nombre peut-être).
C'est sympa d'avoir ton avis sur le sujet. Ça fait un bail que j'utilise vue donc rien de tout ça ne me gêne. Au contraire, j'adore la composition api car ça permet de se rapprocher plus du javascript natif et de pouvoir mieux structurer et réutiliser son projet.
Après, je viens de vue 2, donc j'ai ce discours. (Je comprends les choix fait).
C'est vrai qu'on s'éloigne du concept original (dev friendly, simple etc) et on sent qu'ils veulent se rapprocher de react.
Super cool avis :)
Perso on utilise vue 3 au taff c'est vraiment un plaisir avec la composition api.
En revanche mon problème est avec volar où c'est carrément énervant le support qui est un peu pété :/
Bon après je sens vraiment une maturité qui ne fait que grandir c'est super satisfaisant en plus avec nuxt qui pousse avec les innovations et le typage des routes de la base de donnée jusqu'au composant c'est génial !
En somme vraiment pressé que Volar arrive a maturité !
et ps je crois que tous les frameworks passent a la reactivité fine avec les proxies donc svelte et angular vont aussi avoir une syntaxe qui ressemble ^^
Bonjour,
Oui je suis également attentif à nuxt que je commence à utiliser.
On espère que sa communauté grandira encore.
Hello grafikart, merci pour la video ! J'ai l'impression que depuis la V1 de vue.js il y'a l'utilisation des signaux pour une réactivité fine !
Je suis tes cours depuis des années et j'ai développé énormément d'app web.
Tellement reconnaissant.
Wao ! Très belle video.
On eu presque le même parcours avec les frontend, sauf qu'au moment ou j'ai touché vue.js, j'ai zappé React.
Personnelement j'ai trouvé vue.js beaucoup plus simple , (Svelte aussi mais..)
J'avoue qu'avec l'API Composition on se perd au debut mais cela devient très vite naturel.
Ils sont au courant, une version est à l'éssai qui nous simplifira la tâche en nous permettant de plus utiliser les "variable.value" sur des ref ainsi que d'autre simplications sur les ref().
Super intéressant.
hâte de voir la suite des technos délaissées ... 🙃
Concept et vidéo très intéressants. C'est très bien d'avoir décrit les cas d'usages avec des exemples.
Bonjour ! Je me demande souvent comment faites vous pour apprendre autant de langage et surtout comment parvenez-vous à les maîtriser aussi bien ?
Enfin, une vidéo tel que je le concevais de ta part sur l'utilisation de différentes technologies et leurs abandons ou de leurs adoptions.
Une technologie, si tu n'as pas d'affinité avec elle, tu ne la comprends pas.
Et je m’efforce chaque jour, d'être le plus compatissant possible et d'apprendre à la connaitre.
Qui tu es ? Quelles sont tes origines ? Je ne connais, peux-tu m'expliquer, m'instruire ?
Est-ce que le schéma de compréhension est adapté à ma personne ?
Une personne, peut-elle me faire switch et m'éclairer ?
Aucune technologie n'est *nulle*, toutes se valent dans leur domaine respectif.
C'est notre méconnaissance qui nous freine, le changement des habitudes.
En somme, l'adaptation aux paradigmes, à des modèles de pensées.
Et ce qui freine, c'est pas le technologie, mais ta façon de penser.
Ca fait du bien de voir des vidéos avec ce type de contenu :)
C'est bien argumenté :) Je te rejoins sur certain points, de l'autre il n'y a pas de framework parfait et si on est pas freelance, enfin de compte pas de stress, les entreprises/projets ne s'effacent pas du jour au lendemain, tout comme les évolutions :)
J'ai touché un peu à tout ces 10 dernieres années. Là ça fait 1 / 2 ans que j'fais du React hooks j'me vois plus utiliser autre chose pour du front applicatif.
Je suis d'accord avec tout ce que tu dis sur Vue3. C'est pour cela que j'utilise Angular 😉
Je me retrouve pas mal dans les problèmes 2 et 4. Avec le peu d'xp que j'ai sur VueJS et React, je trouve ça cool du coup d'avoir un comparatif de ta part sur les points qui te gênent (ça m'aide à comprendre les faiblesses et forces de chacun)
Je trouve ça un peu curieux cette histoire avec n à 8:30
Non, n ne sera pas automatiquement mis à jour puisqu'il ne s'agit pas d'un pointeur sur n mais d'une assignation qui est figée.
Si tu faisais const getN = () => props.n
Puis que tu cherchais à obtenir n en faisant getN() (donc obtenir la valeur courante de n avec une callback afin de garantir un accès frais à "n"), qu'est-ce que ça donnerait, du coup ?
Je ne dis pas que c'est plus pratique, juste que techniquement, je ne suis pour ma part absolument pas surpris du comportement que ça a au runtime.
Bonne vidéo, j'avoue que j'ai beaucoup ragé au passage vers la Composition API, mais j'aurais tendance à dire que c'est vraiment pas mal quand on commence à avoir l'habitude.
- La direction vers Vapor est un bon choix, ça pourrait reprendre un paradigme assez similaire à Svelte et nous offrir d'excellentes perfs
- Les galères d'usage sur les Refs, et particulièrement sur la destructuration vont être corrigées, l'équipe est au courant de ce pb
- Nuxt offre un environnement surpuissant pour développer à peu près tout, avec des avantages assez imbattables sur les performances pour du SSR
- Pinia est par contre un très mauvais outil, qui pousse à créer des singleton un peu partout, partagés par les composants. La logique peut très vite devenir très complexe lorsque l'on utilise des stores, et Vue devrait vivement proscrire ces derniers
Pour Pinia, je pense que le problème que tu décris est un faux-problème.
Si tu fais une distinction entre state client et state serveur, que tu utilises les bons outils pour chaque responsabilité : @tanstack/query pour le server state
Pinia pour le client state
Tu te retrouves au final avec assez peu de state client, car la majorité des applications ont essentiellement du state server
Du coup, les problématiques de sur-utilisation de Pinia ne se font pas sentir
Hello @Conobipe,
Merci pour ton partage d'expérience.
Peux tu en dire plus sur cette phrase:
'Les galères d'usage sur les Refs, et particulièrement sur la destructuration vont être corrigées, l'équipe est au courant de ce pb'
Il y a t'il une RFC, un article, une annonce dans Vue comme solution à ce problème spécifique ??
Note que Pinia doit d'après le créateur, disparaître petit à petit.
@@alexandreg.1000 tu as plus d'infos là-dessus ?
Vue 3 n’est pas parfait mais c’est quand même un écosystème bien plus productif que React (et j’ai bossé en entreprise avec les deux)
Pas de perte de temps à comprendre tout ce clusterfuck de rerender avec useMemo, useCallback, useEffect, etc
Pas de perte de temps à débattre de quel système css on va adopter : styled components, CSS modules, tailwind, pandaCSS, etc…
Pas de perte de temps à débattre quel système de state manager on va adopter: Redux? Mobx? Zustand? Etc
C’est fou le temps qu’on peut perdre en entreprise à débattre ces trucs.
Ouai, l'un des avantages de vue c'est que ça diminue la fatigue décisionelle mais au final je trouve React hooks > Vue composition en terme de flexibilité et de DX. Après ce que je n'aime pas avec React c'est l'emprise qu'a Vercel dessus et la direction qu'ils sont entrain de prendre.
@@georgezimmer5622 Oui toute cette fanfare autour de NextJS c’est fatiguant quand tu bosses pour un éditeur de logiciel.
Tu t’en fous du SSR quand ton app est derrière un login, t’as pas de contraintes SEO ni de contraintes fortes niveau performances.
Tu t’en fous des server actions quand ton app est de base assez complexe pour justifier un split entre responsabilités client / server
Vue est clairement plus simple à apprendre que React à l’heure actuelle. La déstructuration des props fonctionne bien, il suffit juste de l’autoriser 😂. Pour moi c’est clairement le framework le plus intelligent car il reprend les bonnes idées des autres frameworks et les rend simples. Bref en terme de productivité et pour bosser en équipe c’est super.
Bon pour le CSS ça ne résoud pas grand chose à part que ça offre un style scoped. Le CSS reste bordelique, tu redeclare très souvent la même chose etc ... Donc la discussion se pose aussi, j'ai jamais vraiment utiliser le CSS avec VueJS directement
@@ZeldriFR ça offre un style scoped et aussi une solution de css dans le même fichier donc qui bénéfice de la colocation.
Ça évite les alternatives à la styled-components
Cette vidéo est intéressante car elle me permet de mieux comprendre sur moi-même.
À la base, c'est ta chaîne qui m'a fait découvrir Vue 2. J'aimais beaucoup cette façon de concevoir les choses. Mais surtout, je ne connaissais même pas l'existence de React.
Donc, à l'arrivée de Vue 3, j'ai été plutôt surpris par cette nouvelle façon de voir les choses. Et personnellement, j'ai accroché. La décomposition des props peut sembler bizarre, mais j'ai trouvé ce concept très pratique.
Mais aujourd'hui, j'ai changé ; je ne me vois plus vraiment utiliser Vue comme ma solution par défaut, dans le sens où mon intérêt s'est davantage recentré sur le serveur.
Et maintenant, je ressens tous ces points que tu as évoqués. Aujourd'hui, Vue ne représente plus vraiment ce que je souhaite qu'Internet soit, de même pour React.
Je suis plus intrigué par HTMX, Solid ou Svelte par exemple.
En tout cas, cette vidéo est très intéressante et j'espère qu'on arrêtera de te demander une formation sur Vue 3 ^^
Très bonne idée cette thématique de vidéo.
Pour qui aime faire du React et du JSX, Solid.js est sympa également.
L’écosystème est jeune mais je trouve que la technologie est aboutie et fait le choix d’intégrer des choses qui ne sont pas présentes par défaut dans React (comme les stores ou l’ajout de classes conditionnelles sur un élément du dom facilement), ce qui est appréciable.
Ce n’est pas parfait notamment sur certains points techniques comme la déstructuration des props et ce genre de choses, mais je pense que la lib vaut le détour malgré tout.
Et merci pour ta vidéo, tu as mis des mots sur mon ressenti de VueJS par rapport aux autres frameworks. ❤
Super intéressant comme point de vue car contrairement à beaucoup de personnes qui s'expriment sur le sujet, on sent que tu as réellement essayé et expérimenté vueJS et d'autres frameworks !
J'adorerai voir une vidéo comparative (une vidéo par framework) ou on expose les forces et faiblesse du framework pour une app real world simple (exemple: une app gestion de contacts avec les opérations CRUD, la validation des forms, l'internationalisation, ...)
Les frameworks sont des outils mais on défend souvent notre opinion de manière subjective et biaisée.
Je trouve que sur ce sujet glissant, la vidéo est intéressante et bien faite car c'est argumenté et plustot objectif ! Merci pour le contenu :)
Si je résume, ce sont avant tout des détails ce qui montre que React et Vue sont tous les deux des bons choix.
Les défauts de Vue :
- moins adopté que React
- les dernières versions rajoutent une complexité, Vue s'éloigne de ses qualités originales qui sont d'être developer-friendly
Et Vue devient moins friendly, autant passer sur React quitte à se prendre la tête 😂 ça fait sens !
Néanmoins ça ne disqualifie pas Vue selon moi car reste bien plus simple que React, on est pas obligé d'utiliser les nouvelles fonctionnalités !
Conduit à un code bien plus maintenable, bien plus facile d'onboarder des juniors...
Bon je dis ça mais j'utilise React à cause du point 1 😂
Merci pour ton analyse. Peux tu faire la meme avec angular. Se que tu lui repproche ou pas par rapport à React
J'ai un peu le même ressenti. Au final pour le moment à choisir, je préfère Svelte. Mais pareil, je tourne beaucoup d'années en années et le choix des frameworks / librairies front ou back m'importe beaucoup moins que les pratiques et architectures en place. Etant plus back que front, de toute façon React, Vue ou Svelte c'est kif kif. De manière générale je tends vers le moins verbeux j'ai l'impression.
Je suis Full Stack, l’écosystème Frontend est aujourd'hui dans beaucoup de situation expérimental.
Les Primer Adopters ne sont pas les grands groupes, tout du moins tant qu'ils ne sponsorisent pas la dite technologie, et encore...
Quand au choix, je suis comme toi, la verbosité, je veux du concis que l'on comprend sans artifice problématique comme les refs dans vue.
C'est fou, mais en fait, c'est réglable en ajoutant une couche de Strategy Design / Interface, c'est fou, hein ?
Je te rejoins sur la complexification de Vue, mais c'est pourquoi je continue d'utiliser l'API options. En effet, les devs ont indiqué que celle-ci est facile à maintenir et ne sera donc pas dépréciée de sitôt.
Quant à Svelte, je suis tellement impressionné par l'efficacité de leurs choix jusqu'ici que j'ai beaucoup d'espoir que ça continue dans la bonne direction, mais évidemment, c'est pas garanti.
Sympa, je partage pas mal ton avis, au début je pensais que la composition API serait bien, mais j'ai l'impression que c'est de plus en plus compliqué. Et j'aimerais pas Angular et je commence à le préférer juste parce qu'il a Typescript obligatoire et que je suis sûr d'avoir aucun problème de typage.
Tu peux tout à fait utiliser Vue3 avec typeScript dès l'initialisation du projet.
Quant à la compo c'est dommage car c'est la meilleure chose qui existe en comparaison à l'option qui est juste imbuvable. Rien de compliqué, la grande satisfaction est lorsque tu comprends que tes variables sont d'office réactives.
La décomposition des props dans l'exemple que prend Grafikart n'est clairement pas conseillé et n'apporte rien d'ailleurs. Comme je l'ai dit plus haut, le problème ici est de vouloir faire du React sur du Vue. Ca n'a littéralement aucun sens. Décomposer ses props n'a pas d'intérêt.
Quant au .value, tu t'y fais et il existe des plugins VsCode qui facilitent l'autocompletion.
@@MrJohAA Le problème c'est que ce n'est pas pensé Typescript, donc le typage est hasardeux comme en React.
Oui la syntaxe est meilleure mais je trouve l'approche svelte mieux car c'est verbeux d'accéder à l'état.
@@rawz06Je comprends. Je trouve également qu'Angular propose une réelle structure de projet.
En revanche Ts est un langage de typage qui vient en surcouche d'un autre langage.
Partir sur du Angular juste parce qu'il supporte nativement Ts n'est pas si pertinent au fond sachant qu'à l'heure actuelle Angular a perdu en popularité et est surtout utilisé par les grosses entreprises type ESN. La courbe d'apprentissage reste raide. Il n'en reste pas moins un choix de framework intéressant.
Tout dépendra de l'affinité que tu as avec le framework. Si tu aimes faire du TS et qu'utiliser des classes javascript te plait dans ce cas Angular me parait être un bon choix. Quant à svelte je trouve que c'est un paris risqué pour l'instant.
Pour le state il y a Pinia qui fait largement l'affaire. Finis les mapGetters et autres.
Mais bon, mon avis n'est peut être pas si objectif que ça 😁
Merci ! Je suis plutôt d'accord avec tes points mais pour moi de mon experience le principal est la complexité de l'écosystème vue de nos jours.
En 2016-2018 tout était encore rose, une seule version vue2 et tout roulait maintenant entre vue2, vue 2.7 et vue3 avec donc certains module de la communauté compatible , d'autres non mais pas forcément indiqué comme tel.
Les migrations sont complexes , parfois impossible, le liens entre typescript et vue2/vue3 et les IDE (volart) pas forcément facile ou 100% fonctionnels.
Le temps qu'a mis vu a passé officiellement la 3 par default et la doc qui a changé plusieurs en par défaut sur vue3 puis re-vue2 .. 😖
Serait-il possible d’avoir ton extension pour mettre en valeur les blocs ? etc de couleurs différentes stp ? :)
J'utilise Vue et React depuis quelques années. Pour Vue, je te rejoins totalement sur la perte de réactivité lors d'une déstructuration d'une ref/reactive, c'est agaçant, MAIS rapidement maîtrisable. Les autres points énumérés me paraissent très peu impactant. Je préfère aujourd'hui encore Vue à React. La maintenance sur les projets avec par exemple la gestion du store (très pratique avec Vue Composition API) me parait plus simple que React avec Redux où le côté synchrone est un peu gênant. En soit, il est juste question de préférence. React et Vue restent top ;)
Pour ton problème au niveau IDE. Ce n'est pas plus "simple" de passer par une extension ?
C'est justement le propos de la vidéo : Utiliser des outils tiers qui ne sont pas forcément à jour car manque de popularité et que même si tu installes l'extension tiers, tu n'es pas à l'abri de la latence d'implémentation du tiers.
Tout à fait d'accord avec API composition, personnellement je le trouve absurde je kiff la logique en option API qui est simple et qui est commune à tous projets inferieur à vue 3, ne pas utiliser l'option api c'est ce tirer une balle dans le pieds dés le départ, sauf si vous aimez vous faire mal au crane
Petite astuce pour différencier les références des autres variables / props, toujours les préfixer par "Ref". Exemple : maVariableRef.
Cette logique peut aussi être appliquée au computed. En utilisant le participe passé (en anglais) ou un verbe comme tu l'as fait pour le "isPair".
On pourrait donc avoir des variables computed comme : isPair, isLoading, disabled, hasRoles etc...
Avec ce nommage on remarque d'un coup d'oeil à quoi correspond la variable.
Édit : suffixer
suffixer du coup
@@IStMl oui, my bad
Et Angular moderne tu as essayé ? Qu'est ce qu'il faut faire pour que tu fasses des tutos dessus ? Vendre son corps ?!?
On dirait que ya un boycott inconscient d'aNgular
Mon cauchemar avec react c'est la communication enfants père qui est trop chiant
Bonjour Grafikart as tu deja essayer livewire 3 peut etre tu peux nous faire un tuto dessus sa ressemble grave a react
Livewire 3 est plutôt inspiré de Vue d'apres ses devs
Livewire s'inspire de VueJs
Je me forme actuellement à Vue aussi et je comprends assez bien tes pain points, particulièrement sur le prop destructuring. Bon à savoir, il est déjà possible depuis la 3.3 de déstructurer ses props en rajoutant une ligne sur la config, comme pour le defineModel. Ce sera probablement disponible sans changer la config dans le futur
Je comprends ton avis sur Vue.Js mais est-ce que ton cours est toujours d'actualité ?
Tout ça a l'air si éphémère... Dans 5 ans il faudra tout changer de nouveau. C'est une industrie immature.
Est ce qu il y aura un framework qui répondrait à tout ?Non bien entendu ,apprenons donc continuellement et apprécier selon vos goût voilà ce qu il faut retenir avec tout ces outils
Salut Grafikart tu pense de next js, et va tu faire une vidéo sur ce framework.
Trop mignonne l'illustration en arrière plan des slides avec le logo de Vue.JS avec les ombres et tout.
C'est fait avec Blender ?
Cinema4D
je préfère clairement react avec les hooks je trouve ça plutôt simple à comprendre (je fais du react native donc pas le choix aussi)
Purée je suis exactement dans le même cas que toi !
Pour ne pas se mélanger les pinceaux avec le ".value"
On peut utiliser "unref", une méthode propre à l'API Reactive de VueJS.
Ce qui permet d'utiliser la variable directement.
Ca ça ne résoud pas vraiment le problème car il faut rajouter cette méthode sur chaque utilisation de variable au cas où ça soit une ref si on veut garantir de ne pas faire d'étourderie.
Dans ce cas tu perds la reactivité derriere
@@skybluFr Pas du tout.
Unref permet d'afficher la valeur de la variable, qu'elle soit réactive ou pas.
Mais on continue de garder la réactivité de la variable originale.
Exemple : if(unref(myValue) === "VueJS"){}
N'empêche en rien de continuer à faire myValue.value = "ReactJS"
@@auredud461 Oui ça ne résout pas intégralement le problème.
Mais cela a le mérite d'éviter d'utiliser ".value" partout.
En plus, cela permet de garder la réactivité et cela affiche la valeur de la variable, qu'elle soit réactive ou non.
@@thehikarilab Alors ... oui mais qui va ajouter cette surcouchr juste pout avoir accès a une valeur ?
Je pensais que tu disais : const maValeur = unref(autreRef)
Dans vue Tu peux tout a fait importer un composant et le stocker dans une variable comme tu l’as fait dans le tableau d’objets en react
Je m'attendais à ce que tu parles de Preact lorsque tu as mentionné Svelte
9 mois après, une formation Vue.js 😅
Merci Grafikart. 🎉 Tu m'as donné envie de me tourner vers Vue.js. 😊
Je dirai tout de même que Vue est "mieux" que React dans la majorité des cas... plus pragmatique et plus complet OOTB. Pas essayé Svelte mais Vue / React ne m'ont pas posé suffisamment problème pour que j'ai envie de m'intéresser à YAJSF.
Je suis arrivé à peu près au même constat. C'est la raison pour laquelle, je préfère largement Svelte (et il n'y a pas photo).
Perso j'ai arrêté VueJs, car j'en ai un peu marre qu'ils changent d'approche tous les 18 mois et que toutes les librairies derrières peine à suivre leurs approches. Je trouve la composition API super flexible et extensible, mais je trouve presque un peu trop compliqué pour en tirer profit. Je trouve un peu moyen ton argument concernant l'extension, ca n'a rien à voir avec le fait que ce soit une extension inconnue, mais au fait que react est plus populaire et que les outils la comprennent plus facilement. J'aurais même tendance à dire que les outils peuvent plus facilement comprendre les fichiers vue que react, c'est mieux séparé entre logique et html
C'est bien VUE, sans être REACT les arguments pourrait s'appliquer à celui-ci, je préfére rester SVELTE pour réduire la charge mental, ou à la limite HTMX, le "html" à la Elon Musk , d'ailleur celui-ci pourrait le racheter le 1 avril 2024 pour l'intégrer à X 🙂🙂🙂.
😆🤣🤣🤣😂 t'as vanillé ma journée 😋
J'ai toujours trouvé que VueJs est une mauvaise évolution anachronique d'AngularJs. Soit ça n'apporte pas grand chose de plus que l'ancienne librairie soit ca apporte bien plus de complication que les concurrents modernes. Il est aujourd'hui tellement simple que créer un front dissocié du back que je peine à trouver des cas d'usage non-marginaux a de telle technologie. Personnellement j'oscille selon les besoins entre React, Angular et le Js native. Je ne ferme pas la porte à de la concurrence (je garde par exemple un oeil attentif sur SolidJs) mais je doute que mes choix futurs aillent dans la direction de VueJs.
Si vous pouvez faire une playliste de tuto sur django ?
Je ne fais pas de python :(
Perso j'adore Svelte même si le premier point se retrouve aussi dans svelte avec les .svelte
Mon historique est vraiment très similaire au tient, je partage complètement ton point de vue et j'ai arrêté de l'utiliser à partir de la v3 avec l'apparition des ref qui complique énormément les choses. J'ai pourtant adoré la v1 et la v2, super dommage ...
C'est à ce moment là que j'ai décidé de me tourner vers React et de partir sur une nouvelle mission. Aujourd'hui je ne regrette absolument pas mon choix 😇
Moi j'ai choisi sveltekit et svelte car il ce framework nous donne envie de jouer avec le code et ca vitesse réactivité
Mouif enfin, quitter Vue pour aller sur du React c'est un peu comme quitter un étron pour prendre une bouse. Pour du travail propre, Angular reste la valeur sûre.
J'avoue ne pas avoir compris l'intérêt de la composition API, perso j'utilise l'option API qui est top et j'arrive a faire ce que je veux sur tous mes projets
Maintenant les développeurs react sont allés vers Next.js hhhh par rapport à l'optimisation di référencement la simplicité des routes l'optimisation des images et encore possibilité de faire rendu serveur et rendu client.
Ça ne s'arrête pas l'évolution du développement web mdr
ça me fait trop rire le disclaimer pour éviter d'utiliser cette vidéo "contre" Vue.js, d'habitude c'est plutôt les youtubeurs qui ont des petites embrouilles avec d'autres "influenceurs" qui font une vidéo en mode "n'allez pas le troller, ou l'insulter sur ses lives, on a fait la paix" ;D
C’est marrant je vient de voir une vidéo similaire mais pour React au profit de Vue. Comme quoi tout est question de point de Vue 😶🌫️
Clairement et c'est pour ça qu'il faut des outils avec des visions différentes (plus d'outils, plus de choix) !
intéressant. tu aurais le lien de cette vidéo ?
Même moi, j'ai commencé à passer à React Js
Lol moi qui viens de me faire tenter par vue js quand je fais mes analyses avec react j ai fini par aimé Vue js
NodeJS 💖
Je souffre actuellement de ces problemes de VueJS XD
idem
Svelte > All
La version 5 de svelte s’approche énormément de la composition api de vue 3 sans tout ces défauts tu devrais y jeter un œil
Oui, tous les frameworks empruntent les meilleurs idées des autres
Je bookmark la video... J'allais apprendre vue maintenant qu'apple a open source l'infra de doc (swift + vuejs)
La vidéo est une opinion perso, il ne faut pas que cela j'arrête si VueJS t'intérèsse.
Vue reste bien meilleur en termes de learning curve que React. Meme chose pour Svelte.
It was said that you would destroy the Sith, not join them ! 😭
Franchement tes freins sont chelou.
javascript est finito de toute facon, vive rust
Prems
Ça ne sert à rien mais c'est la première fois que je peux écrire ce commentaire 😂
Ohh je ne verrais donc pas de formation sur vue 3 sur le cursus 😢 j'irais sur REACT alors
Justement, c'est pas pcq il ne fait plus rien sur cette techno que tu dois l'arrêter. Si tu aimes travailler avec Vue c'est pas pcq Grafikart arrête de suivre cette techno que tu dois l'arrêter comme il a dit
C'est stupide car y a toujours moyen d'apprendre en dehors de Grafikart (malgré que j'avoue, avoir du contenu français et de qualité fait la différence)@@nicolaslachise4187