Le 22 novembre 2019 à 09:59:16 NurseryRhyme a écrit :
Arrêtez de conseiller aux gens de sortir Angular pour une micro-webapp de 5 pages, c'est a cause des gens comme vous que les sites sont bloated a mort.

Y'a des librairies légères pour la navigation coté client, genre sammyjs et ca sera amplement suffisant.

Il est en stage c'est le moment de se former pour la suite, Angular est un framework front très demandé en entreprise alors que SammyJs première fois j'en entends parlé.

Le 22 novembre 2019 à 10:22:57 boucif a écrit :

Le 22 novembre 2019 à 09:59:16 NurseryRhyme a écrit :
Arrêtez de conseiller aux gens de sortir Angular pour une micro-webapp de 5 pages, c'est a cause des gens comme vous que les sites sont bloated a mort.

Y'a des librairies légères pour la navigation coté client, genre sammyjs et ca sera amplement suffisant.

Il est en stage c'est le moment de se former pour la suite, Angular est un framework front très demandé en entreprise alors que SammyJs première fois j'en entends parlé.

Apprendre a être concis et a pas surcharger ses pages c'est aussi important.

Et apprendre des technos qui l'amèneront à trouver du boulot c'est ?

Pour moi des framework comme sammyJS c'est pour des gens qui savent ce qu'ils font et qui cherchent l'optimisation quand on débute on apprend, il doit savoir utiliser des outils qui lui seront souvent demandé.

Certes, mais avant d'apprendre à utiliser un framework, c'est bien d'apprendre à savoir coder sans.

Je vois souvent des gens qui apprennent directement via un framework (qui au final fait BEAUCOUP de choses à la place du dev), mais quand ils sont dans un contexte où ils doivent coder un truc from scratch ils sont largués.

En plus les frameworks apportent tellement d'abstraction que certaines personnes qui les utilisent savent même pas les RFC ou comment fonctionne le web (genre j'ai eu des cas de gens qui savaient pas faire un formulaire POST sans Angular...)

Le 22 novembre 2019 à 10:22:02 UndeadMarston6 a écrit :

plus formateur de faire ça en VanillaJS / jQuery

Je suis à moitié d'accord :

• Faire ça en vanillaJS peut-être très formateur, oui mais aussi être un frein, découvrir toute les possibilités de JS avec un framework être une bonne première approche pour ensuite faire ça en VanillaJS
• jQuery par contre n'a aucun intérêt, techno dépassé et quasi plus utilisé, à oublier

Arrêtez de conseiller aux gens de sortir Angular pour une micro-webapp de 5 pages, c'est a cause des gens comme vous que les sites sont bloated a mort.

Le but ici c'est que l'auteur, qui est stagiaire, puisse se former sur des technos comme Angular, React ou VueJS qui donne du boulot ... sammyjs est surement un choix pertinent pour son cas mais son but principal serait pas plus la formation et la montée en compétence plus que de faire un site de 5 pages ?

Effectivement je te suis sur le frein mais s'il s'en sort il en saura que beaucoup plus formé pour attaquer ensuite les frameworks.
Quand j'ai mis jQuery j'ai pensé surtout aux appels Ajax qui vont lui simplifier la vie.
Je sous entendais pas d'apprendre jQuery comme l'auraient pu le faire les developpeur 5-6 années auparavant.

Le but ici c'est que l'auteur, qui est stagiaire, puisse se former sur des technos comme Angular, React ou VueJS qui donne du boulot ... sammyjs est surement un choix pertinent pour son cas mais son but principal serait pas plus la formation et la montée en compétence plus que de faire un site de 5 pages ?

Comprendre comment fonctionne le DOM, les requêtes asynchrones, manier les callbacks et que sais-je encore est pour moi beaucoup plus interessant que simplement mettre une techno à la mode sur son CV.
Et le soucis avec les frameworks c'est qu'ils t'aident vachement à ne plus te soucier de ça, d'où l'idée d'apprendre à faire une SPA en vanilla et de mettre les mains dans le cambouis avant de passer à Vue / React etc ...
Je suis persuadé que s'il apprend à la méthode " dure " à faire une SPA, la plus simple possible, passer sur un framework et monter en compétence sera un jeu d'enfant ou une simple formalité.

EDIT : j'avais pas vu ton post [Black_Spirit], on se rejoint du coup
Ca me fait penser aux devs qui veulent à tout pris apprendre Symfony ou Laravel car "c'est demandé" mais sans rien biter de comment fonctionne ces derniers.

Pourquoi il devrait apprendre la méthode 'dure', notre boulot c'est pas justement de simplifier la vie des gens, et nous même on cherche pas la simplicité et la rapidité, je fais du web depuis presque 10 ans et j'ai du utilisé 3 fois le XmlhttpRequest, surtout que beaucoup de vieux outils sont rapidement remplacé et ne seront peut être plus jamais utilisé.
Même le js sera remplacé, il existera toujours mais peut être à la marge.
Après à l'auteur de se décider.

Le 22 novembre 2019 à 14:27:20 boucif a écrit :
Pourquoi il devrait apprendre la méthode 'dure', notre boulot c'est pas justement de simplifier la vie des gens, et nous même on cherche pas la simplicité et la rapidité, je fais du web depuis presque 10 ans et j'ai du utilisé 3 fois le XmlhttpRequest, surtout que beaucoup de vieux outils sont rapidement remplacé et ne seront peut être plus jamais utilisé.
Même le js sera remplacé, il existera toujours mais peut être à la marge.
Après à l'auteur de se décider.

J'ai pas dit qu'il devait utiliser XmlhttpRequest toute sa vie, mais apprendre à le faire est beaucoup plus sain je pense que d'avoir un truc tout fait près à l'emploi. Reste à savoir combien de temps va-t-il mettre pour ensuite plonger dans les frameworks.
Tu parles en tant que dev confirmé et c'est normal que tu va faire appel à des frameworks, lui il veut apprendre c'est pas la même approche qu'il faut avoir je pense.

Le 22 novembre 2019 à 13:00:01 Marav a écrit :

Le 22 novembre 2019 à 10:22:02 UndeadMarston6 a écrit :

plus formateur de faire ça en VanillaJS / jQuery

Je suis à moitié d'accord :

• Faire ça en vanillaJS peut-être très formateur, oui mais aussi être un frein, découvrir toute les possibilités de JS avec un framework être une bonne première approche pour ensuite faire ça en VanillaJS
• jQuery par contre n'a aucun intérêt, techno dépassé et quasi plus utilisé, à oublier

Arrêtez de conseiller aux gens de sortir Angular pour une micro-webapp de 5 pages, c'est a cause des gens comme vous que les sites sont bloated a mort.

Le but ici c'est que l'auteur, qui est stagiaire, puisse se former sur des technos comme Angular, React ou VueJS qui donne du boulot ... sammyjs est surement un choix pertinent pour son cas mais son but principal serait pas plus la formation et la montée en compétence plus que de faire un site de 5 pages ?

Effectivement je te suis sur le frein mais s'il s'en sort il en saura que beaucoup plus formé pour attaquer ensuite les frameworks.
Quand j'ai mis jQuery j'ai pensé surtout aux appels Ajax qui vont lui simplifier la vie.
Je sous entendais pas d'apprendre jQuery comme l'auraient pu le faire les developpeur 5-6 années auparavant.

Le but ici c'est que l'auteur, qui est stagiaire, puisse se former sur des technos comme Angular, React ou VueJS qui donne du boulot ... sammyjs est surement un choix pertinent pour son cas mais son but principal serait pas plus la formation et la montée en compétence plus que de faire un site de 5 pages ?

Comprendre comment fonctionne le DOM, les requêtes asynchrones, manier les callbacks et que sais-je encore est pour moi beaucoup plus interessant que simplement mettre une techno à la mode sur son CV.
Et le soucis avec les frameworks c'est qu'ils t'aident vachement à ne plus te soucier de ça, d'où l'idée d'apprendre à faire une SPA en vanilla et de mettre les mains dans le cambouis avant de passer à Vue / React etc ...
Je suis persuadé que s'il apprend à la méthode " dure " à faire une SPA, la plus simple possible, passer sur un framework et monter en compétence sera un jeu d'enfant ou une simple formalité.

EDIT : j'avais pas vu ton post [Black_Spirit], on se rejoint du coup
Ca me fait penser aux devs qui veulent à tout pris apprendre Symfony ou Laravel car "c'est demandé" mais sans rien biter de comment fonctionne ces derniers.

à vraie dire, je ne comprends pas.

Si tu veux comprendre ce que tu fais, et le principe, au final, du système de serveur http, fait du c, pas du js.
En codant en JS tu as déjà une surcouche monstrueuse, tu ne comprends absolument pas ce qu'il se passe réellement, c'est juste une syntaxe plus simple, et beaucoup moins lourde (en terme de code) puisque justement, tu utilise la façon de coder JS natif.

Je ne comprends donc pas en quoi il serait important de connaître la façon de coder JS natif plus que celle d'un framework.
Ok, tu ne sauras pas utiliser l'une des surcouches JS natif, mais si ça t'es pas util, où est le problème ?

Je veux vraiment mettre l'accent sur le fait que de coder en JS natif, ce n'est ABSOLUMENT PAS comprendre le système de browser/serveur http, loin de là, très loin de là.

Donc quitte à apprendre une façon de coder (donc une surcouche) pourquoi passer par une façon de coder "obsolète", quand tu n'en a pas la contrainte ?

C'est pas une question de juste comprendre comment marche un navigateur en bas niveau, c'est une question de savoir concevoir des applications.
Les frameworks c'est cool pour faire des trucs hyper génériques. Mais dès qu'il s'agit de faire qqchose de plus personnalisé, il faut parfois s'en passer. D'où le fait de savoir coder sans.

Effectivement je te suis sur le frein mais s'il s'en sort il en saura que beaucoup plus formé pour attaquer ensuite les frameworks.

Quand j'ai mis jQuery j'ai pensé surtout aux appels Ajax qui vont lui simplifier la vie.
Je sous entendais pas d'apprendre jQuery comme l'auraient pu le faire les developpeur 5-6 années auparavant.

Ah ok oui pour l'Ajax prendre une librairie comme Axios sera quand même plus intéressant que charger tout jQuery sur son site pour ça.

Comprendre comment fonctionne le DOM, les requêtes asynchrones, manier les callbacks et que sais-je encore est pour moi beaucoup plus interessant que simplement mettre une techno à la mode sur son CV.

Et le soucis avec les frameworks c'est qu'ils t'aident vachement à ne plus te soucier de ça, d'où l'idée d'apprendre à faire une SPA en vanilla et de mettre les mains dans le cambouis avant de passer à Vue / React etc ...
Je suis persuadé que s'il apprend à la méthode " dure " à faire une SPA, la plus simple possible, passer sur un framework et monter en compétence sera un jeu d'enfant ou une simple formalité.

ça je suis d'accord mais apprendre un framework te dispense pas de tout ça, avec Vue :

• Des requêtes Asynchrones sur des API c'est monnaie courante, surtout à notre époque
• Une importance primordiale au Promise et au fonction Async, impossible de faire une SPA (avec un framework ou pas sans ses connaissances)

Vue est une facilité, certes mais cette facilité ne peut pas être utilisé correctement sans utiliser les fonctionnalités de JavaScript car Vue avant d'être une framework c'est du JS.
Comme beaucoup de dev Symfony se préoccupe plus de Symfony que du PHP, dommage car PHP a énormément de fonctionnalité avant même Symfony.

C'est vrai que je pense tout l'inverse personnellement, apprendre sur un framework est une bonne chose pour te montrer les possibilités du langages, les choses possibles et puis une fois qu'on a connaissance de tout ça essayer de le faire toi même.
Je sais que personnellement c'est grâce à Vue que j'ai pu mettre autant la main dans le cambouis et que je visualise mieux les possibilités du JS et que grâce à ça je pourrai me dire "Faisons ça en vanillaJS, je vois ce que je cherche à faire et comment je peux le faire"

Les frameworks c'est cool pour faire des trucs hyper génériques. Mais dès qu'il s'agit de faire qqchose de plus personnalisé, il faut parfois s'en passer. D'où le fait de savoir coder sans.

????? Dis moi ce que tu ne peux pas faire avec un framework ? Surtout VueJS (je ne connais que celui là) je vois pas ce que tu ne peux pas faire avec que tu pourrai faire en VanillaJS

J'ai jamais dit qu'on pouvait pas, on peut tjs. Tu peux même faire en assembleur si tu veux ...

Mais y a des cas où ça rajoute plus de complexité qu'autre chose. Parfois on a mieux fait de faire à sa manière plutôt qu'en fonction de la structure imposée par le framework. VueJS je connais pas mais typiquement, des frameworks comme Angular ou emberJS ça t'impose une manière de faire

Le 22 novembre 2019 à 16:56:58 [Black_Spirit] a écrit :
C'est pas une question de juste comprendre comment marche un navigateur en bas niveau, c'est une question de savoir concevoir des applications.
Les frameworks c'est cool pour faire des trucs hyper génériques. Mais dès qu'il s'agit de faire qqchose de plus personnalisé, il faut parfois s'en passer. D'où le fait de savoir coder sans.

Pas vraiment, surtout sur des frameworks de front. React par exemple, ça reste du JSX, soit de l'HTML avec variables. Si tu veux faire quelque chose de complètement personnalisé, tu peux tout autant que si t'étais en JS natif, ce sera juste plus facile et plus structuré.

Autrement dit, en React, tu n'auras littéralement jamais à faire du JS natif, peu importe ce que tu souhaites faire.
D'ailleurs, les personnes contre les frameworks ont à prioris tendance à oublier un petit détail : Un framework n'est rien de plus qu'une librairie+ de son langage natif. Tu peux donc par définition faire AU MOINS tout ce que le langage natif fait, et ce, par définition.

Et pour "les cas où c'est plus compliqué" j'aimerais beaucoup un exemple pour appuyer ce que tu dis dans le contexte d'un framework Frontend.

React EST une librairie en même temps. Pas un framework. Donc ton exemple et pas vraiment en lien avec ce que je disais.

J'ai pas l'impression que t'ai déjà essayé des usines à gaz type EmberJS pour me dire qu'un framework c'est juste une librairie ...

Le 25 novembre 2019 à 16:28:14 [Black_Spirit] a écrit :
React EST une librairie en même temps. Pas un framework. Donc ton exemple et pas vraiment en lien avec ce que je disais.

Non. Il y a débat là dessus, mais non, React EST un framework.

Qu'est ce qu'un framework

En programmation informatique, un framework (appelé aussi infrastructure logicielle1, socle d'applications2, infrastructure de développement3, ou cadre d'applications4 au Canada) désigne un ensemble cohérent de composants logiciels structurels, qui sert à créer les fondations ainsi que les grandes lignes de tout ou d’une partie d'un logiciel (architecture). Un framework se distingue d'une simple bibliothèque logicielle principalement par :
son caractère générique, faiblement spécialisé, contrairement à certaines bibliothèques ; un framework peut à ce titre être constitué de plusieurs bibliothèques, chacune spécialisée dans un domaine. Un framework peut néanmoins être spécialisé, sur un langage particulier, une plateforme spécifique, un domaine particulier : communication de données, data mapping, etc. ;
le cadre de travail qu'il impose de par sa construction même, guidant l'architecture logicielle voire conduisant le développeur à respecter certains patrons de conception ; les bibliothèques le constituant sont alors organisées selon le même paradigme.

Dixit Wikipedia.

Qu'est ce qui differencie un framework d'une librairie, donc ? Un framework est une façon de coder. Un framework te force à coder d'une certaine façon. C'est le cas de React.

Un framework est une librairie, mais toutes les librairies ne sont pas des frameworks. Autrement dit tu es totalement dans le faux quand tu dis que React n'est pas un framework.

Et c'est quoi cet argument cassé ? Parce qu'un framework est mauvais, alors ils le sont tous ?
Et tu pense quoi quand tu dis qu'un framework n'est pas qu'une librairie ? Qu'il est son propre langage ?

Enfin bref. Je pense honnêtement que tu essaie d'abord de te convaincre toi-même de ce que tu dis, alors qu'à priori le monde est contre ton avis.

Comme je l'ai déjà dis, si un framework était inutile, alors personne ne s'en servirait.

C’est vraiment un débat sans fin.

Après de mon avis pour en faire depuis presque 10 ans le js pur à l’ancienne (es5 je crois) avec les anciennes méthodes et les problèmes de compatibilité navigateur c’est de la grosse merde.
Si tu peux utiliser un framework moderne te permettant de t’abstenir de faire du vanillajs à l’ancienne fonce 🤣
Encore que maintenant avec l’ES6 ça va mieux même si je préfère Typescript.

Le 25 novembre 2019 à 20:23:31 Raidden36 a écrit :

Le 25 novembre 2019 à 16:28:14 [Black_Spirit] a écrit :
React EST une librairie en même temps. Pas un framework. Donc ton exemple et pas vraiment en lien avec ce que je disais.

Non. Il y a débat là dessus, mais non, React EST un framework.

Qu'est ce qu'un framework

En programmation informatique, un framework (appelé aussi infrastructure logicielle1, socle d'applications2, infrastructure de développement3, ou cadre d'applications4 au Canada) désigne un ensemble cohérent de composants logiciels structurels, qui sert à créer les fondations ainsi que les grandes lignes de tout ou d’une partie d'un logiciel (architecture). Un framework se distingue d'une simple bibliothèque logicielle principalement par :
son caractère générique, faiblement spécialisé, contrairement à certaines bibliothèques ; un framework peut à ce titre être constitué de plusieurs bibliothèques, chacune spécialisée dans un domaine. Un framework peut néanmoins être spécialisé, sur un langage particulier, une plateforme spécifique, un domaine particulier : communication de données, data mapping, etc. ;
le cadre de travail qu'il impose de par sa construction même, guidant l'architecture logicielle voire conduisant le développeur à respecter certains patrons de conception ; les bibliothèques le constituant sont alors organisées selon le même paradigme.

Dixit Wikipedia.

Qu'est ce qui differencie un framework d'une librairie, donc ? Un framework est une façon de coder. Un framework te force à coder d'une certaine façon. C'est le cas de React.

Un framework est une librairie, mais toutes les librairies ne sont pas des frameworks. Autrement dit tu es totalement dans le faux quand tu dis que React n'est pas un framework.

Et c'est quoi cet argument cassé ? Parce qu'un framework est mauvais, alors ils le sont tous ?
Et tu pense quoi quand tu dis qu'un framework n'est pas qu'une librairie ? Qu'il est son propre langage ?

Enfin bref. Je pense honnêtement que tu essaie d'abord de te convaincre toi-même de ce que tu dis, alors qu'à priori le monde est contre ton avis.

Comme je l'ai déjà dis, si un framework était inutile, alors personne ne s'en servirait.

J'ai jamais dit que c'était inutile, y a des Uses Cases adaptés pour, d'autres moins, c'est tout.

Si le framework c'était la solution miracle, y en aurait qu'un qui fait tout pour toi et ça serait magique, la réalité c'est que c'est pas le cas. ça a rien de ouf de dire que parfois on est plus productif sans, je vois pas pourquoi tu t’obstines à pas vouloir comprendre ça. A croire que c'est toi qui essaie de te rassurer de pas savoir coder sans (je me permet de faire cette remarque car c'est toi qui a le culot de chercher à me décrédibiliser avec tes remarques déplacées).

Et va sur le site officiel de ReactJS, tu verras qu'ils se considèrent eux même comme une librairie et non un framework, tout simplement car ReactJS c'est juste le V de MVC là où de gros framework comme Django font le MVC complet (et "t'obliges" à utiliser leur structure de projet).

Mais bon, par exemple dans une archi Cloud avec containers, micro services et un orchestrateur (kubernetes), tu vas pas utiliser Django ...

Le 25 novembre 2019 à 21:28:00 [Black_Spirit] a écrit :

Le 25 novembre 2019 à 20:23:31 Raidden36 a écrit :

Le 25 novembre 2019 à 16:28:14 [Black_Spirit] a écrit :
React EST une librairie en même temps. Pas un framework. Donc ton exemple et pas vraiment en lien avec ce que je disais.

Non. Il y a débat là dessus, mais non, React EST un framework.

Qu'est ce qu'un framework

En programmation informatique, un framework (appelé aussi infrastructure logicielle1, socle d'applications2, infrastructure de développement3, ou cadre d'applications4 au Canada) désigne un ensemble cohérent de composants logiciels structurels, qui sert à créer les fondations ainsi que les grandes lignes de tout ou d’une partie d'un logiciel (architecture). Un framework se distingue d'une simple bibliothèque logicielle principalement par :
son caractère générique, faiblement spécialisé, contrairement à certaines bibliothèques ; un framework peut à ce titre être constitué de plusieurs bibliothèques, chacune spécialisée dans un domaine. Un framework peut néanmoins être spécialisé, sur un langage particulier, une plateforme spécifique, un domaine particulier : communication de données, data mapping, etc. ;
le cadre de travail qu'il impose de par sa construction même, guidant l'architecture logicielle voire conduisant le développeur à respecter certains patrons de conception ; les bibliothèques le constituant sont alors organisées selon le même paradigme.

Dixit Wikipedia.

Qu'est ce qui differencie un framework d'une librairie, donc ? Un framework est une façon de coder. Un framework te force à coder d'une certaine façon. C'est le cas de React.

Un framework est une librairie, mais toutes les librairies ne sont pas des frameworks. Autrement dit tu es totalement dans le faux quand tu dis que React n'est pas un framework.

Et c'est quoi cet argument cassé ? Parce qu'un framework est mauvais, alors ils le sont tous ?
Et tu pense quoi quand tu dis qu'un framework n'est pas qu'une librairie ? Qu'il est son propre langage ?

Enfin bref. Je pense honnêtement que tu essaie d'abord de te convaincre toi-même de ce que tu dis, alors qu'à priori le monde est contre ton avis.

Comme je l'ai déjà dis, si un framework était inutile, alors personne ne s'en servirait.

J'ai jamais dit que c'était inutile, y a des Uses Cases adaptés pour, d'autres moins, c'est tout.

Si le framework c'était la solution miracle, y en aurait qu'un qui fait tout pour toi et ça serait magique, la réalité c'est que c'est pas le cas. ça a rien de ouf de dire que parfois on est plus productif sans, je vois pas pourquoi tu t’obstines à pas vouloir comprendre ça. A croire que c'est toi qui essaie de te rassurer de pas savoir coder sans (je me permet de faire cette remarque car c'est toi qui a le culot de chercher à me décrédibiliser avec tes remarques déplacées).

Et va sur le site officiel de ReactJS, tu verras qu'ils se considèrent eux même comme une librairie et non un framework, tout simplement car ReactJS c'est juste le V de MVC là où de gros framework comme Django font le MVC complet (et "t'obliges" à utiliser leur structure de projet).

Mais bon, par exemple dans une archi Cloud avec containers, micro services et un orchestrateur (kubernetes), tu vas pas utiliser Django ...

Bien sûr qu'ils l'appellent "librairie", c'est le terme exact. Framework c'est une appellation annexe que les gens donnent. Angular aussi c'est une librairie.

Tu n'as pas dis que les frameworks étaient inutile, tu as dis qu'ils étaient littéralement à fuir tellement ils étaient néfaste, retourne pas ta veste comme ça.

J'ai fais deux ans d'html php js natif. C'est à des années lumières d'un framework dans la réalité, et dans le monde professionnel. Maintenant tu m'as l'air de quelqu'un de buté, c'est inutile de discuter avec toi, tu te contentes d'éviter tous mes arguments et de démontrer une ignorance du sujet complète.

Tu n'as donc répondu à aucunes de mes questions, j'attends toujours des réponses, et des exemples.

1 - J'ai jamais dit "que les frameworks étaient inutile, tu as dis qu'ils étaient littéralement à fuir tellement ils étaient néfaste" et je le pense pas, donc arrête d'interpréter mes propos, merci

2 - J'ai donné des exemples en fait donc relis, et pour info t'as rien dit de pertinent, juste ton avis (donc subjectif).

3 - Si je suis borné t'es quoi ?

Et j'en reste là car ça mène à rien en effet.

Le 25 novembre 2019 à 21:45:58 [Black_Spirit] a écrit :
1 - J'ai jamais dit "que les frameworks étaient inutile, tu as dis qu'ils étaient littéralement à fuir tellement ils étaient néfaste" et je le pense pas, donc arrête d'interpréter mes propos, merci

2 - J'ai donné des exemples en fait donc relis, et pour info t'as rien dit de pertinent, juste ton avis (donc subjectif).

3 - Si je suis borné t'es quoi ?

Et j'en reste là car ça mène à rien en effet.

Pour le coup du "les frameworks sont à fuir" je t'ai confondu avec un mec sur le thread PHP, mea culpa.

J'ai relu, j'ai vu 0 exemples, va falloir me les citer parce que je les vois toujours pas.

Rien dit de pertinent ? Okay React n'est toujours pas un framework du coup, et c'est apprendre le JS via un framework est totallement inutile. Après tout on va juste oublier mes pavés, pourquoi pas.