El ex CTO de Microsoft denuncia en un largo artículo: ¡Windows se ha convertido en un revoltijo! 14 cambios en 14 años, coexistencia de 17 tipos de GUI

Invertir en bolsa consiste en mirar los informes de analistas de Golden Kirin: autorizados, profesionales, oportunos, completos. ¡Le ayudan a descubrir oportunidades temáticas con potencial!

（Fuente: KuaiKeJi）

KuaiKeJi, 25 de marzo. Noticias: Jeffrey Snover, ex CTO de Microsoft y que estuvo 23 años en Microsoft, publicó recientemente un artículo largo en su blog, en el que revisa de forma sistemática las idas y vueltas repetidas de Microsoft durante décadas en lo relacionado con GUI (interfaz gráfica de usuario), y revela por qué el ecosistema de desarrollo de Windows terminó fragmentándose.

Primero, retrocedamos la línea temporal hasta la década de 1980. En aquella época, las API Win16 y Win32 proporcionaban a todos los desarrolladores de Windows un paradigma de desarrollo coherente. Con aprender una sola cosa, los desarrolladores podían cubrir casi todos los escenarios de aplicaciones de Windows.

El autor técnico Charles Petzold escribió 《Programming Windows》, de 852 páginas, considerado la Biblia para el desarrollo de aplicaciones de escritorio.

En la década de 1990, Microsoft intentó superar las limitaciones de Win32 con tecnologías como MFC, COM, OLE, ActiveX, etc. Snover señala que estas arquitecturas “se infiltraron en cada rincón del desarrollo de Windows, introduciendo una complejidad cognitiva sin precedentes”.

En una conferencia para desarrolladores, la narrativa técnica de Microsoft se volvió hecha pedazos. Snover, sin contemplaciones, describió el discurso de apertura temático de ese momento como un “keynote clusterf*ck”.

En 2003, Microsoft presentó la visión técnica de Windows Longhorn. En ella, Avalon (más tarde renombrado como WPF), con su subsistema de renderizado vectorial XAML acelerado por GPU, era un despliegue de fuerza técnica extremadamente potente. Sin embargo, en agosto de 2004, Microsoft cambió de rumbo de manera repentina y exigió que todo nuevo desarrollo usara C++.

Aunque WPF se lanzó con Windows Vista, el propio Windows Shell no lo adoptó. Esta decisión sembró profundas grietas entre el equipo de ingeniería de Windows y el equipo .NET.

Snover indica que las contradicciones internas finalmente llevaron a que WPF fuera abandonado, Silverlight muriera y que UWP (plataforma universal de Windows), desde su salida, estuviera destinada al fracaso.

En 2007, Microsoft, tras haber demostrado ya su capacidad con WPF, volvió a cambiar de rumbo para lanzar Silverlight.

En 2010, Microsoft anunció de repente que Silverlight no era adecuado para el desarrollo multiplataforma. HTML5 era la dirección del futuro. Silverlight solo se usaría para el desarrollo de Windows Phone. Muchos desarrolladores que apostaban fuertemente por Silverlight quedaron tomados por sorpresa.

Avancemos hasta 2012, con el lanzamiento de Windows 8. Se introdujo WinRT, un runtime basado en C++ nativo. La hostilidad del equipo de Windows hacia .NET hizo que las inversiones de este último durante una década se abandonaran instantáneamente. Snover describe así el caos de aquella época:

“Dentro de Microsoft, se contaban dos historias al mismo tiempo: el equipo de Windows estaba trabajando en WinRT, y el equipo .NET seguía impulsando WPF. Edificios distintos, vicepresidentes distintos, hojas de ruta distintas.

Lo que los desarrolladores escucharon en //Build 2012 fue: el futuro es WinRT; al mismo tiempo, HTML+JS es un ciudadano de primera clase; al mismo tiempo, .NET aún puede usarse; al mismo tiempo, el C++ vuelve; al mismo tiempo, deberías escribir aplicaciones Metro; y, además, tu código WPF corre muy bien. Esto no es una estrategia; es 《The Hunger Games》: seis equipos compiten por tu atención.

Los desarrolladores empresariales miraron el mecanismo de sandbox de UWP, la distribución obligatoria mediante la tienda de aplicaciones y la ausencia de Win32 API, se dieron la vuelta y se fueron.”

Snover señala que, en los últimos 14 años, Microsoft se ha movido 14 veces al recomendar marcos de GUI de Windows. Hoy, en la plataforma Windows conviven 17 tecnologías de GUI distintas, que cubren 5 lenguajes de programación:

Marcos nativos de Microsoft: Win32 (1985), MFC (1992), WinForms (2002), WPF (2006), WinUI 3 (2021), MAUI (2022)

Solución web híbrida de Microsoft: Blazor Hybrid, WebView2

Soluciones de terceros: Electron (VS Code, Slack, Discord están siendo usados; Snover señala especialmente que esta es, actualmente, la tecnología de GUI de escritorio con más despliegue en Windows y que Microsoft no tiene nada que ver con ella), Flutter (Google), Tauri, Qt, React Native for Windows, Avalonia (JetBrains, GitHub, Unity lo usan; Snover satiriza a esos desarrolladores como “que ya no esperan a Microsoft”), Uno Platform, Delphi, Java Swing/JavaFX

Snover usa la palabra que él mismo inventó, “boof-a-rama”, para describir la situación actual como que los listos están haciendo tonterías. Enfatiza que, aunque la tecnología que lanza Microsoft en sí muchas veces no es mala, lo que realmente las mata no son defectos técnicos, sino la política interna, el anuncio prematuro de pivotes en conferencias para desarrolladores y una estrategia comercial caótica.

《Programming Windows》de Petzold ya no se actualiza después de la sexta edición en 2012 (cubriendo Windows 8/WinRT). Quizá sea la mejor prueba de que esta fragmentación impredecible.

Snover se unió a Microsoft en 1989; ocupó cargos como Partner Architect, Distinguished Engineer (2009), Technical Fellow y Chief Architect (2015), CTO (2019). En 2022 se fue para unirse a Google; en 2025 se jubiló oficialmente. Conociendo, por su propia experiencia, el funcionamiento interno de Microsoft, la credibilidad de este artículo del blog es incuestionable.

Noticias masivas, interpretación precisa: todo en la aplicación Sina Finance