Design & Développement web - Le topic des canards qui mangent des cookies

[GrandFather]

Le code métier, il est généralement côté backend et accessible au travers d'une API. La logique implémentée dans les composants Vue n'est que celle nécessaire à la construction et au comportement de l'UI. Et, d'expérience, quand on retrouve beaucoup de code JS dans un composant Vue, c'est qu'on s'est loupé sur le « Separation of Concerns »...

[deathdigger]

Oui, je connais les bonnes pratiques, mais là, il est POSSIBLE de faire de la grosse merde (par exemple, le fait d'avoir des if dans la vue). J'aime bien les langages qui limitent les conneries de base.

[TwinBis]

J'aime bien les langages qui limitent les conneries de base.

En front web tu dois souffrir.

[deathdigger]

J'en fais jamais
Là, comme un pote a suivi une formation UX Design et qu'il m'en a parlé, j'ai voulu voir à quoi ça ressemblait.

[GrandFather]

Oui, je connais les bonnes pratiques, mais là, il est POSSIBLE de faire de la grosse merde (par exemple, le fait d'avoir des if dans la vue). J'aime bien les langages qui limitent les conneries de base.

Pire, t'as même des for... Mais en quoi c'est de la connerie ? C'est un template dynamique, donc tu places des interpolations et des attributs qui modifient - selon une logique implémentée dans le reste du composant, et de façon réactive - la structure du DOM, c'est la base même du framework. Si tu veux travailler sur un template statique et modifier le DOM uniquement par un code JS externe au template, c'est du jQuery. Et pour avoir pas mal bossé avec les deux approches, je peux te certifier qu'il est infiniment plus facile d'arriver à une usine à gaz horrible à maintenir avec jQuery qu'avec Vue, sans même parler de la possibilité de réutilisation du code (la notion de composant stricto sensu n'existe pas dans jQuery, qui n'est qu'une librairie).

Mais si les templates de Vue.js ne te plaisent pas, ne t'intéresse alors surtout pas à React ; tu n'es pas prêt pour JSX (moi non plus, remarque)

[Whiskey]

J'ai commencé une formation Vue.js, pour voir ce que c'était le js "moderne".
Ben putain, j'ai du mal avec le principe. Pouvoir foutre de la logique dans la vue, ça peut vite être le bordel.

C'est génial vue, et facilement mis en place. Si tu veux apprendre: https://www.udemy.com/course/vuejs-de-a-a-z/ Très bonne formation (attend les promos sur udemy, ca viens souvent - Formation a 12 € environ).

Si tu as rien contre l'anglais: https://www.udemy.com/course/vuejs-2...omplete-guide/

Y a aussi sveltes.js, qui est connu pour etre le plus léger et assez performant. (Mais pas aussi fun que vueJS)

ReactJS est puissant, (peut être le plus puissants des framworks existant sur le marché) mais il est aussi lourd pour l'utilisation et pour la mise en place/le dev. En général je conseil React pour les gros projet uniquement.

[Orhin]

Pardon si je connais assez mal vuejs et que je ne fais qu'un peu de react à la maison mais il me semble qu'on est quand même pas dans l'optique de "foutre [de] la logique dans la vue".

L'idée il me semble que c'est d'isoler des "composants" les uns des autres. Chaque composants est (plus ou moins) isolé et contient : vue, style et logique qui lui est propre.

Maintenant ça veut pas dire qu'il faut copy pasta toute la logique métier dans la vue. Pour la logique propre au composant tu peux faire des méthodes privées et pour le vrai code métier tu peux faire des services que tu importes où c'est nécessaire.

Corrigez moi les front-endos, si je me gourre.

Non c'est plus ou moins ça (avec des variations en fonction des framework).

Pour les composants, en fait tu vas en généralement en trouver de 3 types :
- des composants purement visuels (par exemple un bouton ou une checbox) qui ne sont là que pour la vue et ne contiennent pas de logique ni ne stocke d'état ;
- des composants structurels (par exemple le layout d'une page) qui sont là pour placer les composants visuels et leur filer les données d'entrée, mais en général ils ne stockent pas non plus d'état ;
- des composants d'orchestration (peu être mixé avec un composant structurel) qui va s'occuper de gérer la donnée (soit en la prenant depuis un store ou un service soit en interne).

Oui, je connais les bonnes pratiques, mais là, il est POSSIBLE de faire de la grosse merde (par exemple, le fait d'avoir des if dans la vue). J'aime bien les langages qui limitent les conneries de base.

Non mais tu peux faire de la grosse merde avec tous les languages et framework du monde en cherchant bien.

Par contre avoir un "if" dans la vue n'a rien d'anormal, c'est pas de la logique juste un aspect dynamique de la vue.

une usine à gaz horrible à maintenir avec jQuery

Mais tellement.

Mais si les templates de Vue.js ne te plaisent pas, ne t'intéresse alors surtout pas à React ; tu n'es pas prêt pour JSX (moi non plus, remarque)

Le JSX c'est le bien.
Pour moi c'est le seul truc qui manque à Angular pour en faire le framework web ultime (et faciliter aussi la composition de components).

[Orhin]

ReactJS est puissant, (peut être le plus puissants des framworks existant sur le marché) mais il est aussi lourd pour l'utilisation et pour la mise en place/le dev. En général je conseil React pour les gros projet uniquement.

Boaf, si tu pars sur du React tout seul (sans routing, internationalisation et tuti quanti) c'est relativement léger, surtout si t'utilises un CLI comme create-react-app pour la mise en place.
Comparé à un projet de base Angular, ça reste light (par contre l'outillage en CLI est bien mieux foutu que ce qu'on trouve sur React).

[Whiskey]

Boaf, si tu pars sur du React tout seul (sans routing, internationalisation et tuti quanti) c'est relativement léger, surtout si t'utilises un CLI comme create-react-app pour la mise en place.
Comparé à un projet de base Angular, ça reste light (par contre l'outillage en CLI est bien mieux foutu que ce qu'on trouve sur React).

Je ne connais pas malheureusement angular (du moins pour le moment - j'y compte bien le voir), difficile pour moi de le comparer

[GrandFather]

C'est génial vue, et facilement mis en place.

Je confirme. Je suis passé récemment pour mes applis d'une architecture MPA « classique » Symfony/Twig/jQuery à une architecture SPA Symfony/API Platform/Vue.js, et je n'ai aucune envie de revenir en arrière.

Le JSX c'est le bien.
Pour moi c'est le seul truc qui manque à Angular pour en faire le framework web ultime (et faciliter aussi la composition de components).

Je ne nie pas que ça soit puissant, c'est sa syntaxe qui me reste en travers. Ca, et le fait que, contrairement à Vue.js, tu ne peux pas le mettre en oeuvre sans transpilation, et donc sans un outil de build (Webpack). Lorsque je me suis formé aux technos modernes pour le frontend - je suis à la base un développeur backend - ça m'avait posé un problème. Vue.js m'avait paru largement plus accessible à un néophyte.

[tenshu]

ReactJS est puissant, (peut être le plus puissants des framworks existant sur le marché) mais il est aussi lourd pour l'utilisation et pour la mise en place/le dev. En général je conseil React pour les gros projet uniquement.

Boaf, si tu pars sur du React tout seul (sans routing, internationalisation et tuti quanti) c'est relativement léger, surtout si t'utilises un CLI comme create-react-app pour la mise en place.
Comparé à un projet de base Angular, ça reste light (par contre l'outillage en CLI est bien mieux foutu que ce qu'on trouve sur React).

J'ai tendance à dire qu'en soit React c'est une librairie avec tout un écosystème autour, pas un framework.

Et oui je recommanderait paaaaaaas du tout pour un petit projet.

Le JSX c'est le bien.
Pour moi c'est le seul truc qui manque à Angular pour en faire le framework web ultime (et faciliter aussi la composition de components).

Par contre le css in js, impossible de m'y faire c'est une hérésie.
(j'ai bien compris que c'est pratique pour isoler les composants)

[GrandFather]

J'ai tendance à dire qu'en soit React c'est une librairie avec tout un écosystème autour, pas un framework.

React, comme Vue.js, conditionne très fortement la structure de l'application JS dans laquelle tu l'utilises, et propose de nombreux points d'extension. C'est vraiment un framework à plein titre.

[tenshu]

On va être d'accord pour ne pas être d'accord
Particulièrement sur le fait que cela structurerait "fortement" l'application.

[GrandFather]

Ben quand même, l'organisation en composants, la façon de bootstrapper l'application... Tu peux pas y aller en mode #YOLO.

Mais bon, les deux projets ne vont pas nous aider à nous départager : React se définit comme une bibliothèque, et Vue.js comme un framework (progressif), malgré leurs très nombreux points communs et leur même finalité.

[Orhin]

Je confirme. Je suis passé récemment pour mes applis d'une architecture MPA « classique » Symfony/Twig/jQuery à une architecture SPA Symfony/API Platform/Vue.js, et je n'ai aucune envie de revenir en arrière.

Ah mais clairement, le second est bien mieux (mais ça fait plus de 10 ans que ça existe maintenant ).

Je ne nie pas que ça soit puissant, c'est sa syntaxe qui me reste en travers. Ca, et le fait que, contrairement à Vue.js, tu ne peux pas le mettre en oeuvre sans transpilation, et donc sans un outil de build (Webpack). Lorsque je me suis formé aux technos modernes pour le frontend - je suis à la base un développeur backend - ça m'avait posé un problème. Vue.js m'avait paru largement plus accessible à un néophyte.

Ça c'est uniquement si tu n'utilises pas de CLI, et là effectivement écrire sa config webpack à la mano c'est chiant.
Mais avec angular-cli ou create-react-app t'as pas grand chose à configurer toi même et ça marche tout seul.

J'ai tendance à dire qu'en soit React c'est une librairie avec tout un écosystème autour, pas un framework.

Oui, c'est comme ça que se définie React.
Mais en vrai l'écosystème te cloisonne quand même un peu.

Et oui je recommanderait paaaaaaas du tout pour un petit projet.

Boaf, si t'as déjà utilisé le framework y'a aucun soucis.

Par contre le css in js, impossible de m'y faire c'est une hérésie.
(j'ai bien compris que c'est pratique pour isoler les composants)

Je suis pas ultra fan non plus mais c'est une question d'habitude.
Par contre c'est chiant à utiliser avec un pré-processeur type scss/less/sass.

Pour l'isolation des composants, pour moi c'est au framework de gérer ça.
Angular le fait de base donc tu peux écrire ce que tu veux en css sans poluer tes autres composants ou ceux des librairies utilisées.

[GrandFather]

Ah mais clairement, le second est bien mieux (mais ça fait plus de 10 ans que ça existe maintenant ).

Là où je bosse, c'est encore une technologie de pointe.

Ça c'est uniquement si tu n'utilises pas de CLI, et là effectivement écrire sa config webpack à la mano c'est chiant.
Mais avec angular-cli ou create-react-app t'as pas grand chose à configurer toi même et ça marche tout seul.

Oui, quand tout va bien. Mais au premier coup de Trafalgar, ou au premier besoin de customiser un peu le build, le débutant se retrouve comme un lapin pris dans les phares... Webpack est un très gros morceau, et l'aborder en même temps que l'apprentissage de React augmente de façon vertigineuse la courbe d'apprentissage de l'ensemble. Vue.js est beaucoup plus noob-friendly de ce point de vue là.

[Orhin]

Oui, quand tout va bien. Mais au premier coup de Trafalgar, ou au premier besoin de customiser un peu le build, le débutant se retrouve comme un lapin pris dans les phares... Webpack est un très gros morceau, et l'aborder en même temps que l'apprentissage de React augmente de façon vertigineuse la courbe d'apprentissage de l'ensemble. Vue.js est beaucoup plus noob-friendly de ce point de vue là.

C'est pas faux.

Après un débutant n'aura pas besoin de toucher à la config webpack dans 99% des cas (j'ai des grosses applis en prod qui utilisent toujours la config de base de create-react-app).

[Lazyjoe]

Bon sang, je pensais avoir posé une petite question innocente et voilà que j'ai déclenché un débat d'expert où je ne comprends plus rien.

[tenshu]

Bon sang, je pensais avoir posé une petite question innocente et voilà que j'ai déclenché un débat d'expert où je ne comprends plus rien.

Ha c'est autre chose que les débats d'experts cpc

[Orhin]

Bon sang, je pensais avoir posé une petite question innocente et voilà que j'ai déclenché un débat d'expert où je ne comprends plus rien.

Et encore, dis-toi que le monde des framework JS front-end est bien plus simple maintenant qu'il y a 5-6 ans.

[Fastela]

C'est pas faux.

Après un débutant n'aura pas besoin de toucher à la config webpack dans 99% des cas (j'ai des grosses applis en prod qui utilisent toujours la config de base de create-react-app).

Webpack commence à me gaver perso. Je suis à deux doigts de retourner sur Gulp dans certains de mes projets. C'est tellement une usine à gaz, et je dois comprendre 20% de ce qui se passe dans mon fichier de config.

[Whiskey]

C'est génial vue, et facilement mis en place. Si tu veux apprendre: https://www.udemy.com/course/vuejs-de-a-a-z/ Très bonne formation (attend les promos sur udemy, ca viens souvent - Formation a 12 € environ).

Si tu as rien contre l'anglais: https://www.udemy.com/course/vuejs-2...omplete-guide/

Y a aussi sveltes.js, qui est connu pour etre le plus léger et assez performant. (Mais pas aussi fun que vueJS)

ReactJS est puissant, (peut être le plus puissants des framworks existant sur le marché) mais il est aussi lourd pour l'utilisation et pour la mise en place/le dev. En général je conseil React pour les gros projet uniquement.

Promo en cours pendant 3 jours.

[Cowboy]

Aujourd'hui pour faire des Webapps (un jeu c'est une webapp) on a les frameworks JS pour faire tout ça (React, Angular, Vue, etc) par contre, "facilement" non, du moins oui c'est facile par rapport à de la gestion du DOM à l'ancienne type Jquery (que je ne recommanderai absolument pas pour une webapp aujourd'hui) mais ça reste pas mal de boulot.

En quoi jquery est moins bien qu'angular aujourd'hui pour faire ca ?

[Dross]

Jquery c'est de la manipulation de DOM à la main, c'était bien quand on avait rien d'autre et qu'on voulais juste rajouter 2-3 animations à une page statique, mais aujourd'hui c'est vraiment prendre le mauvais outil, surtout pour faire une webapp (qui n'est aujourd'hui ni plus ni moins qu'une véritable application desktop, surtout avec l'arrivée des PWA).

Qui dit application desktop dit des décennies de bonnes pratiques et de patterns mis en place par les développeurs : l'isolation et la modularité, la séparation logique/vue/mise en page (sous ses formes récentes comme le MVVM, ou MV*), l'inversion de contrôle et l'injection de dépendances, les tests unitaires, etc.
Tout ça, ça fait justement parti d'un framework comme Angular, alors que Jquery au contraire ne coche aucunes de ces cases.

Après Jquery est encore adapté pour dynamiser un petit site web, mais pour faire une véritable webapp c'est vraiment pas adapté.

[Cowboy]

Jquery c'est de la manipulation de DOM à la main, c'était bien quand on avait rien d'autre et qu'on voulais juste rajouter 2-3 animations à une page statique, mais aujourd'hui c'est vraiment prendre le mauvais outil, surtout pour faire une webapp (qui n'est aujourd'hui ni plus ni moins qu'une véritable application desktop, surtout avec l'arrivée des PWA).

Qui dit application desktop dit des décennies de bonnes pratiques et de patterns mis en place par les développeurs : l'isolation et la modularité, la séparation logique/vue/mise en page (sous ses formes récentes comme le MVVM, ou MV*), l'inversion de contrôle et l'injection de dépendances, les tests unitaires, etc.
Tout ça, ça fait justement parti d'un framework comme Angular, alors que Jquery au contraire ne coche aucunes de ces cases.

Après Jquery est encore adapté pour dynamiser un petit site web, mais pour faire une véritable webapp c'est vraiment pas adapté.

En quoi jquery est moins bien qu'angular aujourd'hui pour faire ca ?

Passer par angular qui passe par jquery pour manipuler du dom, c'est mieux ? En quoi c'est mieux ?
Les controleurs dans le JS plutot que dans le back ?

Je n'ai jamais fais de jeux en ligne, je ne suis pas contre un exemple concret.


Vous dites qu'il faut utiliser un framework JS aujourd'hui sans justifier pourquoi.

[tenshu]

En quoi jquery est moins bien qu'angular aujourd'hui pour faire ca ?

Passer par angular qui passe par jquery pour manipuler du dom, c'est mieux ? En quoi c'est mieux ?
Les controleurs dans le JS plutot que dans le back ?

- Par ce que c'est un framework complet pas une méga librairie fourre tout
- Angular n'utilise pas jquery pour manipuler le dom, mais des concepts différents et plus performants
- pourquoi pas des controler ? Si il y a besoin de brancher une route et un template avec de la logique métier c'est pas une mauvaise idée non ?

[Teocali]

En quoi jquery est moins bien qu'angular aujourd'hui pour faire ca ?

Passer par angular qui passe par jquery pour manipuler du dom, c'est mieux ? En quoi c'est mieux ?
Les controleurs dans le JS plutot que dans le back ?

Je n'ai jamais fais de jeux en ligne, je ne suis pas contre un exemple concret.


Vous dites qu'il faut utiliser un framework JS aujourd'hui sans justifier pourquoi.

https://www.educba.com/angular-vs-jquery/

Plus serieusement, si tu dois juste rajouter quelques widget sur une page (genre moi avec mon Back Office), JQuery fait bien le taf

Si tu dois te cogner la conception complète d'une webapp, Angular répondra bien mieux aux contraintes que tu rencontreras.

[Cowboy]

- Par ce que c'est un framework complet pas une méga librairie fourre tout
- Angular n'utilise pas jquery pour manipuler le dom, mais des concepts différents et plus performants
- pourquoi pas des controler ? Si il y a besoin de brancher une route et un template avec de la logique métier c'est pas une mauvaise idée non ?

Framework tellement complet qu'il va nécessiter un autre framework derrière pour fonctionner ... j'appel pas ca complet.
Angular n'utilise pas jquery mais manipule forcément le DOM.
Pourquoi pas un controler ? Parcequ'en général on fait des choses quand on a une raison de les faire.

On peut faire des webapp sans framework JS.

Pourquoi un framework JS ? et pas jquery avec n'importe quel backend ?

[Siscka]

En quoi jquery est moins bien qu'angular aujourd'hui pour faire ca ?

Passer par angular qui passe par jquery pour manipuler du dom, c'est mieux ? En quoi c'est mieux ?
Les controleurs dans le JS plutot que dans le back ?

Je n'ai jamais fais de jeux en ligne, je ne suis pas contre un exemple concret.


Vous dites qu'il faut utiliser un framework JS aujourd'hui sans justifier pourquoi.

Y'a pas de vérité absolue.

@Dross t 'impose aucuns FW.

ça dépend ton besoin comme d'habitude, puis on parle de 2 choses différentes une lib (jquery) !== un FW (Angular)

[Cowboy]

On parle a la base d'une solution pour faire un projet.

La solution est "framework" js, sans justification et apparament ca me semble difficile d'obtenir une justification même provenant d'un peu moins 10 personnes différentes.