Choix d'un framework javascript

Salut,

Ma question a déjà dûe être posée un milliard de fois au moins, mais je tente

Pour poser le contexte, je développe une (petite) application web avec Flask. Et pour le fun, j’ai d’abord écrit tout une API (Rest) avec l’idée d’écrire ensuite la partie frontend pour la poser dessus. L’idée que j’ai derrière la tête, c’est que ça soit un peu dynamique, autrement dit d’utiliser Javascript pour mettre dynamiquement à jour les éléments via des appels à l’API. Je ne souhaite ceci dit pas en arriver au point d’avoir une single page application.

Du coup, j’ai été faire un tour des frameworks Javascript à la mode. J’ai bien noté Vue.js et consorts (React, Angular, etc), mais il y a un truc qui me plaît moyen, c’est qu’au final, ils intègrent leur propre système de route et t’invitent à lancer un second serveur web. Ça a très certainement son utilité, mais pour le coup, ça me parait un peu compliqué pour ce que je souhaite faire ici. J’ai aussi noté Svelte.js, mais je vois un peu mal comment l’intégrer au système de template de Flask (c’est le même que celui de Django). Finalement, j’ai pointé Alpine JS, mais je suis pas sûr d’être convaincu par l’idée de mettre du JS directement dans les balises HTML. Par contre, si si je dois écrire de tels codes "à la main" (à coup de document.getElementById() et document.createElement()), c’est assez long à faire convenablement (exemple: ajouter dynamiquement des lignes à un tableau).

Bref, je suis à la recherche de quelque chose d’intermédiaire entre Vue/Angular/whatever et du bête JS, quelque chose qui permettrait de manipuler le DOM facilement sans que un npm run serve (ou équivalent) ne soit nécessaire.

Merci d’avance

Bonjour,

Tu as éventuellement le Framework NextJS, qui s’appuie sur ReactJS et qui propose de faire un export static de ton site. Peut-être que cela peut correspondre à ce que tu recherches.

Ça m’a aussi l’air d’être un peu complexe/complet pour ce que j’en ferais réellement

Je pense que tu cherches vraiment quelques chose comme Svelte alors.

Compilation vers un site statique. Tu peux utiliser Sapper pour avoir un système de route et tout mais personnellement je préfère juste avoir plusieurs pages statiques, un peu comme ça.

Très franchement, les difficulté que j’ai eu à prendre en main l’outils sont principalement dû au fait qu’il est tellement simple que ça surprend. Tu comprendras si tu essayes je pense.

Pour Vue.js, tu as Nuxt.js, ça permet d’avoir une architecture de projet propre (tu n’en as pas forcément besoin pour ce qui va suivre).

Tu peux utiliser Vue (ou Nuxt.js) en mode SPA (Single Page Application), de ce fait, pas besoin de backend.

Ça fait bientôt 4 ans que je dev un projet avec Nuxt, et elle a toujours été hébergé sur un CDN (Github page, Vercel, Cloudflare Pages). Je n’ai jamais eux besoin de backend pour cela, en tout cas jusqu’a très récemment, mais je n’utilise pas leurs backend, j’ai un backend API uniquement (Strapi), ça ressemble à ce que tu souhaites faire.

Si j’ai bien compris, ton but est avant tout de générer les pages avec un moteur de template côté serveur, et d’utiliser un peu de JS pour mettre à jour certains éléments. Dans ce cas, Next, Nuxt et Angular ne sont sûrement pas appropriés, car ce sont de gros frameworks front-end qui sont fait pour générer un site web entièrement côté client.

Vue et React ne font pas de routing (il y a des packages spécifiques pour cela). Ce sont de simples bibliothèques qui génère du HTML côté client. Elles peuvent facilement s’importer directement dans une balise <script>, sans avoir à passer par npm, Webpack et compagnie.

Il existe des alternatives spécialement "light" pour des cas comme le tien, telles que Alpine.js comme tu l’as mentionné, ou plus récemment petite-vue, qui est une version très légère de Vue (6 Ko) justement destinée à s’intégrer dans des pages générées côté serveur (actuellement encore en développement, mais déjà assez stable).

Quant à Svelte, le code doit être compilé avant de pouvoir être exécuté par le navigateur, donc j’ai également du mal à voir comment l’intégrer au backend.

Je ne suis pas sûr de voir ce qui te pose problème. En l’occurrence, la syntaxe pour les templates Alpine est très similaire à celle de Vue. Tu auras dans tous les cas des trucs à ajouter dans tes balises.

Salut,

Il existe aussi une alternative au JS traditionnel sans arriver dans un framework pour autant : les Web Components.

La syntaxe reste connue, mais avec quelques évolutions pour faire des trucs plus dynamiques.

Il y a même un tutoriel en bêta sur le sujet (bon d’accord c’est un peu de la pub pour mon tuto, j’avoue).
Tu peux parcourir le code et voir le résultat via les liens dans la conclusion si tu veux.

Sinon concrètement c’est quoi tes critères principaux ?

Les frameworks que tu cites ne proposent de lancer un serveur qu’en local parce qu’ils transpilent à la volée (généralement pour la compatibilité navigateurs) donc te permettent d’accéder à ton front sans t’embêter à mettre ça en place. Une fois déployé en prod ce sera du statique que tu peux servir avec un Nginx tout simple.

Bonjour,

Merci pour vos réponses. Peut être que mes critères ne sont pas clair, mais je recherche plutôt quelque chose, comme le dit @Olybri, du genre de petite-vue.js (que je ne connaissait pas, je vais regarder). Grâce à ça, je suis également tombé sur stimulus, qui me semble dans l’esprit assez proche de ce que tu proposes, @viki53. En tout cas, quelque chose de léger

La compilation statique me semble mal se marrier avec le système de template côté Flask, mais je peux me tromper

Je ne suis pas sûr de voir ce qui te pose problème. En l’occurrence, la syntaxe pour les templates Alpine est très similaire à celle de Vue. Tu auras dans tous les cas des trucs à ajouter dans tes balises.

Ce que j’aime bien dans petite-vue (et stimulus, du coup), c’est que tu as encore une certaine séparation entre javascript et HTML (même si évidement, il faut adapter le HTML en conséquence) grace à un objet dédié (souvent nommé Application, il semblerait). C’est un choix purement philosophique, à ce niveau là

Je comprend mieux la problématique maintenant, tu veux utiliser Jinja2 en plus d’un framework JS.

Par simplicité, oui (d’autant que Javascript et moi, on est pas forcément copains, mais c’est justement l’occasion pour moi d’y travailler ). Dans un second temps, vu que tout est à peu près dans l’API Rest, je pourrais ensuite envisager une transition

Il me semble qu’il n’existe pas vraiment de librairie permettant d’utiliser Jinja en Javascript. Il y a jinja-js mais ce n’est plus maintenu depuis sept ans. Apparemment, liquid.js est assez proche. Svelte aussi, relativement.

Dans tous les cas, j’ai peut-être mal compris ce que tu voulais dire, mais il ne faut pas faire de confusion : dans ton architecture avec une API qui répond du JSON et un templating côté frontend, le moteur de templating présent dans ta technologie serveur, ici Flask, est hors de propos, puisque tu réponds du JSON et pas du HTML, donc il n’y a pas "d’intégration au système de template de Flask" à chercher, à part éventuellement une similarité de syntaxe.

Il y a toujours le bon vieux jQuery. C’est assez dépassé car le lien entre données et vue reste manuel, mais c’est quand même mieux manipulable que les fonctions standard getElementById, etc.

Ou alors, si ça suffit à ton besoin, tu peux aussi rendre ton interface avec Flask et y mettre un bête setTimeout qui rafraîchit la page.

Quant à l’industrialisation qui est venue se greffer autour de Javascript depuis une dizaine d’années, npm, webpack & co, effectivement c’est déroutant quand tu veux juste faire une petite interface simple que tu as eu l’habitude de faire en intégrant une simple balise script dans du HTML, et ça ajoute une learning curve entre toi et ton projet, mais en réalité ce n’est pas très compliqué, ça apporte des choses bénéfiques pendant le développement (gestion des dépendances, linting, live-reload, …), ça ne change rien une fois en production (il faut voir ça comme un environnement de développement, une fois que tu build ton app tu obtiens du statique que tu peux servir avec ton instance Flask si tu veux), et tu n’es pas obligé de les utiliser. Je sais que tu peux par exemple utiliser Vue.js via un simple ajout d’une balise <script>, à l’ancienne. Cela dit, ça peut te sembler plus simple peut-être, mais je ne suis pas sûr que ça le soit vraiment.

À noter qu’on a querySelector et querySelectorAll depuis un moment pour avoir un fonctionnement proche de jQuery.

On peut d’ailleurs créer des raccourcis facilement du genre const $ = document.querySelector, $$ = document.querySelectorAll; si on veut une syntaxe courte.

Attention, ne me faites pas dire ce que je n’ai pas dit: j’ai déjà eu l’occasion de tâter npm et co' dans différents cadres (entre autre celui de ZdS!) et je ne doute pas de l’intérêt de telles technologies, ni de l’intérêt de compiler/transpiler mon javascript.¹ Ceci dit, dans le cadre de ce projet en particulier, pour lequel j’en serai l’utilisateur principal et qui est (principlament) prévu pour tourner en local… Je recherche quelque chose de simple et de léger dans un premier temps. Pour la même raison, j’ai également envie d’avoir quelque chose dont le backend reste géré par Flask, génération de HTML compris (je sais très bien que maintenant, on fait des machins full-javascripts qui font des appels REST, et que c’est relativement simple à dévelloper, mais encore une fois, le tank, la mouche, toussa).

Du coup, je recherche réellement quelque chose qui oscille entre jquery (ou du vanilla JS, je n’ai rien contre) et quelque chose d’un tout petit peu plus haut niveau tel petitevue. Je vais d’ailleurs essayer ce dernier prochainement, à voir si c’est pas trop buggé

Salut,

Alors je ne suis pas expert, mais dans la boîte où je suis, j’ai bossé sur un projet en Django et pour avoir un rendu plus dynamique sur un formulaire j’ai dû intégrer VueJS sur la page de celui ci et uniquement sur cette page.

Du coup comme l’a dit @Zephyr y avait juste à importer Vue dans une balise script à l’ancienne et à l’utiliser dans le template de Django.

Je ne connais pas Flask mais si ça peut aider à trancher !

@chrichrisp: Tu as tout à fait raison.

Ici Svelte n’a pas trop sa place. Éventuellement en utilisant composants web comme dit viki53.

L’idée que j’ai derrière la tête, c’est que ça soit un peu dynamique, autrement dit d’utiliser Javascript pour mettre dynamiquement à jour les éléments via des appels à l’API. Je ne souhaite ceci dit pas en arriver au point d’avoir une single page application.

J’ai eu un besoin similaire l’année dernière. Je bossais sur une app Django « classique » (SSR), mais j’avais besoin d’un peu de dynamisme par-ci par-là, notamment au niveau des formulaires ou autres éléments d’interaction avec l’utilisateur.

Comme je ne voulais pas (et connaissais pas) de framework JS complet, j’ai utilisé un toolkit qui répondait pile à mes besoin : htmx. J’étais plutôt satisfait dans l’ensemble :

• aucun problème de litige avec les templates Django (pareil avec Jinja2) ;
• pas de JS à écrire, seulement des endpoints à prévoir (dans mon cas, je préfère écrire du Python backend que du JS frontend donc aucun souci) ;
• pas de npm ou autre : juste intégrer le fichier JS est c’est parti.

Le frontend n’est pas ma spécialité donc je laisse les autres se prononcer sur des éléments peu orthodoxes qui, je pense, méritent d’être indiqués :

• ça fonctionne sur un principe HTML over the Wire (ce qui pour moi est une bonne chose car ça se composait très bien avec mes fragments de templates Django/Jinja2) ;
• il est possible de hooker certains comportements de htmx pour des besoins un peu poussés, mais il faut alors écrire du JS dans ce cas.