Pour détailler un peu plus.

Si je pense qu'il vaut mieux apprendre à coder sans framework AVANT d'apprendre à en utiliser un (donc oui, j'ai jamais dit que j'étais contre les frameworks en fait), c'est que, malheureusement, les frameworks (surtout côté front) subissent de gros effets de mode, et celui utilisé actuellement le sera certainement pas dans 5 ans.

D'où l'intérêt de comprendre le web de manière plus générale (normes, RFC, etc.) plutôt que de le voir QUE à travers les yeux d'un framework, qui t'impose UNE vision. Et ça me semble pas ouf de dire que le web ne se limite pas à une manière de faire, c'est pas pour rien qu'ils existent pleins de frameworks différents.

Un des exemples que j'ai donné pour illustrer ça c'est le mec qui a appris directement le front via Angular mais sait pas comment fonctionne les balises de formulaires et comment est structurée une requête POST. S'il change de framework, va bien falloir qu'il comprenne un jour ce qu'il y a derrière. Du coup je trouve qu'apprendre directement un framework sans avoir les bases, c'est pas hyper pédagogique, car au final c'est pas de la connaissance pérenne.

Autre exemple, le cloud, Ça a pas de sens d’utiliser Django (full MVC) si t'as une archi avec microservices et un orchestrateur. Et du coup si t'as des microservices (donc des bouts d'applications très petits), est ce que ça a du sens d'utiliser un framework même côté front ? Y a pas que le backend qu'on peut diviser en microservices, tu peux aussi le faire avec le frontend. J'ai assisté à une démo sur les microservices une fois, et ils montraient comment diviser sa UI en pleins de microservices (donc chaque bouts de l'UI étaient autonomes, certains bouts codés en Java, d'autres en Python, etc.).

Ou pour revenir sur Django, ça me semble pas ouf de dire qu'un ORM ne permet pas d'optimiser ses requêtes et peut donc potentiellement provoquer des pertes de performances. Ce que je veux dire par là, c'est que même pour le front, tu peux avoir des contraintes qui t'imposes un certain seuil de performance, et donc devoir te passer d'utiliser certains frameworks, qui sont trop lourds et pas optimisés.

Tout ça pour dire que ça dépend de ton use case, et qu'avoir une vision globale du web et son fonctionnement permet d'y voir plus clair (plutôt que bloquer sa vision sur comment fonctionne UN framework).

Ce ne sont pas les exemples que je t'ai demander, mais soit.

Reprenons le type qui a apprit avec Angular. Cette personne a obligatoirement dû faire la base de tout apprentissage de langage de programmation : Lire de la doc. C'est la seule compétence nécessaire à maîtriser pour être capable de s'adapter à tous les langages. Voilà pourquoi je ne pense pas qu'il soit nécessaire de commencer par du JS pour apprendre à faire du React.
Pour en revenir à ce que je disais, ça aurait été du C/CPP, ok, il est préférable de commencer par le C, mais c'est uniquement parce que le CPP abstrait des notions qui ne le sont pas (le C) (et non, le C n'abstrait pas l'assembleur, il se contente de lui donner une plus jolie syntaxe, il fonctionne pareil, dans l'absolue). Hors, sur des langage de base très haut niveau, qui sont des abstractions d'abstractions, ça n'est pas utile puisque justement, retirer une couche ne servirait qu'à un découvrir une autre, donc aucune chances de faire planter le programme. Partir de ce principe, on n'apprend donc plus qu'une façon de coder, donc inutile d'en apprendre une qui ne correspond pas à ce qu'on veut.

Me concernant je ne dis pas non plus qu'il ne faut pas réfléchir dans le choix de sa techno, mais pour en revenir à l'origine du poste, l'OP voulait faire un front -> React/Angular propose des templates très jolie, codable donc en un rien de temps, et absolument pas surchargé -> React/Angular sont donc de très bonne technos pour l'OP. Et React/Angular ont tendance à de très bons choix de techno front assez souvent.

De mon expérience, j'ai vraiment apprécié apprendre à faire des sites web avec Angular.
La documentation est claire, ça apprends plein de bonnes pratiques, et même si le framework sera peut être plus la dans 10ans, la façon de coder des interfaces "façon angular" est bien là depuis 10ans et sera surement encore là pour 10ans donc c'est pas perdu.
En plus c'est maintenable, au lieu d'etre "un travail de stagiaire" c'est à dire que le jour ou ca marche plus on jette tout car c'est pas maintenable (en tout cas un site en vanillajs j'y touche même pas).

Et aussi, un projet commence toujours avec "5 page et deux div" et ça fini toujours en truc monstrueux avec un cahier des charges qui grossit plus vite qu'on code et on regrette vite le framework solide qu'on a pas voulu utiliser en premier lieu

Je n'ai jamais ete tres convaincu que l'endroit ou on commence a apprendre etait si important que ca.

Pour beaucoup de gens qui veulent apprendre, etre capable de produire rapidement un resultat au debut est critique parceque sinon ils abandonnent.

Donc dire qu'il faut commencer par le truc de base potentiellement va repousser beaucoup d'utilisateur potentiel: ils vont essayer un peu, et ils vont partir. Pour plein ca va marcher, mais dans le pire cas ils ont pas appris grand chose.

Alors que ceux qui commencent avec un systeme qui leur permet de resoudre un probleme rapidement se retrouvent souvent a devoir creuser pour resoudre des problemes plus complique plus tard. Dans le pire cas, ils ont appris un outils qui leur ait utile et ne creuse pas plus.

pour devenir un vrai expert, il n'y a pas de bon endroit ou commencer. Tu commence a un niveau d'abstraction/d'outil et en general, tu montes de quelques niveau, et tu descends quelques niveau dans ton apprentissage. Et quelque soit le niveau ou tu commences, tu finis par faire ca.

Le 27 novembre 2019 à 00:16:29 godrik a écrit :
Je n'ai jamais ete tres convaincu que l'endroit ou on commence a apprendre etait si important que ca.

Pour beaucoup de gens qui veulent apprendre, etre capable de produire rapidement un resultat au debut est critique parceque sinon ils abandonnent.

Donc dire qu'il faut commencer par le truc de base potentiellement va repousser beaucoup d'utilisateur potentiel: ils vont essayer un peu, et ils vont partir. Pour plein ca va marcher, mais dans le pire cas ils ont pas appris grand chose.

Alors que ceux qui commencent avec un systeme qui leur permet de resoudre un probleme rapidement se retrouvent souvent a devoir creuser pour resoudre des problemes plus complique plus tard. Dans le pire cas, ils ont appris un outils qui leur ait utile et ne creuse pas plus.

pour devenir un vrai expert, il n'y a pas de bon endroit ou commencer. Tu commence a un niveau d'abstraction/d'outil et en general, tu montes de quelques niveau, et tu descends quelques niveau dans ton apprentissage. Et quelque soit le niveau ou tu commences, tu finis par faire ca.

Je suis totalement d'accord avec tout ça

dark_drow: Entre Angular ou Vue, lequel des deux t'a paru plus accessible ? Un des deux est plus abordable que l'autre concernant la syntaxe ?

Le 27 novembre 2019 à 10:58:07 AsariTech a écrit :
dark_drow: Entre Angular ou Vue, lequel des deux t'a paru plus accessible ? Un des deux est plus abordable que l'autre concernant la syntaxe ?

Perso Vue semble plus accessible et se rapproche d'AngularJS niveau syntaxe, mais c'est un piège parce que de base Angular embarque 90% de ce qui est nécessaire pour faire une SPA, alors que sur Vue il faudra ajouter des modules, donc pas sur que ça soit plus rapide au finale.
Angular 2 mini est plus simple à appréhender qu'AngularJS au finale et t'es plus productif grâce a Typescript et AngularCli.

Intéressant, merci pour ces infos. D'ailleurs dans le cas d'une application monopage, est-il possible avec Angular de garder en mémoire certaines parties de la page comme des menus puis de charger le contenu qu'il faut en fonction de la requête utilisateur mais en changeant également l'adresse dès qu'on charge de nouvelles données ? Et prend-t-il bien en charge un support multilingue sans Backend derrière, donc avec le contenu dans des fichiers ?

Vue est quand même super cool avec les fichiers .vue qui permet d'avoir une archi de dev vraiment cool !

garder en mémoire certaines parties de la page comme des menus puis de charger le contenu qu'il faut en fonction de la requête utilisateur mais en changeant également l'adresse dès qu'on charge de nouvelles données

Tu fais ça avec Vue router assez facilement

dès qu'on charge de nouvelles données

ça dépendra de ton type de requête, si tu fais une requête ajax (avec Axios, par exemple, sur un backend) alors non mais si tu change de route avec les outils de vue router, oui !

Et prend-t-il bien en charge un support multilingue sans Backend derrière, donc avec le contenu dans des fichiers ?

Tu trouveras ton bonheur avec Vue I18n

Le 27 novembre 2019 à 17:13:50 AsariTech a écrit :
Intéressant, merci pour ces infos. D'ailleurs dans le cas d'une application monopage, est-il possible avec Angular de garder en mémoire certaines parties de la page comme des menus puis de charger le contenu qu'il faut en fonction de la requête utilisateur mais en changeant également l'adresse dès qu'on charge de nouvelles données ? Et prend-t-il bien en charge un support multilingue sans Backend derrière, donc avec le contenu dans des fichiers ?

Oui de base tu as le routage, les appels http, tu peux creer layout qui sera en faite un component parent ou tu met menu header et qui sera charger la première fois où t’arrive sur le site.
Pour le multilingue ta des plugins, par contre la gestion des url multilingues c’est un peu plus chiant mais t’as aussi un plugin pour ça 🤣

Merci à vous deux pour vos réponses, plus qu'à étudier tout ça car je n'ai pas tout compris.

Le 26 novembre 2019 à 22:40:53 dark_drow a écrit :
De mon expérience, j'ai vraiment apprécié apprendre à faire des sites web avec Angular.
La documentation est claire, ça apprends plein de bonnes pratiques, et même si le framework sera peut être plus la dans 10ans, la façon de coder des interfaces "façon angular" est bien là depuis 10ans et sera surement encore là pour 10ans donc c'est pas perdu.
En plus c'est maintenable, au lieu d'etre "un travail de stagiaire" c'est à dire que le jour ou ca marche plus on jette tout car c'est pas maintenable (en tout cas un site en vanillajs j'y touche même pas).

Et aussi, un projet commence toujours avec "5 page et deux div" et ça fini toujours en truc monstrueux avec un cahier des charges qui grossit plus vite qu'on code et on regrette vite le framework solide qu'on a pas voulu utiliser en premier lieu

Si de base tu as bien codé ton site en vanilla JS je ne vois pas le soucis.
Disons Mr Dupont a très bien pu faire du code spaghetti et là c'est comme pour tout ça risque d'être un casse-tête monstre à le maintenir.
J'ai récemment voulu faire une modernisation de mon interface sur une application que je conçois, ça m'a pris au bas mot 2 jours ( de Lundi matin à Mardi soir 23h ) et dieu sait que je ne suis pas un exemple de productivité

Maintenant je comprends bien l'idée d'utiliser un framework, il y a un tas d'avantages à en utiliser mais je vois pas en quoi un site en vanilla JS serait comme par magie beaucoup moins maintenable, tout dépendra du type d'application bien évidemment mais surtout de comment est fait le code en premier lieu.

T'en connais beaucoup des spa en full vanillajs au minimum t'as jquery.
Il y a quelques années c'était le début des spa, un client nous avait demandé de faire le workflow d'une page en full js, résultats 3000 lignes de js va maintenir ça, en angular on aurait pas dépasser 500 lignes.

Si de base tu as bien codé ton site en vanilla JS je ne vois pas le soucis.

Tu devrais :') ou alors c'est du troll

résultats 3000 lignes de js va maintenir ça, en angular on aurait pas dépasser 500 lignes.

Je pense que ça résume tout