Orchids

Vous décriviez l'application que vous vouliez et Orchids produisait un projet, pas une image d'un projet. Cela voulait dire de vrais fichiers et de vrais composants que vous pouviez exécuter. Pas une maquette de design qu'il vous faudrait encore construire à la main. Pour ceux qui n'ont pas de bagage en programmation, c'était tout l'attrait. Le piège ? Des prompts vagues donnaient des résultats vagues. La qualité de la sortie suivait la clarté de votre description. Sans code à corriger à la main, il fallait viser juste dans la description dès les premières fois.

Orchids ne s'arrêtait pas au front end. Il montait les éléments de backend dont une application fonctionnelle a besoin, avec la logique applicative et une base de données, pour que des fonctions comme les formulaires et les comptes stockent de vraies données. C'est la différence entre un site qui a l'air terminé et un site qui marche. Cela rendait Orchids adapté aux petites applications web, pas seulement aux pages vitrines. Ce qui était complexe demandait encore à un humain de vérifier la sortie.

Chaque changement apparaissait dans un aperçu en direct, et vous affiniez le résultat en discutant plutôt qu'en éditant du code. Vous pouviez demander une autre mise en page, un nouveau champ ou un changement de couleur et le voir appliqué. Cette boucle rendait l'outil accessible. Vous jugiez l'application en la regardant, pas en lisant des fichiers de code. Cela signifiait aussi que l'essentiel de votre temps passait à décrire clairement votre intention, ce que certains ont trouvé plus difficile que prévu. Coder en langage naturel paraît simple jusqu'à ce qu'il faille être précis.

Les projets qui devaient stocker des données pouvaient utiliser une base de données gérée, provisionnée pour vous. Un formulaire d'inscription, une liste de tâches ou un petit suivi clients pouvaient contenir de vrais enregistrements sans que vous montiez un serveur ni écriviez des scripts de migration. Pour les utilisateurs non techniques, cela retirait l'un des plus gros freins à la construction de quoi que ce soit d'interactif. Aucun serveur à surveiller. La contrepartie était le contrôle. Vous travailliez dans la configuration gérée plutôt que de régler la base de données vous-même.

Orchids gérait le déploiement, donc un projet terminé pouvait être mis en ligne sur une URL publique depuis le tableau de bord. Pas de compte d'hébergement séparé. Pas de pipeline CI. Vous pouviez montrer votre travail sans quitter l'outil. Quand le service a fermé, cette commodité est devenue le problème : les projets déployés ont cessé de fonctionner et ont dû être récupérés ou déplacés vers un autre hébergeur. C'est un rappel que l'hébergement lié à un seul outil vit et meurt avec cet outil.

À côté de la version web, Orchids proposait une application de bureau qui gardait vos projets en local, généralement dans un dossier de votre machine. Pour ceux qui tenaient à conserver leur travail, cette copie locale comptait. Elle a survécu à la fermeture sans aucune étape de migration. Une petite fonction qui s'est révélée, avec le recul, l'une des plus utiles.