- Hasta fines de la década de 1980, el desarrollo de apps para Windows era claro con un modelo único centrado en la API Win16/Win32, pero en las décadas posteriores se repitieron transiciones de plataforma sin consistencia
- El colapso de la estrategia de GUI de Windows no se debió al fracaso de una tecnología específica, sino a tres causas organizacionales: política entre equipos, una cultura de anuncios centrada en conferencias para desarrolladores y cambios estratégicos sin aviso previo
- En 1988, Programming Windows de Charles Petzold dio una respuesta clara a “cómo crear una app de Windows” con una sola API, Win32, y un solo modelo mental, pero en los 30 años siguientes Microsoft no logró recuperar esa claridad
- Desde MFC, OLE, COM, ActiveX, WPF, Silverlight, WinRT, UWP, WinUI 3 y MAUI, continuó durante décadas una proliferación caótica de frameworks GUI, y en cada iniciativa fallida la causa principal no fueron defectos técnicos sino fallas de toma de decisiones dentro de la organización
- Hoy en Windows se usan más de 17 tecnologías de GUI, y entre ellas la tecnología de GUI de escritorio más ampliamente distribuida, Electron, fue creada fuera de Microsoft
- El diagnóstico central — “si una plataforma no puede responder en 10 segundos a la pregunta ‘¿cómo debo construir una UI?’, esa plataforma les falló a los desarrolladores” — sigue aplicándose tal cual a Microsoft en 2026
Microsoft después de perder una estrategia coherente de GUI
- Durante más de 30 años ha continuado el caos en la estrategia de GUI de Windows, y no existe una respuesta clara a la pregunta “¿qué framework debería usarse para crear una nueva app de escritorio para Windows?”
- En 1988 existía un modelo único, la API Win16/Win32, que permitía a los desarrolladores escribir apps de una sola manera
- En las décadas siguientes, Microsoft no pudo sostener una plataforma coherente debido a política interna, decisiones guiadas por demos y cambios en la estrategia de negocio
- Como resultado, desde Win32 hasta MAUI coexisten 17 tecnologías de GUI, y los desarrolladores lidian con la confusión de una plataforma sin estrategia
- La causa de fondo no fue un fracaso técnico, sino un fracaso organizacional
La era de Petzold: la última vez que hubo claridad
- En 1988, Programming Windows (852 páginas) de Charles Petzold era la única respuesta autorizada sobre cómo trabajar con la API Win16 en C, y eso era precisamente la estrategia de desarrollo de Windows
- Win32 también creció en escala, pero mantuvo un solo modelo mental — message loop, window procedure y GDI —; Petzold lo explicaba y los desarrolladores podían aprenderlo y usarlo de inmediato
- “Un SO, una API, un lenguaje, un libro” — esa claridad era la señal de confianza de la plataforma
El auge de la orientación a objetos (1992–2000): el inicio de la complejidad
- En 1992, MFC envolvió Win32 en C++, pero luego aparecieron OLE, COM y ActiveX, y arquitecturas de componentes, no frameworks GUI, terminaron invadiendo el desarrollo de Windows en general
- En vez de ofrecer una historia coherente, Microsoft solo entregó primitivas tecnológicas para que los desarrolladores las combinaran por su cuenta, porque la cultura de anuncios centrada en keynotes de conferencias priorizaba impresionar a ejecutivos por encima del éxito de los desarrolladores
PDC 2003 Longhorn: una visión que se devoró a sí misma
- Longhorn, presentado en la PDC de 2003, era una visión convincente compuesta por tres pilares: WinFS (sistema de archivos relacional), Indigo (comunicación unificada) y Avalon (UI basada en XAML con aceleración por GPU)
- En enero de 2004, un memo interno de Jim Allchin lo describió como “un cerdo”, y en agosto de ese mismo año se anunció un reinicio completo del desarrollo: volver a la base de código de Server 2003
- Después del reinicio, el liderazgo dio la directiva de “prohibido el managed code dentro de Windows; todo el código nuevo en C++”; WPF salió junto con Vista, pero el propio shell no usó WPF
- Esa decisión inició una guerra interna de 13 años entre el equipo de Windows y el equipo de .NET, que finalmente llevó a la orfandad de WPF, el abandono de Silverlight y el fracaso de UWP
Silverlight: se establece un patrón que se repetiría (2007–2010)
- WPF salió a fines de 2006, pero en 2007 apareció Silverlight como plugin de navegador para competir con Flash, dispersando la inversión de desarrollo
- En la conferencia MIX de 2010, durante una sesión de preguntas y respuestas, un ejecutivo de Microsoft dijo que “Silverlight no era una estrategia multiplataforma sino una estrategia para Windows Phone” — el equipo de Silverlight no había sido avisado de antemano, y los desarrolladores que habían invertido sus apps LOB en Silverlight también se enteraron por primera vez en ese Q&A de la conferencia
- El final de Silverlight no fue resultado de un fracaso técnico, sino de un cambio en la estrategia de negocio, y aquí quedó establecido el patrón de que los desarrolladores siempre serían los últimos en enterarse
Metro y la guerra entre dos equipos (2012)
- Como respuesta a los 200 millones de iPhone vendidos por Apple y a cómo el iPad desplazaba a la PC, se lanzaron Windows 8 y Metro, pero WinRT fue diseñado deliberadamente no como un runtime basado en .NET, sino como un runtime nativo en C++ — reflejo directo de la aversión del equipo de Windows hacia .NET
- En //Build 2012, los desarrolladores recibieron al mismo tiempo mensajes contradictorios: “el futuro es WinRT, HTML+JS es ciudadano de primera clase, .NET sigue funcionando, C++ ha vuelto, también se pueden escribir apps Metro y el código WPF sigue ejecutándose”
- Los desarrolladores empresariales revisaron el sandboxing de UWP, los requisitos de distribución por Store y las APIs Win32 faltantes, y se fueron de inmediato — “la app store para tablets nunca terminó de hacerse realidad”
La confusión de UWP y WinUI (2015–actualidad)
- La UWP (Universal Windows Platform) de Windows 10 prometía la visión de “escribe una vez, ejecuta en todas partes” para PC, teléfono, Xbox y HoloLens, pero con la caída de Windows Phone y el hecho de que las propias apps principales de Microsoft (Office, Visual Studio y el shell) no usaban UWP, la señal quedó clara
- La respuesta oficial degeneró en “depende” — UWP, mantenimiento de WPF, XAML Islands, esperar a WinUI 3, convivencia con WinUI 2, lanzamiento de Project Reunion y cambio de nombre a Windows App SDK, todo ello profundizó la confusión
- Project Reunion / WinUI 3 representa un avance técnico, pero su sola existencia es producto de un problema organizacional: los controles de UWP estaban ligados al SO y el equipo de .NET y el de herramientas de desarrollo no los controlaban
- El recuento de un desarrollador en 2024: “UAP, UWP, reemplazo de C++/CX por C++/WinRT (sin soporte de herramientas), XAML Islands, XAML Direct, reinicio con Project Reunion, reinicio con WinAppSDK, la confusa transición entre WinUI 2.0 y 3.0… 14 años, 14 pivotes”
Un zoológico sin cuidador: la lista actual de tecnologías GUI en Windows
Frameworks nativos de Microsoft:
- Win32 (1985) — sigue en uso; el libro de Petzold todavía es válido
- MFC (1992) — en modo mantenimiento; sigue presente en sectores empresariales y CAD
- WinForms (2002) — “usable, pero no recomendado”; sigue siendo lo más rápido para formularios de captura de datos
- WPF (2006) — XAML, renderizado con DirectX, open source, sin inversión nueva de Microsoft
- WinUI 3 / Windows App SDK (2021) — la respuesta oficial “moderna”, con una hoja de ruta incierta
- MAUI (2022) — sucesor multiplataforma de Xamarin.Forms, la apuesta actual del equipo de .NET
Híbridos web de Microsoft:
- Blazor Hybrid — componentes Razor de .NET dentro de un WebView nativo
- WebView2 — Chromium embebido en apps Win32/WinForms/WPF
Terceros:
- Electron — Chromium + Node.js, adoptado por VS Code, Slack y Discord; hoy es la tecnología de GUI de escritorio más ampliamente distribuida en Windows, pero no tiene relación con Microsoft
- Flutter (Google), Tauri (basado en Rust), Qt (C++/Python/JS), React Native for Windows (patrocinado por Microsoft, pero basado en tecnología de Facebook)
- Avalonia — heredero espiritual open source de WPF, adoptado por desarrolladores como JetBrains, GitHub y Unity que no esperaron a Microsoft
- Uno Platform — más comprometida con WinUI que Microsoft
- Delphi/RAD Studio, Java Swing/JavaFX — todavía sobreviven en mercados verticales y en entornos empresariales
→ 17 enfoques, 5 lenguajes de programación, 3 filosofías de renderizado — eso no es una “plataforma”
Diagnóstico central
- Todas las iniciativas fallidas de GUI terminan explicándose por una de tres causas: política entre equipos (Windows vs. .NET), apuestas tempranas de plataforma impulsadas por anuncios de conferencia (Metro, UWP) o cambios de estrategia de negocio sin avisar antes a los desarrolladores (Silverlight)
- La tecnología en sí solía ser buena — WPF era buena, Silverlight era buena, XAML era bueno — el fracaso organizacional fue el fracaso del producto
- Sin una Plausible Theory of Success que abarque todo el ciclo de vida de “adopción-inversión-mantenimiento-migración”, no hay estrategia sino solo un keynote de conferencia
- Charles Petzold revisó Programming Windows hasta su sexta edición para seguir el ritmo de las novedades que Microsoft iba anunciando, pero dejó de escribir después de la sexta edición, que cubría WinRT (Windows 8)
2 comentarios
¿Al final todo lleva a Win32?!!
Comentarios en Hacker News
El problema de fondo es que Microsoft intenta resolver la consistencia de la GUI solo en la capa de framework
Sigue lanzando frameworks nuevos como WinForms, WPF, UWP y WinUI, y al final los termina abandonando
Apple, en cambio, ve el sistema de diseño en sí como el producto, y hace que el framework sea invisible, mientras que Microsoft siempre lo aborda al revés
¿Quieres contar también algunos ejemplos del lado de Apple?
Últimamente WPF está imitando el skin de WinUI, así que por lo menos Microsoft sí está intentando algo
Incluso en el stack moderno de .NET sigue siendo una de las rutas oficiales
WinForms sigue siendo atractivo
Gracias a WebView2 se volvió fácil desarrollar apps híbridas, y aunque podrías irte por puro web, la sensación que da el chrome nativo es mejor
Como todos los clientes usan Windows, no vale la pena pelearse con eso
Últimamente estoy construyendo un asistente de IA con .NET10 + WinForms + WebView2
No quiero ni imaginar tener que iterar una y otra vez la UI del historial de conversación en puro WinForms
No estoy de acuerdo con eso de que “WPF era bueno”
En hardware común de finales de los 2000, las apps WPF eran lentas
Por ejemplo, Logos Bible Software era básicamente una app de texto, pero exigía rendimiento gráfico, así que se arrastraba en laptops viejas
Después vi que Logos 4 estaba hecho sobre WPF, y en el foro también había muchas quejas al respecto
Al final reimplementamos la mayor parte del código en Direct3D/Direct2D
El problema era la arquitectura de WPF
Según se dijo, fue por el texto borroso y los problemas de rendimiento
Artículos relacionados: edandersen.com / Reddit
Artículo relacionado: Ars Technica
Al final, los debates sobre rendimiento se repiten en cada época
Apple también está pasando por problemas parecidos al moverse de AppKit/UIKit a SwiftUI
Cuando ChatGPT explotó por primera vez, fue una idea genial que Bing integrara una versión con acceso a la web
Pero Microsoft no implementó detalles como la compresión de contexto, así que las conversaciones se bloqueaban rápidamente
En cambio, OpenAI, Perplexity y otros sí lo implementaron bien, y ahora ya es algo estándar
Si Microsoft lo hubiera hecho bien en ese momento, podría incluso haber reemplazado a Google
Al final, el problema fue la falta de pulido en la UI/UX, y creo que eso viene de la falta de consistencia en la cultura organizacional
Me desesperaba que Apple impidiera empaquetar librerías de UI, pero también es cierto que gracias a eso se mantuvo la consistencia de la UI
A la mayoría de los usuarios no les importa
Hay un usuario que sigue copiando y pegando una historia sobre una cena con un ejecutivo de Microsoft, y la idea central es que “Microsoft está all-in con enterprise”
Pero en la práctica, incluso las empresas se están yendo por la caída en la calidad de Windows y Azure
Nuestra empresa también salió perjudicada por problemas con el SLA de Azure, y no hubo compensación alguna
Por eso estamos reduciendo nuestra dependencia de Active Directory y Windows
Al final, no existe un mercado empresarial sin usuarios
Desde Win32, Microsoft no ha empujado una sola dirección durante más de 2 años
WinRT estaba decente, pero llegó Nadella, giró todo hacia Azure y abandonó la plataforma Windows
Su identidad se ha ido diluyendo al pasar de Windows → Office → Azure
Office existe tanto en web como en escritorio, y también tienen hardware y tienda
La visión de Satya Nadella no se comunica con claridad
La tienda era pésima y no pasaba de ser un proyecto para ascensos internos
El problema es que Microsoft sigue sacando frameworks GUI nuevos, pero aun así todavía se pueden escribir apps Win32
Microsoft tomó una dirección centrada en la web desde hace mucho, y también contribuyó al avance de tecnologías como AJAX, Flexbox y Grid
Yo desarrollo principalmente sistemas multiplataforma basados en web, Java y Python
No hay razón para hacer una GUI exclusiva de Windows
Las apps web son más flexibles y accesibles
La web funciona en cualquier lado, y con PWABuilder también puedes distribuir en tiendas de apps
Participo en este proyecto y permite crear apps rápidas y ligeras sin Electron
Si ves la documentación de Active Desktop, en ese momento era algo bastante experimental
La web sigue siendo un parche temporal; la experiencia realmente buena sale de lo nativo
Por ahí de 2007 me pasé de Delphi a WPF, pero en 2010 dejé Windows por completo
La política interna de Microsoft y lo seguido que abandonaban tecnologías ya era demasiado
Además, Rails estaba despegando, así que cambiarse era fácil
Tal vez sea síndrome de Estocolmo, pero Visual Studio también sigue basado en WPF, así que no me preocupa
En cierto modo, mostró por adelantado los problemas de las big tech de hoy
Steven Sinofsky publicó hace poco algo sobre el mismo tema
enlace a x.com
Él estaba en DevDiv en la época de WinRT, y el equipo de Windows no entendía las necesidades de los desarrolladores
Incluso hubo un prototipo de Python/WinRT, pero lo descartaron porque “los desarrolladores solo quieren JS”
También forzaron el estilo Metro hasta cambiar todos los menús de Visual Studio a mayúsculas
Windows RT además rompía la compatibilidad, así que casi no tenía apps, y al final fracasó
De hecho, algunas de las afirmaciones técnicas de Sinofsky son incorrectas (.NET 3.0 venía incluido en Vista)
xcancel.com todavía no soporta esa función
La respuesta es clara: Qt
Y no es broma; si no vas a usar Electron, Qt sí es una alternativa real
Ese es el negocio principal de Qt, así que no está cambiando de dirección a cada rato