Cuando WhatsApp tomó la decisión universalmente odiada de cambiar su aplicación nativa de Windows a un contenedor web, logró enfrentar la mayoría de las críticas. Y con razón. Se sintió lento, fue una degradación clara que acaparó la RAM y eliminó un poco de la experiencia “nativa” de la aplicación en Windows.
Pero la realidad es un poco más incómoda.
Incluso Meta no tenía muchos incentivos para seguir con una aplicación nativa de Windows. La compañía simplemente lo actualizó, no igualó las funciones y finalmente optó por la versión web de forma predeterminada. La razón principal es probablemente que las aplicaciones web son más baratas de crear y mantener. Pero el verdadero problema es que Microsoft no ha brindado a los desarrolladores un marco de interfaz de usuario con el que puedan comprometerse a largo plazo. Las aplicaciones web no tienen ese problema.
Recientemente escuchamos a un lector veterano de Windows Latest, Alexander Ovchinnikov, quien también es desarrollador. Sus puntos reflejan lo que muchos desarrolladores ya sienten.
A diferencia de macOS, que siempre obtiene aplicaciones nativas, a pesar de una base de usuarios mucho más pequeña, la actitud de los desarrolladores hacia impulsar aplicaciones web sólo para Windows no se trata de conveniencia. Se trata de confianza, o mejor dicho, de la falta de ella.
A lo largo de los años, Microsoft ha introducido múltiples marcos “futuros”, para luego alejarse de ellos. Desde WPF y Silverlight hasta UWP y ahora WinUI 3, la empresa no ha cambiado este patrón. Como dice Alexander, muchos desarrolladores ahora asumen que cualquier cosa que Microsoft esté impulsando hoy podría no durar lo suficiente como para justificar la construcción a partir de ello.
Microsoft no ha tenido una estrategia clara de GUI durante décadas, y Windows ahora ofrece muchos marcos sin una respuesta definitiva sobre qué deberían usar realmente los desarrolladores.
Saber esto cambió mi enfoque hacia las aplicaciones web para Windows. Son una opción alternativa cuando la propia plataforma se siente incierta. Sin embargo, el reciente amor de Microsoft por crear aplicaciones 100% nativas para Windows puede cambiar las cosas.
Windows ha pasado de un camino de desarrollo claro a muchas opciones confusas
Hubo un tiempo en el que crear una aplicación para Windows no requería debate mental. El desarrollo inicial de Windows giró en torno a un sistema único y bien comprendido. Win32 fue la respuesta. Una API, un modelo mental y una forma clara de hacer las cosas.
Por Charles Petzold “Programación de Windows”Lo que era ampliamente considerado la “Biblia” del desarrollo de Windows, lo hizo accesible y los desarrolladores podían pasar su tiempo sabiendo que la plataforma no se les iba a escapar. Esa estabilidad generó confianza y el ecosistema de confianza creció.
Sin embargo, en lugar de convertir Win32 en algo más moderno, Microsoft continuó introduciendo nuevas capas y opciones. Primero surgió MFC como contenedor de C++. Luego WinForms para desarrolladores .NET. WPF siguió con XAML y renderizado acelerado por hardware. Silverlight se presenta como una apuesta multiplataforma. Luego vinieron WinRT y UWP en la era de Windows 8 y Windows 10. Y ahora tenemos WinUI 3 con Windows App SDK, junto con MAUI para desarrollo multiplataforma.
Cada uno de estos fue anunciado con un fuerte discurso acerca de ser el futuro del desarrollo de Windows. Cada uno pidió a los desarrolladores que invirtieran tiempo, aprendieran nuevos patrones y construyeran sobre ellos.
El problema no era que estas tecnologías fueran malas. Muchos de ellos estaban realmente adelantados a su tiempo. El problema era que el “futuro” seguía siendo reemplazado antes de que estuviera completamente resuelto. En lugar de una única plataforma en evolución, los desarrolladores tuvieron que perseguir objetivos en movimiento.
Blog detallado de Jeffrey Snover indica Que Windows ha dejado de dar una respuesta clara a una sencilla pregunta: ¿Cómo se debe crear una aplicación para Windows?
Hasta que apareció Silverlight, hasta que Microsoft pasó a HTML5, se suponía que WPF era el futuro, lo cual era prometedor. UWP fue impulsada como una plataforma unificada para todo, pero ni siquiera obtuvo plena aceptación interna. WinUI 3 ahora se posiciona como la solución moderna, pero su hoja de ruta no ha inspirado el mismo nivel de confianza en los desarrolladores que en épocas anteriores.
Cuando Microsoft introduzca un nuevo marco con una directiva clara, los desarrolladores comenzarán a adoptarlo. Entonces las tácticas cambiarán y la atención se desplazará hacia otra parte. La estructura anterior no siempre desaparecerá oficialmente, pero poco a poco irá perdiendo relevancia. Este ciclo se ha repetido tantas veces que los desarrolladores han dejado de comprometerse por completo.
Como nos dijo Alexander, la sensación actual es que, si Microsoft no puede seguir con el marco anterior, ¿por qué suponer que el actual será diferente?
Así son las cosas hoy. Pregúntele a un desarrollador qué usaría para una aplicación de Windows y la respuesta dependerá de a quién le pregunte. Algunos todavía recomendarían Win32. Otros prefieren WPF porque es estable. WinUI 3 se posiciona como moderno, pero aún no es de confianza universal. MAUI existe para uso multiplataforma. Luego está la ruta web con Electron o PWA. Además de eso, los frameworks de terceros como Avalonia y Qt están ganando terreno.
Esas opciones no se solicitan a los desarrolladores. Es una completa incertidumbre.
Por qué los desarrolladores eligen aplicaciones web en lugar de nativas
Algunas de las aplicaciones de Windows más populares no son verdaderamente nativas. WhatsApp, Spotify, Discord, Slack, Ideas, Zoom e incluso partes del propio ecosistema de Microsoft… Microsoft Teams (antes de su reescritura), ClipChamp y varias experiencias propias utilizan WebView2.
Por supuesto, se ha vuelto muy fácil crear una aplicación web una vez y enviarla a todas partes. Puede ejecutarse en Windows, macOS, Linux e incluso en navegadores sin mantener una base de código separada. Marcos como Electron, WebView basado en Chromium y Progressive Web Apps han facilitado la distribución, han hecho actualizaciones más rápidas y han reducido los costos de desarrollo. Parece difícil ignorar a las empresas.
WebView2 incorpora el motor Edge (Chromium) dentro de la aplicación Pivot de Microsoft. Esto funciona bien por motivos de compatibilidad, pero significa que muchas aplicaciones de “escritorio” son páginas web que se ejecutan en un contenedor.
Y la desventaja obvia es que estas aplicaciones usan más RAM, responden menos y no se integran profundamente con el sistema operativo. La ejecución de varias aplicaciones de Electron al mismo tiempo puede consumir fácilmente los recursos del sistema, algo que algunas aplicaciones nativas tradicionalmente manejan mucho mejor.
En MacOS e iOS, los desarrolladores siguen prefiriendo las aplicaciones nativas. Incluso las empresas que tienen tecnologías web en otros lugares crean versiones nativas para dispositivos Apple. Porque Apple mantiene un camino de desarrollo muy claro. Marcos como Cocoa, AppKit y ahora SwiftUI reciben soporte y desarrollo continuo. Los desarrolladores saben qué usar y, lo que es más importante, saben que será relevante dentro de unos años.
Windows no tiene la misma transparencia y los desarrolladores responden en consecuencia.
Entonces, en lugar de apostar por una estructura que puede volver a cambiar de rumbo, muchos eligen la web. No es perfecto y, en muchos casos, es objetivamente malo para el rendimiento del escritorio. Pero elimina el gran riesgo de confiar en la próxima decisión de Microsoft.
Microsoft está intentando solucionar este problema, pero puede que sea demasiado tarde
Hay señales de que Microsoft es consciente del problema. Esfuerzos recientes sugieren que están avanzando hacia la mejora del rendimiento, la reducción de la dependencia de componentes basados en web y la creación de una experiencia más nativa en Windows. La publicación X de Rudy Huynh se ha visto de manera positiva, dando la bienvenida a los desarrolladores de Windows para que creen aplicaciones 100% nativas.
Pero arreglar las aplicaciones en sí es sólo una parte de la ecuación.
Incluso si Microsoft ofrece mejores aplicaciones nativas en el futuro, los desarrolladores todavía se enfrentan a un dilema. El dilema no proviene de lo que WinUI 3 puede o no puede hacer hoy. Viene de lo que pasó antes. Años de prioridades cambiantes han hecho que los desarrolladores sean cautelosos, y esos dilemas no desaparecen de la noche a la mañana.
Si Microsoft quiere cambiar esto, se comprometerá plenamente con un marco y lo comunicará bien a los desarrolladores. También significa apegarse a una estructura para madurar, aclarar su dirección y apoyarla. Los desarrolladores necesitan una hoja de ruta en la que puedan confiar, con rutas de migración claras cuando se produzcan cambios.
El verdadero problema no es la tecnología, es la coherencia
A Microsoft no le faltan capacidades. La empresa cuenta con algunos de los mejores talentos de ingeniería de la industria y una larga trayectoria en la creación de potentes herramientas de desarrollo. Muchos de los marcos que introdujo fueron realmente poderosos desde una perspectiva técnica.
Lo que faltaba era continuidad.
Análisis de Rebecca Sutter señala que el problema no es un fallo técnico, sino un patrón de decisiones internas que cambian de dirección repetidamente.
Esto se ha traducido repetidamente en incertidumbre para los desarrolladores. Desde fuera, no importa por qué ocurrieron estos cambios. Lo que importa es el resultado. Los desarrolladores se quedaron con múltiples caminos, ninguno de los cuales parecía garantizado para durar.
Por eso la situación parece así hoy. El problema no es que Windows tenga muy pocas opciones. Es que ninguno de ellos se siente específico. Los desarrolladores no piden más estructura. Están pidiendo a alguien en quien puedan confiar.
Las aplicaciones web son un síntoma, no un problema
Las aplicaciones web no se están apoderando de Windows porque son más adecuadas para la informática de escritorio. En muchos casos, no es así. Están asumiendo el control porque ofrecen confiabilidad a los desarrolladores que ya no quieren invertir en la plataforma Windows.
No puedo culpar a los desarrolladores por tomar una decisión calculada basada en experiencias pasadas.
Si Microsoft quiere mejorar la calidad de las aplicaciones en Windows, la solución no es solo arreglar Windows 11 y comprometerse a crear aplicaciones nativas propias, sino reconstruir la confianza con los desarrolladores y demostrar que esta vez, la plataforma (WinUI3, espero) será consistente.
