je fais du nuxt js coté front mais je suis pret à tester ton framework vu que je suis plus un dev back-end qui utilise django , bonne continuation à toi et j'attends la suite , on verra peut etre la révolution pour ceux qui n'aiment pas le js , tu viens de gagner un abonné
🎉 ç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 !
Je suis un développeur JavaScript de base et j'aime bien JavaScript par rapport a python mais je peux dire que tu as souligner des problèmes tres important dans le développement en JavaScript et ça serai un plaisir d'être parmi les premiers a contribué et a travaillé avec ce framework 🎉
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.
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....
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 ^^
J'ai les mêmes questionnements, surtout qu'aujourd'hui on a le ContextAPI dans React, et les stores dans tout les autres grands framework pour gérer le state et la transmission de données en dehors des composants et faire passer les données aux composants sans passer par les props :/ Je trouve qu'il parle de problèmes qu'on se posait il y a 4 ans, que la communauté à résolu depuis...
Salut, Merci pour ce commentaire, Beaucoup de points sont très intéressant et je prépare une prochaine vidéo pour répondre à toutes tes questions (que pas mal de gens doivent se poser aussi). Mon exemple était vraiment simple ici juste pour présenter le concept, tu verras l’intérêt et le fonctionnement de cette approche sur un exemple plus concret dans une prochaine vidéo, ce sera surement un exemple sur un site e-commerce. Encore merci d'avoir pris le temps de rédiger un tel commentaire 🙏
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.
pour passer des données de façons global tu n'es pas sensé passer par des props que du faite erité a 300 enfant ou inversement normalement tout les framework on un systeme de context global par exemple en svelte tu utilise le ce qu'on appelle le store, le but de ces systemes est la pour isolé les variables dans les composants afin d'évité par exemple que dans le scope global il y ai deux composant qui possede le meme nom de variable et rentre en colision deuxiement les plus grosse companie évite generalement de melanger le front et le back en créant une api et une interface distinct ca te permet de tester ta logique server par exemple avec post man pour faire des requete api et developper ton front avec svelte aussi ca te permet par exemple si tu prefere python, ruby, php de travailler coté serveur avec le language de toin choix. Apres il est vrais que le jsx est vraiment verbeux et pas cool a travailler dessus je prefere svelte qui est plus light et aussi le fait qu'il y a un compilateur rend le code bien plus optimiser que passer par un code python coté server qui est executer a chaque requete et en plus un code interpreteur client. Malgré tout ca a l'air d un projet assez cool bonne chance 👍
Perso je suis adepte de svelte et je trouve prune beaucoup trop complexe ça règles des problèmes qui n’existent pas avec svelte donc pas utile pour moi aujourd’hui, mais je félicite le travail quand même !
Salut ! Moi aussi j'étais un grand fan de svelte et lorsque tu commences à avoir une logique complexe c'est une autre histoire... peux tu me dire sur quel point tu trouves prune complexe si tu l'as essayé ? Merci pour ton commentaire
@ le fait qu’avec svelte 5 tu puisse isoler tes logiques dans des fichiers svelte.ts/js rend le code isolable et te permet de le tester beaucoup plus simplement. Je n’ai pas (encore) testé, mais déjà je suis un peu embêté par le notify qui va render le composant ( ou la page entière idk ) je suppose que ça va faire l’update même si rien n’a changé, peut-être faudrait il donner la possibilité de fine tuner ça en donnant une fonction render manuelle permettant un rendu au cas par cas. Ensuite l’installation du plugin est très verbeuse il faut ajouter beaucoup de chose au HTML peut-être rendre ça dynamique via un compiler. Anyway c’est très bien pour un début !
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.
Moi je préfère le bon vieux php et pour le front un bon vieux jquery. Récemment j'ai découvert un nouveau jquery en ultra minimaliste (moins de 20ko) ça s'appelle Cash.js
je fais du nuxt js coté front mais je suis pret à tester ton framework vu que je suis plus un dev back-end qui utilise django , bonne continuation à toi et j'attends la suite , on verra peut etre la révolution pour ceux qui n'aiment pas le js , tu viens de gagner un abonné
C'est incroyable bravo, j'espère qu'un grand nombre puisse y adhérer.
🎉 ç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 !
On est là avant que ton framework perce 🎉🎉🎉❤
Merci ! Ça fait chaud au cœur 🤩
Bravo pour ton travail en tout cas, c'est vraiment bien pensé. En tant qu'amoureux d'AlpineJS et pythoniste, je vais m'amuser avec ^^
Je suis un développeur JavaScript de base et j'aime bien JavaScript par rapport a python mais je peux dire que tu as souligner des problèmes tres important dans le développement en JavaScript et ça serai un plaisir d'être parmi les premiers a contribué et a travaillé avec ce framework 🎉
Top ! C'est par ici : dekoding.fr/join/
C’est de joli travail, bravo ! 🎉
Je trouve que @notify devrait être là par défaut. C'est cool
C'est bien, je vois que prune joue le rôle d'un global state! Il y a encore du chemin a faire, sur le templating bravo
J'ai hâte de voir la suite
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.
@@mwlulud2995 cette même chose qui te permet de m'écrire ce commentaire et de voir cette video ? Je te rappelle que TH-cam est coder en Python
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
Complètement d'accord
Bon travail.
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....
Bravo
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. 😊
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 ^^
J'ai les mêmes questionnements, surtout qu'aujourd'hui on a le ContextAPI dans React, et les stores dans tout les autres grands framework pour gérer le state et la transmission de données en dehors des composants et faire passer les données aux composants sans passer par les props :/
Je trouve qu'il parle de problèmes qu'on se posait il y a 4 ans, que la communauté à résolu depuis...
Salut, Merci pour ce commentaire,
Beaucoup de points sont très intéressant et je prépare une prochaine vidéo pour répondre à toutes tes questions (que pas mal de gens doivent se poser aussi).
Mon exemple était vraiment simple ici juste pour présenter le concept, tu verras l’intérêt et le fonctionnement de cette approche sur un exemple plus concret dans une prochaine vidéo, ce sera surement un exemple sur un site e-commerce.
Encore merci d'avoir pris le temps de rédiger un tel commentaire 🙏
@@LoicRust Agréablement surpris de voir que tu réagis aussi bien, à ta place je me serais braqué sur moi-même ^^' je regarderai :)
do you know redux or zustand ?
Super comme projet, ça me fait penser à HTMX mais sans le serveur 👍
Merci, oui le but c'est de rester dans une stack minimaliste
Ta façon de faire est très compréhensible et pédagogique 😊😊😊
Un lien discord pour Rust ???
Il aurait dit une librairie encore oui mais framework. Je pense pas.
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).
C'est bien pour un full stack Python, mais les arguments me semble peux convainquant par rapport aux outils js existant, comme Solidjs ou Angular 19.
Mais la doc, le site tu le fais en Réact franchement ? j'allais en venir et pour le deploiement ?
Si je vais ajouter tailwind je crois les balises seront trop long😢
Justement j'ai quelque chose qui arrive aussi à ce sujet ;)
👍
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.
Et l'API context ? Et Redux tool kit ? 😑
pour passer des données de façons global tu n'es pas sensé passer par des props que du faite erité a 300 enfant ou inversement normalement tout les framework on un systeme de context global par exemple en svelte tu utilise le ce qu'on appelle le store, le but de ces systemes est la pour isolé les variables dans les composants afin d'évité par exemple que dans le scope global il y ai deux composant qui possede le meme nom de variable et rentre en colision deuxiement les plus grosse companie évite generalement de melanger le front et le back en créant une api et une interface distinct ca te permet de tester ta logique server par exemple avec post man pour faire des requete api et developper ton front avec svelte aussi ca te permet par exemple si tu prefere python, ruby, php de travailler coté serveur avec le language de toin choix. Apres il est vrais que le jsx est vraiment verbeux et pas cool a travailler dessus je prefere svelte qui est plus light et aussi le fait qu'il y a un compilateur rend le code bien plus optimiser que passer par un code python coté server qui est executer a chaque requete et en plus un code interpreteur client. Malgré tout ca a l'air d un projet assez cool bonne chance 👍
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
si tu as besoin des contirbuteur je suis partant pour bosser avec toi
Avec plaisir ! C'est par ici : dekoding.fr/join/
Perso je suis adepte de svelte et je trouve prune beaucoup trop complexe ça règles des problèmes qui n’existent pas avec svelte donc pas utile pour moi aujourd’hui, mais je félicite le travail quand même !
Salut ! Moi aussi j'étais un grand fan de svelte et lorsque tu commences à avoir une logique complexe c'est une autre histoire... peux tu me dire sur quel point tu trouves prune complexe si tu l'as essayé ? Merci pour ton commentaire
@ le fait qu’avec svelte 5 tu puisse isoler tes logiques dans des fichiers svelte.ts/js rend le code isolable et te permet de le tester beaucoup plus simplement.
Je n’ai pas (encore) testé, mais déjà je suis un peu embêté par le notify qui va render le composant ( ou la page entière idk ) je suppose que ça va faire l’update même si rien n’a changé, peut-être faudrait il donner la possibilité de fine tuner ça en donnant une fonction render manuelle permettant un rendu au cas par cas.
Ensuite l’installation du plugin est très verbeuse il faut ajouter beaucoup de chose au HTML peut-être rendre ça dynamique via un compiler. Anyway c’est très bien pour un début !
C'est bien mais je crois pas que c'est performant parce que surement ça utilise du WebAssembly contrairement à du javascript qui est natif
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.
Tu as essayé react mais à mon sens tu ne le connais pas. Ce que tu présentes comme pratique est certes possible mais ce n'est pas l'usage.
Oublie react pour ton vraimework pas maintenant
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
Moi je préfère le bon vieux php et pour le front un bon vieux jquery. Récemment j'ai découvert un nouveau jquery en ultra minimaliste (moins de 20ko) ça s'appelle Cash.js