L'ancien CTO de Microsoft dénonce en détail : Windows est devenu une soupe ! 14 ans, 14 changements, 17 interfaces graphiques coexistantes

Pour investir en Bourse, référez-vous aux rapports d’analyse de l’analyste Jin Qilin : faisant autorité, professionnels, opportuns, complets—pour vous aider à découvrir des opportunités de thèmes porteurs !

（Source : Kuai Technology）

Kuai Technology, 25 mars : Jeffrey Snover, ex-CTO de Microsoft et ayant travaillé 23 ans au sein de Microsoft, a récemment publié un long billet de blog, dans lequel il dresse de façon systématique le tableau des hésitations répétées de Microsoft au fil des décennies en matière de GUI (interface graphique), et met en lumière pourquoi l’écosystème de développement Windows en est venu à se fragmenter.

Tout d’abord, revenons à la chronologie des années 1980 : à cette époque, les API Win16 et Win32 offraient à tous les développeurs Windows un paradigme de développement cohérent. Les développeurs n’avaient qu’à apprendre une seule chose pour couvrir presque tous les scénarios d’applications Windows.

Le livre de Charles Petzold, « Programming Windows », qui compte 852 pages, est considéré comme la bible du développement d’applications de bureau.

Dans les années 1990, Microsoft a tenté de dépasser les limites de Win32 avec des technologies comme MFC, COM, OLE, ActiveX, etc. Snover indique que ces composants ont « pénétré chaque recoin du développement Windows, en introduisant une complexité cognitive sans précédent ».

Lors de la conférence des développeurs, le récit technique de Microsoft est devenu incohérent ; Snover a qualifié sans détour l’allocution principale de l’époque de « keynote clusterf*ck ».

En 2003, Microsoft a présenté sa vision technique de Windows Longhorn, dont Avalon (rebaptisé ensuite WPF), avec son sous-système de rendu vectoriel XAML accéléré par GPU : la puissance technique était alors impressionnante. Cependant, en août 2004, Microsoft a brusquement changé de cap, exigeant que tout nouveau développement soit fait en C++.

Bien que WPF ait été publié avec Windows Vista, le Shell Windows lui-même ne l’a pas adopté. Cette décision a semé de profonds clivages entre l’équipe d’ingénierie Windows et l’équipe .NET.

Snover souligne que les contradictions internes ont finalement conduit à l’abandon de WPF, à la mort de Silverlight et à l’échec inévitable de l’UWP (plateforme universelle Windows) dès sa naissance.

En 2007, Microsoft, alors même que WPF avait déjà prouvé sa capacité, s’est de nouveau retourné et a lancé Silverlight.

En 2010, Microsoft a annoncé soudainement que Silverlight ne convenait pas au développement multiplateforme : HTML5 serait l’avenir. Silverlight n’était réservé qu’au développement de Windows Phone. De nombreux développeurs ayant fortement misé sur Silverlight ont été pris de court.

Avançons jusqu’en 2012 : avec la sortie de Windows 8, introduction du runtime WinRT basé sur le C++ natif. L’hostilité de l’équipe Windows envers .NET a entraîné l’abandon instantané des investissements de dix ans. Snover décrit ainsi la confusion de l’époque :

« En interne, Microsoft raconte en même temps deux histoires : l’équipe Windows travaille sur WinRT, et l’équipe .NET pousse encore WPF. Des immeubles différents, des vice-présidents différents, des feuilles de route différentes.

Les développeurs entendent sur //Build 2012 : l’avenir, c’est WinRT ; en même temps, HTML+JS est un citoyen de première classe ; en même temps, .NET peut encore être utilisé ; en même temps, le C++ est de retour ; en même temps, vous devriez écrire des applications Metro ; en même temps, votre code WPF tourne très bien. Ce n’est pas une stratégie : c’est “The Hunger Games”, six équipes se disputent votre attention.

Les développeurs d’entreprise regardent le mécanisme de sandbox de l’UWP, la diffusion obligatoire via l’App Store, et l’absence d’API Win32—et repartent. »

Snover indique qu’au cours des 14 dernières années, Microsoft a opéré 14 revirements en recommandant des frameworks de GUI Windows ; aujourd’hui, sur la plateforme Windows coexistent 17 technologies de GUI différentes, couvrant 5 langages de programmation :

Frameworks natifs Microsoft : Win32 (1985), MFC (1992), WinForms (2002), WPF (2006), WinUI 3 (2021), MAUI (2022)

Solutions web hybrides Microsoft : Blazor Hybrid, WebView2

Solutions tierces : Electron (VS Code, Slack, Discord sont utilisés ; Snover précise particulièrement qu’il s’agit de la technologie de GUI de bureau la plus largement déployée sur Windows à l’heure actuelle, et que Microsoft n’a rien à voir avec elle), Flutter (Google), Tauri, Qt, React Native for Windows, Avalonia (utilisé par JetBrains, GitHub et Unity ; Snover se moque de ces développeurs en disant qu’ils « n’attendent plus Microsoft »), Uno Platform, Delphi, Java Swing/JavaFX

Snover emploie le mot qu’il a lui-même inventé, « boof-a-rama », pour décrire la situation actuelle comme des gens intelligents qui font des bêtises. Il souligne que les technologies que Microsoft lance elles-mêmes ne sont souvent pas mauvaises. Ce qui les tue vraiment, ce ne sont pas des défauts techniques, mais la politique interne, l’annonce trop précoce d’un changement d’orientation lors des conférences de développeurs, ainsi que une stratégie commerciale chaotique.

Le « Programming Windows » de Petzold n’a plus été mis à jour après la sixième édition de 2012 (couvrant Windows 8/WinRT) ; peut-être est-ce là la meilleure note explicative à propos de cette fragmentation imprévisible.

Snover a rejoint Microsoft en 1989. Il a occupé successivement les postes de Partner Architect, Distinguished Engineer (2009), Technical Fellow et Chief Architect (2015), puis CTO (2019). En 2022, il est parti pour rejoindre Google ; en 2025, il a pris sa retraite officielle. Au vu de sa compréhension du mode de fonctionnement interne de Microsoft, la crédibilité de ce billet de blog s’impose d’évidence.

Un flot massif d’informations, une interprétation précise—tout est sur l’application Sina Finance