Visual Basic 6 en 2026: Un appel à Microsoft

C# en tant que langage de programmation n'est pas du tout inférieur à VB6, ni à VB.NET.

Mais : l'environnement de développement .NET donne l'impression à un développeur VB6 de revenir à l'âge de pierre :

1. Il manque les capacités magiques de débogage qui faisaient de la "programmation en direct" dans VB6 un véritable booster pour la programmation : Tu commences avec un brouillon et tu l'optimises en cours d'exécution.
2. .NET réunit des centaines de technologies sous un même toit, mais l'interface surchargée décourage dès le début tout débutant ou tout nouvel arrivant, et la courbe d'apprentissage pour se familiariser avec l'IDE est énorme.
3. L'IDE .NET est beaucoup moins responsive et pour lancer une petite application Hello World, il faut parfois 10 seconde de temps de compilation avant qu'un programme simple ne démarre...
4. L'IDE .NET semble être extrêmement gourmand en ressources. Installer rapidement un environnement de développement .NET sur un ordinateur portable Surface avec 250 Go d'espace disque ressemble à un parcours du combattant lorsqu'il s'agit de libérer les ressources nécessaires.

Mon appel à Microsoft : VB6 doit devenir OpenSource pour que la communauté puisse continuer à le développer et le faire passer à l'année 2026.

VB6 continue à vivre en 2026

La communauté n'a jamais abandonné Visual Basic 6. Kr00l a fait passer les Microsoft Common Controls, souvent utilisés dans VB6, à l'année 2026 et a créé les mêmes composants complètement DPI-Aware et compatibles Unicode/UTF-8.

TwinBasic est en train de devenir un compilateur 64Bit prêt à démarrer, même pour des programmes déjà existants. L'approche de la communauté est louable et très ambitieuse, surtout parce que personne n'a accès au code source de VB6 et que la communauté doit tout redévelopper.

Malheureusement, l'approche est si ambitieuse qu'il vaut la peine de se demander quelles autres alternatives nous avons.

De nombreuses faiblesses de VB6, comme le véritable multithreading, pourraient être résolues en 2026 avec des composants Rust supplémentaires, qui pourraient être ancrés si nécessaire.

Le niveau d'OOP de Visual Basic est un compromis génial entre la réduction de la complexité et l'utilisation facultative des classes comme conteneurs de méthodes et de données, là où cela favorise vraiment l'efficacité de la programmation. Cette approche ne devrait pas être modifiée du tout.

L'installateur de l'IDE VB6 pourrait et devrait être entièrement reconstruit, par exemple avec Inno Setup.

Le DPIAwareness complet, la compatibilité UTF8 de bout en bout et même un compilateur 64 bits pourraient être intégrés directement dans le code source de VB6.

Là où VB6 appelle encore des méthodes Ansi dans l'API Win32 (par exemple WriteTextA), nous pourrions les remplacer par des méthodes W compatibles UTF8 (WriteTextW).

Nous, la communauté, prendrions en charge cette tâche et ferions passer l'approche géniale de Visual Basic 6 à l'année 2026. Car personne parmi les anciens fans de VB6 n'utilise actuellement Visual Basic .NET vraiment avec cœur.

Et cela doit être un aveu pour Microsoft : la décision d'arrêter VB6 et de positionner .NET comme son successeur est un échec.

Beaucoup de développeurs VB6 restants doivent se réorienter lentement, perdent patience et passent alors lentement mais sûrement à Linux et Rust.

Ou bien Microsoft ouvre le code source de Visual Basic 6 et nous, la communauté, récupérons cet environnement de développement génial pour Windows en 2026.

Ce dernier cas serait un grand bénéfice pour la communauté, pour les développeurs, les utilisateurs et même pour toute l'industrie technologique.

Et enfin, ce serait un grand plus pour Microsoft, car la décision de mettre à disposition le code source de Visual Basic 6 en open source, favorisera également la réputation de Microsoft et fera revenir de nombreux fans & développeurs, et les fidélisera à l'écosystème Microsoft.

Ce serait un gain sérieux pour Microsoft, je dirais.