Waouh, quel programme formidable. On dirait que son créateur est norvégien. Créer un programme d’une telle qualité juste pour le plaisir, puis le rendre public… c’en est presque admirable. Ça me rappelle une fois de plus que le monde est vaste et qu’il y a énormément de génies. Les développeurs coréens aussi devraient redoubler d’efforts, créer quelque chose d’aussi chouette et le publier.
Le concept en lui-même m’était déjà arrivé sous les yeux de temps en temps, mais j’ai été surpris par la qualité de la page web, à la fois amusante et très bien conçue pour permettre d’en tester les fonctionnalités d’un seul coup d’œil.
Alors que je somnolais, ce fut une expérience amusante qui m’a instantanément réveillé.
À l’origine, dans les cas où l’on envisageait un SPA uniquement pour son côté « fluide », j’aurais simplement renoncé à cette fluidité et développé en MPA, donc j’avoue que je n’y adhère pas vraiment...
Honnêtement, il y avait aussi quelques personnes qui n’avaient rien de spécial à faire mais faisaient tourner plusieurs sessions de force pour rentabiliser au maximum leur abonnement...
Parmi les cas que vous avez présentés, le seul qu’on ne puisse pas remplacer par des SPA avec des view transitions et autres, ce sont les outils de collaboration en temps réel, et la grande majorité des sites web ne sont pas des outils de collaboration en temps réel. Les sites marketing, les tableaux de bord et les apps de commerce peuvent tous être construits en excluant les frameworks SPA, tout en respectant les conditions suivantes : rendu côté serveur, vraies pages, animations basées sur CSS, préchargement intentionnel et recours minimal au JS. Il y a aussi Hotwire, porté par l’écosystème Rails, qui vise justement cela, avec des cas de production comme Basecamp et Hey. La gestion d’état ? Sauf pour quelque chose comme un outil de collaboration en temps réel, des méthodes côté serveur comme les paramètres d’URL ou les sessions serveur, ou encore le stockage local, suffisent largement. Il existe clairement des cas où des SPA sont adoptées pour les transitions de page (comme le site officiel d’AGF, où Astro aurait largement suffi mais où React a quand même été adopté), et on ne peut pas nier que les transitions de page sont souvent citées comme l’un des principaux avantages des SPA.
Il est clair que certains adoptent un framework SPA juste pour une interaction fluide. Pourtant, une grande partie des sites utilisant des SPA n’ont pas besoin d’interactions complexes.
Tout n’est pas un endofoncteur. Les types avec plusieurs paramètres de type, comme Result<T, E>, ne sont pas de la forme 𝒞 → 𝒞 mais Result : 𝒞 × 𝒞 → 𝒞, donc ce genre de chose est un bifoncteur.
C’est tout à fait exact !
Je pense qu’il y a eu un malentendu dans le processus d’application à Rust d’un contenu rédigé dans un autre langage.
Comme le système de types de Rust constitue une seule catégorie, il semble que la distinction entre endofoncteur et foncteur ordinaire n’ait pas vraiment de sens.
C’est dommage qu’il n’y ait pas de fonction de commentaire sur le blog, mais je vais demander s’il est possible de solliciter une correction.
Rien qu’en voyant le site de démo, c’est extrêmement impressionnant. C’est fou de voir autant de fonctionnalités prises en charge avec un code aussi court.
Cette personne semble parler du coût de l’abonnement à l’IDE. FLCC n’est pas proposé dans la version gratuite.
Mais ce n’est pas non plus pour ça seulement que les gens paient.
C’est impressionnant.
Waouh, quel programme formidable. On dirait que son créateur est norvégien. Créer un programme d’une telle qualité juste pour le plaisir, puis le rendre public… c’en est presque admirable. Ça me rappelle une fois de plus que le monde est vaste et qu’il y a énormément de génies. Les développeurs coréens aussi devraient redoubler d’efforts, créer quelque chose d’aussi chouette et le publier.
Là-bas aussi, ils sont nombreux, mais au final ce qu’ils font, c’est du pareil au même ici comme là-bas lol
Une scène familière d’un certain pays dont le nom commence par « Han » et se termine par « guk ».
Le concept en lui-même m’était déjà arrivé sous les yeux de temps en temps, mais j’ai été surpris par la qualité de la page web, à la fois amusante et très bien conçue pour permettre d’en tester les fonctionnalités d’un seul coup d’œil.
Alors que je somnolais, ce fut une expérience amusante qui m’a instantanément réveillé.
À l’origine, dans les cas où l’on envisageait un SPA uniquement pour son côté « fluide », j’aurais simplement renoncé à cette fluidité et développé en MPA, donc j’avoue que je n’y adhère pas vraiment...
Honnêtement, il y avait aussi quelques personnes qui n’avaient rien de spécial à faire mais faisaient tourner plusieurs sessions de force pour rentabiliser au maximum leur abonnement...
Parmi les cas que vous avez présentés, le seul qu’on ne puisse pas remplacer par des SPA avec des view transitions et autres, ce sont les outils de collaboration en temps réel, et la grande majorité des sites web ne sont pas des outils de collaboration en temps réel. Les sites marketing, les tableaux de bord et les apps de commerce peuvent tous être construits en excluant les frameworks SPA, tout en respectant les conditions suivantes : rendu côté serveur, vraies pages, animations basées sur CSS, préchargement intentionnel et recours minimal au JS. Il y a aussi Hotwire, porté par l’écosystème Rails, qui vise justement cela, avec des cas de production comme Basecamp et Hey. La gestion d’état ? Sauf pour quelque chose comme un outil de collaboration en temps réel, des méthodes côté serveur comme les paramètres d’URL ou les sessions serveur, ou encore le stockage local, suffisent largement. Il existe clairement des cas où des SPA sont adoptées pour les transitions de page (comme le site officiel d’AGF, où Astro aurait largement suffi mais où React a quand même été adopté), et on ne peut pas nier que les transitions de page sont souvent citées comme l’un des principaux avantages des SPA.
Il est clair que certains adoptent un framework SPA juste pour une interaction fluide. Pourtant, une grande partie des sites utilisant des SPA n’ont pas besoin d’interactions complexes.
Tout n’est pas un endofoncteur. Les types avec plusieurs paramètres de type, comme
Result<T, E>, ne sont pas de la forme 𝒞 → 𝒞 maisResult : 𝒞 × 𝒞 → 𝒞, donc ce genre de chose est un bifoncteur.C’est tout à fait exact !
Je pense qu’il y a eu un malentendu dans le processus d’application à Rust d’un contenu rédigé dans un autre langage.
Comme le système de types de Rust constitue une seule catégorie, il semble que la distinction entre endofoncteur et foncteur ordinaire n’ait pas vraiment de sens.
C’est dommage qu’il n’y ait pas de fonction de commentaire sur le blog, mais je vais demander s’il est possible de solliciter une correction.
C’est un bon article ! En revanche, l’explication concernant l’endopunctor comporte une erreur, donc il serait préférable de la corriger : https://x.com/simnalamburt/status/1950074970647761168?s=46
king - man + woman = queen
On dirait qu’il a toutes les fonctionnalités qu’on aimerait avoir. À lui seul, il fait tout le boulot d’un NAS.
Rien qu’en voyant le site de démo, c’est extrêmement impressionnant. C’est fou de voir autant de fonctionnalités prises en charge avec un code aussi court.
Comme quoi, NamuWiki...
Je ne vois pas bien comment la vérification d’âge et la protection de la vie privée peuvent aller ensemble..
Au moment où on s’authentifie, ça ne revient pas au minimum à laisser une fois sa signature là-bas ?
Si on veut vraiment protéger la vie privée, il faut pouvoir l’utiliser anonymement
Excellent. J’aime beaucoup ce genre d’approche.
Une méthode d’optimisation non-ML bienvenue.
Cette personne semble parler du coût de l’abonnement à l’IDE. FLCC n’est pas proposé dans la version gratuite.
Mais ce n’est pas non plus pour ça seulement que les gens paient.