Le cauchemar de la maintenance des applications Low-Code (et ce que coûte réellement une réécriture native)

TL;DR

• Le low-code vous permet de commercialiser rapidement. La facture arrive généralement lorsque vous devez modifier quelque chose, pas au lancement.
• La migration d'une application FF (low-code) vers Flutter natif a nécessité plus de 80 commits en quelques semaines. Aucun d’entre eux n’a livré de fonctionnalité.
• Je n'étais pas une personne sans code. J'ai écrit beaucoup de Dart personnalisés dans FlutterFlow. La couche visuelle possédait toujours l’architecture.
• Avec des outils comme Cursor, l’avantage de vitesse du low-code est bien moindre qu’il ne l’était en 2022. La dette technique ne l’est pas.

J'ai passé des années à construire des architectures mobiles complexes. Comme beaucoup dans l'industrie, j'ai adopté les constructeurs visuels comme FlutterFlow lorsqu'ils ont atteint leur apogée, appréciant ce qu'ils nous ont appris sur la réutilisabilité des composants et la rapidité d'expédition. J'ai beaucoup de respect pour ces outils.

Mais la technologie évolue.

Le mois dernier, j'ai migré une application de production en direct de FlutterFlow vers Flutter natif, en utilisant Cursor comme IDE principal. L'application avait de vrais utilisateurs, des fonctionnalités d'IA et des paiements. En apparence, tout fonctionnait. Écrans chargés, notifications déclenchées, utilisateurs connectés.

Ensuite, j'ai regardé le code ci-dessous. L'application n'avait pas été créée. Il avait été assemblé. Cette différence n'a pas d'importance au moment du lancement. Cela compte beaucoup lorsque vous grandissez.

Ce n’est pas un argument contre le low-code. Il s'agit de ce qui se passe une fois votre prototype réussi et de la raison pour laquelle personne ne parle de cette pièce tant qu'elle n'est p...
[Courte citation de 8% de l'article original]