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

[Etheon]

Puisque ça parle de frameworks, je sais pas si vous avez vu un des nouveaux venu mais je suis en train d'apprendre/tester SvelteKit (Framework fullstack construit sur Svelte https://svelte.dev/) , et ben c'est vraiment rafraichissant. Plus simple à appréhender que React pour le coup. Je pense passer la plupart des mes projets perso dessus, c'est agréable à utiliser.

[Awake]

Regarde Angular alors, la séparation MV* est plus propre que React et le framework est clairement influencé par les pratiques d'architecture du monde du desktop/backend.

(j'ai jamais été impressionné par React pour les mêmes raisons)

L'intérêt d'un framework par rapport à du pur js c'est surtout la normalisation : pour une entreprise, prendre un dev sur le framework X c'est l'assurance que le gus ne sera pas dépaysé quand il arrivera sur le projet. Alors qu'avec du pur js t'est forcément face à la cuisine local que tu dois commencer à comprendre avant de faire quoi que ce soit.

Merci, effectivement j'ai suivi le getting started d'Angular, et ce que j'ai vu me plaît beaucoup plus.

Il y a quelques trucs qui me chiffonnent, par exemple, pourquoi pas de routes nommées ? Comment on fait pour le refactoring de route ? J'ai vu quelques solutions sur SO mais c'est du hack.

Aussi ça m'a étonné, sur les tags HTML, de devoir indiquer que l'attribut doit être interprété sur le nom de l'attribute.

<a href="#" [title]="variable">coin</a>

Cette syntaxe m'aurait semblé beaucoup plus logique :

<a href="#" title="{{ variable }}">coin</a>

Bref je vais surement dev une petite app (en rapport avec Expert CPC tant qu'à faire) open source sur GitHub pour me faire une première expérience.

J'ai mis mon statut en #OpenToWork sur LinkedIn, mais pour l'instant il se passe pas grand chose... j'ai l'impression que les gens cherchent des CDI/CDD, pas des freelances. J'ai aussi vu une annonce pour un Ingénieur Full Stack Bénévole

[Charmide]

Tu peux pas vraiment comparer React en tant que framework à un truc plus large. Le principe de React en soit, voire même le design pattern "recommandé" de Flux, n'est pas révolutionnaire ou particulièrement éloigné des archis qui les précède sur comment faire la couche UI, mais ça fait 20% du taf d'un framework *applicatif* et t'as encore 12 000 questions d'archi à te poser pour faire n'importe quel projet.
D'ailleurs c'est bien le gros problème si tu veux te mettre à React, t'as encore à apprendre un ecosystème entier plus qu'un framework, encore plus que pour n'importe quel autre techno. Angular en ce sens est un peu plus sur le côté batteries included et fait bien plus que juste la vue.
D'ailleurs y'a un principe refleté de philosophie sur le point de syntaxe que tu remontes, {{variable}} c'est logique pour un principe de template unidirectionel où data =(ton truc)> la vue (e.g. ce que fait React ou ce que tu fais quand tu génères du HTML en backend pour le renvoyer), Angular c'est davantage bidirectionnel et ((data <=> la vue))=ton truc.

Sur le côté "separation of concern" - je trouve ça drôle. Même pour des (vieux) gens qui ont fait beaucoup de web, y'a un petit peu ce faux sentiment surané en web que le fait de mettre dans des fichiers différents le CSS, le JS et le HTML voudrait nécessairement dire que ton archi est plus propre. Pourtant si y'a bien un truc qui converge très fortement dans l'état de l'art c'est la façon de travailler sur et déclarer des composants, avec globalement la même tambouille:



En web comme ailleurs en programmation mais bien plus ici vu que la barrière à l'entrée est basse et qu'on accepte tout le monde, t'as des gens qui arrivent à faire des archis de merde ou très cool en partant de n'importe quelle combinaison de framework.
Les goûts et les couleurs de sucre syntaxiques sont d'aussi bonnes raisons que d'autres pour s'intéresser à un framework plus qu'un autre, mais en l'état de l'ecosystème web ils ne forcent voire n'encouragent pas vraiment de bonnes pratiques IMHO.

Puisque ça parle de frameworks, je sais pas si vous avez vu un des nouveaux venu mais je suis en train d'apprendre/tester SvelteKit (Framework fullstack construit sur Svelte https://svelte.dev/) , et ben c'est vraiment rafraichissant. Plus simple à appréhender que React pour le coup. Je pense passer la plupart des mes projets perso dessus, c'est agréable à utiliser.

J'ai testé sur quelques projets et je pense que je vais lancer mes nouveaux projets sur Svelte par défaut après 7 ou 8 ans de loyaux services de React, c'est plus simple et plus clean parce que plus jeune effectivement.
SvelteKit architecturalement c'est la même archi que Remix côté React, c'est pas mal comme approche et ça a le vent en poupe, ça revient à des trucs très route-based et principalement server-side, y'a de l'ironie vu que ça rappelle les belles heures de Django RoR & co, mais sans perdre l'intérêt des SPA ce qui a toujours été un peu le graal.
J'ai jamais voulu abandonner le gain d'usabilité que tu peux avoir sur les SPA, mais sur le type de projets que je gère ça m'a toujours cassé le cul d'avoir un coût en termes de rapidité de développement d'avoir à gérer son backend, sans avoir été satisfait des trucs type firebase et backend as a service. Y'a des chances que SvelteKit soit la bonne solution après quelques années d'évolution.

[Awake]

Et oui, quand j'ai commencé le dev web, pour mettre 4 textes en rouge on faisait comme ça :

<font color="red">
<?php
for ($i = 0; $i < 4; $i++) {
?>
Coin<br>
<?php
}
?>
</font>

Et c'était horrible, les fichiers étaient illisibles, le refactoring impossible.

Donc quand les feuilles de style sont arrivées, puis les premiers frameworks MVC backend, c'était la révolution. Le boulot est devenu beaucoup plus agréable.

Pour cette raison, ouais, tout mélanger me hérisse un peu le poil. Probablement à tort, les choses ont beaucoup évolué depuis

[Charmide]

Disons que c'est moins tout mélanger que organiser différemment, parce que le scope d'une SPA n'est pas le même que celui d'une app backend. Mais ouais comme tu dis, ça évolue et c'est plus un coup à prendre qu'autre chose.

Et de toute façon le paysage technologique du web est tellement fragmenté que bien malin (pas moi) celui qui arrive à reconnaître une/la good practice indiscutable, on a quelques repères sur boîtes très UX et front type airbnb & co comme références, mais à part ça je suis sûr que tu peux trouver à peu près ce que tu veux pour matcher tes préférences.

Angular est très inspiré Java (design patterns de service, injection de dépendence, etc.) et on prend le modèle MVC classique pour le mettre dans le navigateur, pas super bankable dans mon référentiel tech propre à moi de ce que je connais par rapport à React, à peine mieux que Symfony, mais c'est que moi, pas un jugement de valeur, et je doute pas trop que ça puisse se freelancer quand même

[deathdigger]

<a href="#" [title]="variable">coin</a>

Cette syntaxe m'aurait semblé beaucoup plus logique :

<a href="#" title="{{ variable }}">coin</a>

C'est quoi que t'essaies de sortir ? Parce que les deux syntaxes existent mais n'ont pas le même but.

[Awake]

Ouais j'ai compris ce que ça fait, c'est juste la syntaxe qui me semble étrange.

Comme les ngIf et ngFor . Pourquoi rajouter ng

[Orhin]

Ouais j'ai compris ce que ça fait, c'est juste la syntaxe qui me semble étrange.

Faut bien comprendre que même si ça ressemble à du HTML n'est pas du HTML, que ce soit pour les template Angular ou le JSX React.
Ça a une syntaxe proche par soucis de simplicité.

Mais derrière c'est compilé en JS et c'est le framework qui va manipuler le DOM.

Ce bout de code

<a href="#" title="{{ variable }}">coin</a>

C'est pas un template HTML (sous forme de fichier texte) dans lequel "{{ variable }}" va être remplacé par une valeur.
C'est une représentation d'un nœud HTML avec différents attributs (href et title) et un enfant (coin) et pour lequel l'attribut "title" a sa valeur bindé à la variable "variable".

Quand Angular va rendre ce bout de code, il va créer dans le DOM le nœud "a" et y coller les attributs associés.
Puis à chaque changement de valeur de "variable", il va mettre à jour la valeur de l'attribut "title".

La syntaxe

<a href="#" [title]="variable">coin</a>

Est différent car à la base "[toto]=" c'est pour binder une valeur sur un input d'un component, pas sur un attribut d'un élément HTML.

Comme les ngIf et ngFor . Pourquoi rajouter ng

Pour éviter les conflits de nommage.
Ce sont des directives (structurelles ou d'attribut) qui permettent de manipuler des composants ou des éléments de tes templates.
Et vu que tu peux créer les tiennes (comme pour les components), Angular a décidé que tout ce qui venait du framework aurait un prefix "ng".

Tout comme la majorité des librairies Angular vont avoir leur propre préfixe pour les composants qu'elles exposent (md pour la librairie Material officielle par exemple).

[Awake]

Ouais, je m'en doutais, mais je me dit que ça aurait surement été mieux de renommer le for du label à ce moment là.

Vu que les dev vont beaucoup plus utiliser ngIf et ngFor que le for="" du <label>, ça me semble assez logique que ce soit ce second qui doive s'adapter.

[Orhin]

Sauf que le "for" du label vient de la spec HTML, Angular va pas changer la spec.
Et renommer juste au sein du framework c'est casse gueule car l'idée c'est que les template restent quand même proches du HTML.

Mais quand je parlais de conflits de nommages, je ne pensais pas à celui-ci.
Plutôt au cas où toi tu veux développer ton propre "ngIf" qui fonctionne différemment.
Ben tu pourras le nommer "if" si tu veux vu que ce sera pas réserver par Angular.
Même si dans l'idéal tu devrais le nommer "appIf" (ou "awakeIf" si c'est dans une lib nommée "awake").

[Anonyme20240202]

ngUyen

[Orhin]

[zatura]

Pour les fronteux du coin vous connaissez un outil comme celui-ci permettant de générer de la doc pour différents composants ?

La plupart de ceux que je vois comme storybook obligent à passer par des composants en Vue ou en React, langages que certains collègues ne maîtrisent pas forcément. J'aurais bien utilisé KSS mais il veut pas se lancer, j'ai des erreurs dès la troisième commande d'install

[deathdigger]

ChatGPT ?

[Etheon]

Me semblait que Storybook était plutôt agnostique...

https://betterprogramming.pub/gettin...k-c2968d3f3d9f
https://www.reddit.com/r/Frontend/co...js_components/

Après c'est peut être beaucoup moins rapide/pratique qu'avec React !

[mellifico]

@Charmide Je te remercie chaleureusement d'avoir attiré mon attention sur Svelte et Sveltekit, moi qui était parti pour apprendre Vue...
Je suis une belle grosse quiche enthousiaste en JS mais j'ai besoin de sortir de Wordpress, vous voyez ? Je suis un vieux d'la vieille, un peu lent, mais il me reste de l'instinct quand même...
Je cherche donc des idées de projet basique pour apprendre " en m'amusant ", en particulier fetch and XMLHTTPRequest. Si vous avez des suggestions, merci d'avance.

PS: ce thread est monstrueux, en tant que freelance " jack of all trades, master of none ", je tryhard comme un dingue pour vous comprendre, c'est très stimulant et vous me faites gagner un temps fou, tous, merci !

[Charmide]

Bon courage

La discussion m'a fait penser que j'avais pas encore lu le State of JS 2022, je conseille pour ce genre de discussions, c'est pas mal a minima comme liste de technos intéressantes à considérer et auxquelles jeter un oeil, et je trouve que l'adoption/satisfaction des différentes libs est assez représentative.

[Awake]

@mellifico : Je te conseil de partir sur fetch directement si tu veux te mettre à jour, XMLHttpRequest n'est plus trop utilisé.

Sinon ça y est, j'ai release mon premier projet Angular J'y boss depuis 2.5j, c'est une petite app statique pour parcourir les data d'ExpertCPC.

La prod -> https://expertcpc.s3.amazonaws.com/archives/index.html

C'était bien marrant à faire, mais je suppose que j'ai fait certaines choses qui ne sont pas très catholiques - j'ai notamment essayé de faire de l'héritage de composant, avec succès, mais je sens bien que ce n'est pas fait pour.

Le github -> https://github.com/code200fr/expertcpc-archive

A votre bon cœur si vous avez des retours

[raaaahman]

Je cherche donc des idées de projet basique pour apprendre " en m'amusant ", en particulier fetch and XMLHTTPRequest. Si vous avez des suggestions, merci d'avance.

Des idées de projets sur DevProjects by CodeMentor: https://www.codementor.io/projects/javascript

Des API publiques sur RapidAPI Hub: https://rapidapi.com/collection/list-of-free-apis


EDIT: Arrêtez tout!

Spoiler Alert!

[deathdigger]

Je connais quelqu’un qui bosse avec et c’est pas mal. Déjà, ça permet d’avoir tout de suite toutes les infos de la charte graphique et ça permet une unicité des devs. Les mecs derrière sont réactifs, du coup s’il manque un objet, ils les préviennent et l’équipe l’implémente rapidement.

Sinon Dross, je veux bien des détails sur l’archi que tu vas mettre en place et son coût. J’ai un contrat d’un VPS OVH qui va arriver à expiration et j’ai clôturé un Amazon
LightSail. Ce que je voudrais, c’est avoir un back en .Net et un front en angular. Le but c’est de tester comment on fait maintenant et comment on estime les coûts. J’ai cité AWS mais ça peut être Azure ou autre (pas un truc trop exotique, c’est aussi pour me former). Si tu peux me présenter ta solution, ça serait top
Enfin quid du multi-sites ?

[Dross]

Pour mes projets pro (start-up) et perso (open source comme closed source), j'utilise maintenant des petits VPS chez Vultr (mais des offres équivalentes existent chez Linode etc), avec des instances aussi petites que 1CPU 500MB à 3.5$/mois, et je scale ensuite si nécessaire.

En général je déploie 1 service par VPS (que je peux placer derrière un loadbalancer au besoin) si ça doit être sérieux en terme de charge / potentiel de scaling / etc. Donc par exemple la webapp + webapi sur son propre VPS, une api backend sur un autre, une bdd sql sur un autre, une bdd no-sql sur encore un autre, etc. Toujours sur les instances les plus petites possibles.

Si ça n'a pas besoin d'être sérieux (projet perso), je vais juste caler toutes les dépendances sur le même VPS, mais ce sont en général des projets qui ne génère pas tellement de trafic. Même si je suis toujours surpris des performances de leurs trucs à 3.5$, j'ai des uptimes très élevés et des bonnes perfs (bien plus que quand on étais chez Azure : on payais très cher et c'était lamentable au niveau des perfs).

Avec une stack essentiellement .NET me concernant, on dockerise tout. Sur hub public ou privé. Si tu veux un exemple de ce que je fais sur les machines, c'est globalement cette démarche (c'est la doc d'installation d'un de mes projets opensource). Avec un firewall au niveau de Vultr en plus (typiquement je bloque le port SSH en dehors de mes endroits de connexion usuels, et comme c'est fait via l'interface de Vultr et pas au niveau des VPS je ne risque pas de me faire bloquer dehors si mon IP change).

Pour le multi-site j'imagine que tu parle redondance et géo-redondance ? Rien t’empêche de créer des VPS sur différents sites pour chopper la charge, même si de ce coté là j'ai jamais eu vraiment besoin de ce genre de choses sur mes projets donc pas tellement d'expérience dedans (ça arrivera ptet un jour). Pour la sécurité des données, Vultr propose des trucs qui sont vraiment pas mal (et pas trop cher), mais en général je rebackup en plus sur du AzureStorage (ça par contre c'est pas mal comme service, pas trop cher et si tu veux tu peux aussi avoir du redondant local et géographique - dans les autres services PaaS que j'aime bien chez Azure c'est l'AzureTable, du NoSQL sans emmerdes de gestion et pas cher du tout).

Ce que j'aime bien avec 1 app = 1 VPS c'est qu'il est très facile de trouver le responsable en cas de service qui pète les plombs, sans pour autant partir dans le kubernetes et autre qui est encore plus intéressant, mais avec un investissement encore plus grand aussi.


Pour le petit service que je vais mettre en place je pars sur une instance à 5$ (pas pour les perfs mais pour le bandwidth qui risque d'être un peu plus important que la normale), et tout le monde sur la même instance au début : webapp / wepapi / messaging in-memory / service worker. Mais avec peu de travail (le code est déjà architecturé comme ça) je pourrai très rapidement le faire migrer vers instance wepapp + instance rabbitmq (ou AzureQueue) + instances workers si j'en éprouve le besoin.

Je pense pas avoir besoin de scaler la partie webapp (ça sera une PWA - via Angular - donc servie qu'une seule fois et autonome ensuite) et ASP.NET Core est extrêmement performant, j'aurai d'autres problèmes à régler avant que ce truc sature.

Si t'a d'autres questions hésite pas.

ps: si tu veux tester Vultr, avec ce lien referal tu aura 100$ de test (aucune obligation évidemment)

[deathdigger]

Cool, merci
Je pensais que tu separais toujours front et back, et que tu partais sur des conteneurs, plutôt que des VPS. Aussi, je n'ai jamais essayé de déployer un site .Net sur Linux, faudrait que je teste. Et pourquoi t'es parti sur Vultr, plutôt qu'AWS ?

[Dross]

C'est les deux : conteneurs et VPS, t'est pas obligé de prendre du PaaS pour utiliser des conteneurs (faut juste installer docker/docker compose sur la machine). Ça reste intéressant en terme de déploiement (ça ne te pourri pas la machine, c'est facile à mettre à jour, etc).

A l'époque ou j'ai tout passé sur Vultr, AWS était légèrement plus cher, puis pour être honnête, Azure et AWS sont les deux "go to", et j'ai eu tellement de soucis avec Azure (maintenance de leur part sans me prévenir, perfs vraiment à chier, etc) alors que mes trucs perso tournaient avec qualité et du service chez Vultr (je donne le moins d'argent possible à Jeff d'un point de vu perso) que j'ai migré tout notre parc là bas quand j'en ai eu marre.

.NET Core c'est top pour le multiplate-forme, et pour la dockerisation t'a déjà tout ce qu'il faut en image de base, autant SDK pour builder, que framework simple pour faire tourner le bazar.

Pour la séparation front/back, ça se discute. On a eu par le passé ce genre de séparation, quand on était en ASP.NET MVC et ASP.NET API, deux projets distincts avec routes/etc propre à chaque projet et hébergé en séparé. Mais avec une webapp de type Angular, t'a plus vraiment d'intérêt à séparer les deux. C'est comme si t'avais une api publique (ASP.NET Core) et un outil desktop au final (une PWA se comportant comme tel d'ailleurs).

[deathdigger]

Je ne suis pas encore super à l'aise avec Angular et .Net, mais quand j'ai testé, c'était mouef :
Je voulais tester un front en Angular et le back en .Net. En faisant un projet de ce type dans Visual Studio, je trouvais que ça ramait comme pas possible et au bout d'un moment, je me tapais des erreurs de compilation.
J'ai testé en utilisant VS que pour la couche C# (les webservices) et l'Angular à part, ben là ça marchait plutôt bien. La seule merdouille à régler, ce sont les droits (les WS par défaut ne répondent pas à un autre site que celui sur lequel ils sont, si je me rappelle bien).
Bon, c'était pour la partie dev, pas encore testé de déployer.

[Dross]

Le mieux sur cette stack c'est de travailler en C# avec VisualStudio, et en Angular sur VS Code. Mais les deux trucs peuvent hébergés au sein du même projet ça ne devrai pas poser de problème, du moins j'en ai pas de mon coté et j'ai des projets assez velus (avec du WS, WebGL etc).

Le template VS de ASP.NET Core + Angular est pas mal d'ailleurs, même s'il faut en effet l'adapter un peu pour faire marcher le WS (le proxy dans Angular, les CORS dans ASP.NET, etc ; mais les premiers résultats dans google te donnerons la marche à suivre) et il manque le dockerfile (dans les templates ASP.NET il est fourni en général mais pas dans celui là) pour ce dernier si tu veux je t’enverrai un de ceux que j'utilise.

[deathdigger]

Attends, déjà faut que je digère tranquillou ce que tu me dis.
Je n'ai jamais utilisé Docker, va falloir que je m'y mette.

[acdctabs]

Ouais je pensais m'y mettre rapidement pour faire tourner un truc.
Faut juste que je trouve un endroit pour faire tourner le docker si j'ai bien suivi.

[Dross]

Docker c'est le truc que j'avais laissé de coté pendant 3 ans après avoir testé de loin (et j'avais trouvé ça trop compliqué en premier contact) mais c'était une belle erreur de ma part : je regrette vraiment de ne pas m'y être mis sérieusement plus tôt.

En plus la stack est mature aujourd'hui, à l'époque on la déconseillait en prod, aujourd'hui ça serai presque l'inverse.

Le plus simple pour s'y mettre en douceur c'est d'installer Docker Desktop (y'a une belle UI et tout) et de commencer à jouer avec. Lancer un Ubuntu pour commencer, s'y connecter, installer 2-3 trucs, vérifier que ça marche. Puis lancer 2-3 app conteneurisées (un Postgres ? un Redis ? un MongoDb ? etc) pour jouer avec, remarquer qu'installer (et surtout désinstaller) ce genre de truc ne dégueulasse plus la machine. Ensuite se lancer dans docker-compose et lancer un écosystème complet en 3 clics sur sa machine (y'a des exemples dans la doc officielle qui est très bien faite). En général c'est là qu'on se dit "Oh putain. Aussi facilement ? Comme ça ?" et on ne reviens plus en arrière après.

[GrandFather]

Docker est devenu vraiment viable sous Windows depuis assez récemment, et à condition de l'utiliser avec WSL2. Attention avec Docker Desktop, notamment dans un contexte pro d'entreprise, l'accord de licence a évolué.

[acdctabs]

Non mais faut que je paie un truc en ligne pour faire tourner un truc sous docker quand mon pc est éteint ?
Genre un serveur avec un debian ?