Clone de Tumblr en JS avec Lovable
Alexis implémente le même clone de Tumblr mais cette fois avec Loveable, démontrant la rapidité de développement cloud vs local tout en révélant les limitations de complétude fonctionnelle des outils no-code haut niveau.
À propos de cette session
Alexis débute en réutilisant la spécification Claude de la session Ruby, mais épurée des détails techniques spécifiques à Rails. Il insiste sur le fait que Loveable impose sa stack technique JavaScript/React, éliminant les choix technologiques.
La création du projet dans Loveable est immédiate. En quelques secondes, une interface brutaliste apparaît avec du contenu contextuel, des icônes de types de posts, des dates formatées et même des références au brutalisme dans le contenu généré. L'interface d'administration est également fonctionnelle d'emblée.
Alexis teste l'upload d'images qui fonctionne instantanément avec prévisualisation. Il crée un post avec image, tags multiples et constate que l'interface publique affiche correctement les contenus. Cependant, il découvre rapidement que sans base de données connectée, les données ne persistent pas entre les sessions.
Face aux limitations de son plan Supabase gratuit, Alexis demande à l'agent d'implémenter le Local Storage comme solution temporaire. L'agent adapte rapidement l'application pour persister les données localement, rendant le prototype fonctionnel pour une session donnée.
Les tests révèlent des fonctionnalités incomplètes : les tags ne sont pas cliquables, certains types de posts (citations) ne sont qu'en développement partiel. L'agent n'a implémenté que les posts texte et images malgré les spécifications plus larges.
La session se termine avec un prototype visuellement impressionnant mais fonctionnellement incomplet, nécessitant encore du travail pour connecter une vraie base de données et finaliser toutes les fonctionnalités demandées.
Points clés
- Aspects techniques et méthodologiques*
- La réutilisation de spécifications entre outils accélère le développement multi-plateforme
- Les outils cloud éliminent complètement la friction d'environnement de développement
- Le Local Storage peut servir de solution temporaire pour prototyper sans backend
- L'adaptation des spécifications selon les contraintes techniques de chaque outil est cruciale
- Limitations des outils découvertes*
- Loveable impose ses choix technologiques sans possibilité de personnalisation
- L'agent peut implémenter partiellement les fonctionnalités sans signalement clair
- La dépendance aux services tiers (Supabase) peut bloquer le développement complet
- Les limitations de plans gratuits impactent directement les capacités de test
- Bonnes pratiques identifiées*
- Adapter le brief technique selon les contraintes de chaque plateforme
- Utiliser le Local Storage comme solution de contournement pour les prototypes
- Tester systématiquement chaque fonctionnalité promise par l'agent
- Prévoir des alternatives aux services payants pour les phases de test
- Problèmes récurrents du vibe coding*
- Les agents peuvent livrer des fonctionnalités incomplètes sans notification explicite
- La rapidité apparente cache parfois des implémentations partielles
- La dépendance aux écosystèmes fermés limite la flexibilité technique
- L'absence de vraie base de données limite l'utilisation réelle du prototype
- Insights sur l'architecture, sécurité, performance*
- Le Local Storage convient uniquement pour des prototypes mono-utilisateur
- L'architecture imposée par Loveable (React/JavaScript) limite les choix d'optimisation
- L'absence de contrôle sur le backend pose des questions de sécurité long terme
- Le déploiement automatique simplifie la distribution mais réduit le contrôle
- Leçons sur la collaboration avec l'IA*
- Claude 4 génère du contenu contextuel plus riche que Gemini 2.5 Pro
- L'IA s'adapte rapidement aux contraintes techniques changeantes (Local Storage)
- Elle peut omettre des fonctionnalités complexes sans justification explicite
- La qualité visuelle masque parfois les lacunes fonctionnelles
- Réalités du vibe coding au-delà du marketing*
- La rapidité apparente de Loveable cache des implémentations incomplètes
- Le "zéro setup" a un coût en termes de contrôle et de flexibilité
- Les plans gratuits des services tiers limitent rapidement les possibilités
- La dépendance à l'écosystème Loveable peut devenir problématique
- Stratégies qui fonctionnent vraiment*
- Tester immédiatement chaque fonctionnalité après génération
- Préparer des contournements pour les limitations de services tiers
- Adapter les attentes selon les contraintes techniques de chaque outil
- Utiliser Loveable pour des prototypes rapides, pas pour des applications finales
- Comparaison Ruby on Rails vs Loveable*
- Setup : 30 minutes (Rails) vs instantané (Loveable)
- Contrôle technique : Total (Rails) vs Limité (Loveable)
- Complétude fonctionnelle : Élevée (Rails) vs Partielle (Loveable)
- Persistence données : SQLite robuste vs Local Storage temporaire
- Courbe d'apprentissage : Élevée (Rails) vs Nulle (Loveable)
- Déploiement : Manuel complexe vs Automatique simple
- Points de friction identifiés*
- Les outils cloud masquent la complexité mais réduisent le contrôle
- La dépendance aux plans payants limite l'expérimentation
- L'absence de signalement clair des fonctionnalités incomplètes trompe l'utilisateur
- Le paradigme "tout automatique" peut générer de fausses attentes