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.
Le gros problème de React selon moi, c'est la performance, car il faut toujours penser : Est-ce que je dois utiliser useMemo, memo(), useCallback, ou rien... sur un petit projet, pas de vrai souci, mais sur des projets conséquent, ça devient un vrai problème. Le fait que React recharge constamment tout les composants à chaque changement est difficile à gérer.
@loich7713, react 19 est maintenant sortie et d'après ce que j'ai vu, il n'arrange pas ces problèmes et ajoute encore de la complexité avec toujours plus de hooks...
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 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 ^^
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.
@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
@@jonathanrosado5818 C'est déjà bien en effet, mais un pandaCSS par exemple ajoute tellement plus et résoud quasiment tous les autres problèmes. Mais en soit oui c'est déjà bien. Perso le gros gros problème que j'ai avec Vue, et il en parle dans la vidéo, c'est de pouvoir avoir des petits composants "privés". Tu as la fonction h(), mais c'est litérallement quasiment un autre langage, et c'est pas très user friendly. Y'a le JSX certes, mais bon c'est pas l'idéal d'avoir un mélange SFC et JSX
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 ??
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 :)
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 :)
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.
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)
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.
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 ^^
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 😂
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.
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. ❤
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
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'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 ?
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 😁
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.
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 ;)
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 😇
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
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 🙂🙂🙂.
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
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
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)
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
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.
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'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.
ç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
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
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
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
![Lp. Сердце Вселенной #60 РОЖДЕНИЕ ЛОЛОЛОШКИ [Финал] • Майнкрафт](http://i.ytimg.com/vi/YoR0pAV9FVQ/mqdefault.jpg)
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.
Le gros problème de React selon moi, c'est la performance, car il faut toujours penser : Est-ce que je dois utiliser useMemo, memo(), useCallback, ou rien... sur un petit projet, pas de vrai souci, mais sur des projets conséquent, ça devient un vrai problème. Le fait que React recharge constamment tout les composants à chaque changement est difficile à gérer.
React 19 en stable arrive sous peu et va palier à ces soucis
@loich7713, react 19 est maintenant sortie et d'après ce que j'ai vu, il n'arrange pas ces problèmes et ajoute encore de la complexité avec toujours plus de hooks...
Super intéressant.
hâte de voir la suite des technos délaissées ... 🙃
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().
Concept et vidéo très intéressants. C'est très bien d'avoir décrit les cas d'usages avec des exemples.
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 !
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.
@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
@@jonathanrosado5818 C'est déjà bien en effet, mais un pandaCSS par exemple ajoute tellement plus et résoud quasiment tous les autres problèmes. Mais en soit oui c'est déjà bien.
Perso le gros gros problème que j'ai avec Vue, et il en parle dans la vidéo, c'est de pouvoir avoir des petits composants "privés". Tu as la fonction h(), mais c'est litérallement quasiment un autre langage, et c'est pas très user friendly. Y'a le JSX certes, mais bon c'est pas l'idéal d'avoir un mélange SFC et JSX
Bonjour ! Je me demande souvent comment faites vous pour apprendre autant de langage et surtout comment parvenez-vous à les maîtriser aussi bien ?
Je suis tes cours depuis des années et j'ai développé énormément d'app web.
Tellement reconnaissant.
Ca fait du bien de voir des vidéos avec ce type de contenu :)
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 ?
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 :)
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.
Tout ça a l'air si éphémère... Dans 5 ans il faudra tout changer de nouveau. C'est une industrie immature.
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 :)
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.
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)
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.
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 ^^
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 😂
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.
Bonjour merci pour tes vidéos. As-tu changé d'avis depuis ? J'ai vu que tu avais mis a disposition un tuto vuejs 3 qui date de quelques mois.
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. ❤
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
Merci pour ton analyse. Peux tu faire la meme avec angular. Se que tu lui repproche ou pas par rapport à React
Très bonne idée cette thématique de vidéo.
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'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 ?
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 😁
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.
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 ;)
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
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 😇
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
Salut Grafikart tu pense de next js, et va tu faire une vidéo sur ce framework.
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
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 😋
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 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. 😊
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
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
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)
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
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 comprends ton avis sur Vue.Js mais est-ce que ton cours est toujours d'actualité ?
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).
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.
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
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.
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 ?
Je suis d'accord avec tout ce que tu dis sur Vue3. C'est pour cela que j'utilise Angular 😉
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 !
Si vous pouvez faire une playliste de tuto sur django ?
Je ne fais pas de python :(
ç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
Serait-il possible d’avoir ton extension pour mettre en valeur les blocs ? etc de couleurs différentes stp ? :)
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
Moi j'ai choisi sveltekit et svelte car il ce framework nous donne envie de jouer avec le code et ca vitesse réactivité
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
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
Perso j'adore Svelte même si le premier point se retrouve aussi dans svelte avec les .svelte
Même moi, j'ai commencé à passer à React Js
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.
Je souffre actuellement de ces problemes de VueJS XD
idem
NodeJS 💖
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
It was said that you would destroy the Sith, not join them ! 😭
Svelte > All
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