En vrai ça a l'air sympa mais ça soulève plein de questions : 1) Comment on ferait pour scinder son HTML en plusieurs composants réutilisables au lieu d'un seul fichier index.html inbuvable ? 2) Dans chaque fichier python tu aurais ce boilerplate (petit, certes) "prune = Prune(global_scope=globals(), ...)" ? 3) Dans un fichier python différent tu devrais te souvenir que tel nom de variable est déjà présent dans le store pour pas avoir de conflit ? 4) Dans le template html ça serait cool de pouvoir interpoler (exemple avec des {{ store.x }} qui serait remplacé par la variable x) 5) Si tu as un @notify ça rerend TOUT l'html ou bien seulement la partie modifiée ? 6) Comment tu appelles ton back ? (à moins que ton back soit justement les fichiers python mais je suis pas certain d'avoir saisi) Perso pour y croire il me faudrait un cas simple avec plusieurs fichiers python, un traitement de backend avec une base de données par exemple, une possibilité de scinder la logique, et un moyen de re-rendre sélectivement l'html de manière simple. Mais au final quelle est la principale différence avec un backend en Java embarquant des JSP, ou bien avec un backend en php ? Tu vends la chose comme "Avec ça, plus besoin de s'embêter à trouver comment transmettre la data entre les composants !". Mais dans ton exemple tu n'as qu'un seul HTML unique. Tu peux faire en React/Vue/Angular/Svelte/xxx un unique composant et tu n'auras pas de problème de transmission de data non plus ^^
🎉 ça va cartonner ton truc ! C’est simple, mais pas simpliste. Bravo !! J’ai pas l’habitude du python, mais j’ai tout compris, c’est du vuejs en plus fun !
Ce serait super de créer maintenant un tutoriel vidéo sur la documentation expliquer page par page en vidéo et faire des projets de site dynamique, de site e-commerce dessus.
Salut Loïc ! Merci pour la vidéo, mais ça fait un moment qu'on attend la suite pour Rust j'ai hâte de découvrir les nouvelles notions pourquoi pas des petits projets....
Une chose est de faire découvrir une nouvelle techno, mais c'est une autre chose quand tu essaies de boycotter l'autre. Pour un débutant en React c'est facile de gober cette comparaison, mais pour quelqu'un qui a de l'expérience en React, on voit clairement que tu es loin de comprendre et penser React.
Pour moi ton framework n'est pas un conçurent à react car totalement différent, déjà je crois que après chaque mis à jour tu reinterprete tout le html. Il n'y a pas de composant. Le paradigme est totalement différent par exemple du peut pas faire des bibliothèques d'éléments d'interface avec Prune. Prune est "un retour en arrière" (bien pensé) fait pour des applications avec très peu l'interactivité et pour les personnes qui ont déjà leur backend en python.
0:24 Premier problème, aucun framework dans ta liste. As-tu essayé Angular? 0:40 Oui, c'est le principe. Si tu veux les partager, stocke les dans un service. 2:09 Effectivement, un même langage des deux coté simplifie les choses, et à choisir, j'aurais plutôt mis TS partout. 2:50 Ok, mais dans ce cas tu ne fais que retourner 10 ans en arrière, à l'époque où ton PHP back générait des pages HTML :s 3:17 Oui effectivement, c'est une horreur de react. Mais encore une fois, regarde du coté d'un Framework type Angular, tout est séparé en 4 : html, ts, scss et fichier de test. J'arrête là, mais il y a pas mal de choses qui sont déjà présentes et bien faites dans des technologies plus sérieuses que React. Cela n'enlève rien au caractère passionnant de tout ce que tu as fait, ce sera probablement un outil très pratique pour des cas précis comme le tien :)
Merci pour ton commentaire, oui en effet on peut croire que c'est un retour en arrière, mais j'ai pas eu l'occasion ici de montrer comment intégrer ça avec une page rendue par un serveur, l'idée c'est de se dire que la page doit être rendu avec le html de façon statique et ensuite de la rendre dynamique avec PrunePy. (C'est surtout pratique pour le SEO car le rendu est déjà fait et ça évite de se prendre la tête avec le rendu côté serveur ou client).
Pour le second point, je suis d'accord, y'a tellement de manières différentes pour sortir de la data d'un composant (hooks, composables, store, models, 2 way bindings, events, signaux (composition api avec vue), proxy, provide/inject, etc...) Donc, non la data n'est pas difficilement transmissible entre composants.
3:17 pour ajouter, c'est partiellement faux ce que dit Loïc. On peut faire des tests unitaires sur du react ou du vue sans navigateur. Tu montes ton composant avec du js-dom ou du happy-dom (vitest ou jest utilise ça). Tu peux tester très rapidement et simplement tout ton code.
@@louismazel Oui mais ce que je voulais dire c'est que tu restes dépendant du DOM pour tester une logique qui ne devrait pas l'être, c'est ce que je montre dans l'exemple de fin avec du code, une logique qui est indépendante du DOM
@@LoicRust Tu es dépendant du DOM si tu ne découpes pas bien ton code. Si tu fais des map ou logiques directement dans le JSX, c'est pas le cas oui. Mais un bon code est un code bien découpé et donc testable unitairement. Malgré tout, les tests sur le DOM restent inévitable pour avoir une application bien testée.
En vrai ça a l'air sympa mais ça soulève plein de questions :
1) Comment on ferait pour scinder son HTML en plusieurs composants réutilisables au lieu d'un seul fichier index.html inbuvable ?
2) Dans chaque fichier python tu aurais ce boilerplate (petit, certes) "prune = Prune(global_scope=globals(), ...)" ?
3) Dans un fichier python différent tu devrais te souvenir que tel nom de variable est déjà présent dans le store pour pas avoir de conflit ?
4) Dans le template html ça serait cool de pouvoir interpoler (exemple avec des {{ store.x }} qui serait remplacé par la variable x)
5) Si tu as un @notify ça rerend TOUT l'html ou bien seulement la partie modifiée ?
6) Comment tu appelles ton back ? (à moins que ton back soit justement les fichiers python mais je suis pas certain d'avoir saisi)
Perso pour y croire il me faudrait un cas simple avec plusieurs fichiers python, un traitement de backend avec une base de données par exemple, une possibilité de scinder la logique, et un moyen de re-rendre sélectivement l'html de manière simple.
Mais au final quelle est la principale différence avec un backend en Java embarquant des JSP, ou bien avec un backend en php ?
Tu vends la chose comme "Avec ça, plus besoin de s'embêter à trouver comment transmettre la data entre les composants !". Mais dans ton exemple tu n'as qu'un seul HTML unique.
Tu peux faire en React/Vue/Angular/Svelte/xxx un unique composant et tu n'auras pas de problème de transmission de data non plus ^^
🎉 ça va cartonner ton truc !
C’est simple, mais pas simpliste. Bravo !!
J’ai pas l’habitude du python, mais j’ai tout compris, c’est du vuejs en plus fun !
C'est incroyable bravo, j'espère qu'un grand nombre puisse y adhérer.
C’est de joli travail, bravo ! 🎉
Bon travail.
J'ai hâte de voir la suite
On est là avant que ton framework perce 🎉🎉🎉❤
Merci ! Ça fait chaud au cœur 🤩
Bravo 👏🏻👍🏻 et je te souhaite une bonne continuation, en tout cas je me suis abonnée pour voir le suivi de ton idée.
C'est une très belle alternative pour ceux qui souhaite rester sous python
"Rester sous python" mdr appart du prototypage faut oublier cette merde.
Ce serait super de créer maintenant un tutoriel vidéo sur la documentation expliquer page par page en vidéo et faire des projets de site dynamique, de site e-commerce dessus.
C'est beaucoup trop stylé wtf. ça me donne premier degré envie d'utiliser ça comme techno principale. ça t'a pris combien de temps à faire ?
Merci 🥳! La première version je l'ai sortie en 2semaines, puis je l'ai amélioré quand j'avais le temps, le tout fait seulement 220 lignes de code. 😊
Salut Loïc !
Merci pour la vidéo, mais ça fait un moment qu'on attend la suite pour Rust j'ai hâte de découvrir les nouvelles notions pourquoi pas des petits projets....
Bravo
Une chose est de faire découvrir une nouvelle techno, mais c'est une autre chose quand tu essaies de boycotter l'autre. Pour un débutant en React c'est facile de gober cette comparaison, mais pour quelqu'un qui a de l'expérience en React, on voit clairement que tu es loin de comprendre et penser React.
Tellement vrai
Ta façon de faire est très compréhensible et pédagogique 😊😊😊
Un lien discord pour Rust ???
Super !
Alt Z (ou alors trouver le script d'automatisme) pour formater le texte dans VS Code ou VS Codium(que je préfère).
Pour moi ton framework n'est pas un conçurent à react car totalement différent, déjà je crois que après chaque mis à jour tu reinterprete tout le html. Il n'y a pas de composant. Le paradigme est totalement différent par exemple du peut pas faire des bibliothèques d'éléments d'interface avec Prune.
Prune est "un retour en arrière" (bien pensé) fait pour des applications avec très peu l'interactivité et pour les personnes qui ont déjà leur backend en python.
Super comme projet, ça me fait penser à HTMX mais sans le serveur 👍
Merci, oui le but c'est de rester dans une stack minimaliste
do you know redux or zustand ?
👍
Si je vais ajouter tailwind je crois les balises seront trop long😢
Justement j'ai quelque chose qui arrive aussi à ce sujet ;)
c'est pas du livewire version python ?
Livewire utilise un serveur back pour gérer la logique, ici tout est géré dans le front
C'est bien mais je crois pas que c'est performant parce que surement ça utilise du WebAssembly contrairement à du javascript qui est natif
Oublie react pour ton vraimework pas maintenant
0:24 Premier problème, aucun framework dans ta liste. As-tu essayé Angular?
0:40 Oui, c'est le principe. Si tu veux les partager, stocke les dans un service.
2:09 Effectivement, un même langage des deux coté simplifie les choses, et à choisir, j'aurais plutôt mis TS partout.
2:50 Ok, mais dans ce cas tu ne fais que retourner 10 ans en arrière, à l'époque où ton PHP back générait des pages HTML :s
3:17 Oui effectivement, c'est une horreur de react. Mais encore une fois, regarde du coté d'un Framework type Angular, tout est séparé en 4 : html, ts, scss et fichier de test.
J'arrête là, mais il y a pas mal de choses qui sont déjà présentes et bien faites dans des technologies plus sérieuses que React.
Cela n'enlève rien au caractère passionnant de tout ce que tu as fait, ce sera probablement un outil très pratique pour des cas précis comme le tien :)
Merci pour ton commentaire, oui en effet on peut croire que c'est un retour en arrière, mais j'ai pas eu l'occasion ici de montrer comment intégrer ça avec une page rendue par un serveur, l'idée c'est de se dire que la page doit être rendu avec le html de façon statique et ensuite de la rendre dynamique avec PrunePy. (C'est surtout pratique pour le SEO car le rendu est déjà fait et ça évite de se prendre la tête avec le rendu côté serveur ou client).
Pour le second point, je suis d'accord, y'a tellement de manières différentes pour sortir de la data d'un composant (hooks, composables, store, models, 2 way bindings, events, signaux (composition api avec vue), proxy, provide/inject, etc...)
Donc, non la data n'est pas difficilement transmissible entre composants.
3:17 pour ajouter, c'est partiellement faux ce que dit Loïc. On peut faire des tests unitaires sur du react ou du vue sans navigateur. Tu montes ton composant avec du js-dom ou du happy-dom (vitest ou jest utilise ça). Tu peux tester très rapidement et simplement tout ton code.
@@louismazel Oui mais ce que je voulais dire c'est que tu restes dépendant du DOM pour tester une logique qui ne devrait pas l'être, c'est ce que je montre dans l'exemple de fin avec du code, une logique qui est indépendante du DOM
@@LoicRust Tu es dépendant du DOM si tu ne découpes pas bien ton code. Si tu fais des map ou logiques directement dans le JSX, c'est pas le cas oui.
Mais un bon code est un code bien découpé et donc testable unitairement.
Malgré tout, les tests sur le DOM restent inévitable pour avoir une application bien testée.
Si le problème c'est juste de passer des données entre composants de manière générale, tu peux faire un useContext🤦🏾♂️🤦🏾♂️🤦🏾♂️🤦🏾♂️
Arrête le python et dirige toi sur des langages typés
Je fais du Rust 😅
N'importe quoi