Lorsque WhatsApp a pris la décision universellement détestée de remplacer son application Windows native par un wrapper Web, la plupart des critiques ont été adressées à Meta. Et à juste titre. Cela semblait paresseux, il s’agissait d’une rétrogradation claire, monopolisant la RAM, et cela supprimait le peu d’expérience « native » que l’application avait sous Windows.
Mais la réalité est un peu plus inconfortable.
Même Meta n’était pas vraiment incité à s’en tenir à une application Windows native. La société l’a à peine mis à jour, n’a pas apporté la parité des fonctionnalités et a finalement opté par défaut pour la version Web. La principale raison est probablement due au fait que les applications Web sont moins chères à créer et à maintenir. Mais le véritable problème est que Microsoft n’a pas fourni aux développeurs un cadre d’interface utilisateur dans lequel ils peuvent s’engager à long terme. Les applications Web n’ont pas ce problème.
Nous avons récemment entendu parler d’un lecteur de longue date de Windows Insight, Alexander Ovchinnikov, qui se trouve également être développeur. Ses arguments font écho à ce que ressentent déjà de nombreux développeurs.
Contrairement à macOS, qui obtient toujours des applications natives, malgré une base d’utilisateurs beaucoup plus réduite, l’attitude des développeurs à l’égard de la promotion d’applications Web uniquement pour Windows n’est pas une question de commodité. Il s’agit de confiance, ou plutôt de manque de confiance.
Au fil des années, Microsoft a introduit plusieurs frameworks « futurs », pour ensuite s’en éloigner. De WPF et Silverlight à UWP et maintenant WinUI 3, la société n’a pas changé ce modèle. Comme le dit Alexander, de nombreux développeurs supposent désormais que tout ce que Microsoft propose aujourd’hui ne durera peut-être pas assez longtemps pour justifier de s’en inspirer.
Microsoft n’a pas eu de stratégie claire en matière d’interface graphique depuis des décennies, et Windows propose désormais trop de frameworks sans réponse définitive sur ce que les développeurs devraient réellement utiliser.
Sachant cela change ma vision des applications Web pour Windows. Il s’agit d’une option de repli lorsque la plateforme elle-même semble incertaine. Cependant, l’intérêt récent de Microsoft pour la création d’applications 100 % natives pour Windows pourrait changer la donne.
Windows est passé d’un chemin de développement clair à trop de choix déroutants
Il fut un temps où la création d’une application Windows ne nécessitait pas de débat mental. Les premiers développements de Windows tournaient autour d’une approche unique et bien comprise. Win32 était la réponse. Une API, un modèle mental et une manière claire de faire avancer les choses.
La « Programmation Windows » de Charles Petzold, universellement considérée comme la « Bible » du développement Windows, l’a rendu accessible, et les développeurs ont pu investir leur temps en sachant que la plate-forme n’allait pas bouger sous leurs pieds. Cette stabilité a créé la confiance, et la confiance a fait croître l’écosystème.
Cependant, au lieu de faire évoluer Win32 vers quelque chose de plus moderne, Microsoft a continué à introduire de nouvelles couches et alternatives. MFC est d’abord venu en tant que wrapper C++. Puis WinForms pour les développeurs .NET. WPF a suivi avec XAML et le rendu accéléré par le matériel. Silverlight est apparu comme un pari multiplateforme. Puis vinrent WinRT et UWP à l’ère de Windows 8 et Windows 10. Et maintenant, nous avons WinUI 3 avec le SDK Windows App, aux côtés de MAUI pour le développement multiplateforme.
Chacun d’entre eux a été annoncé avec un discours fort sur l’avenir du développement Windows. Chacun a demandé aux développeurs d’investir du temps, d’apprendre de nouveaux modèles et de s’appuyer sur ceux-ci.
Le problème n’était pas que ces technologies étaient mauvaises. Beaucoup d’entre eux étaient véritablement en avance sur leur temps. Le problème était que le « futur » était constamment remplacé avant qu’il ne puisse être complètement réglé. Au lieu d’une plate-forme unique et évolutive, les développeurs se sont retrouvés à poursuivre des cibles mouvantes.
Le blog détaillé de Jeffrey Snover souligne que Windows n’a plus de réponse claire à une question simple : comment créer une application Windows ?
WPF était censé être l’avenir, jusqu’à l’arrivée de Silverlight, qui semblait prometteur, jusqu’à ce que Microsoft passe à HTML5. UWP a été présenté comme une plate-forme unifiée pour tout, mais n’a jamais été pleinement adopté, même en interne. WinUI 3 se positionne désormais comme la solution moderne, mais sa feuille de route n’a pas inspiré le même niveau de confiance que les développeurs avaient dans les époques précédentes.
Lorsque Microsoft introduira un nouveau framework avec une orientation claire, les développeurs commenceront à l’adopter. La stratégie changerait alors et l’attention se déplacerait ailleurs. Le cadre précédent ne serait pas toujours officiellement supprimé, mais il perdrait peu à peu sa pertinence. Ce cycle s’est répété suffisamment de fois pour que les développeurs aient cessé de s’engager pleinement.
Comme Alexander nous l’a dit, le sentiment actuel est le suivant : si Microsoft ne pouvait pas s’en tenir aux frameworks précédents, pourquoi supposer que le framework actuel sera différent ?
Voilà à quoi ressemblent les choses aujourd’hui. Demandez à un développeur ce qu’il doit utiliser pour une application Windows, et la réponse dépend de la personne à qui vous demandez. Certains recommanderont quand même Win32. D’autres préfèrent WPF car il est stable. WinUI 3 se positionne comme moderne, mais pas encore universellement fiable. MAUI existe pour une utilisation multiplateforme. Ensuite, il y a la voie Web avec Electron ou les PWA. En plus de cela, les frameworks tiers comme Avalonia et Qt gagnent du terrain.
Ce n’est pas le genre de choix que demandaient les développeurs. C’est l’incertitude totale.
Pourquoi les développeurs choisissent les applications Web plutôt que natives
Certaines des applications Windows les plus populaires ne sont pas véritablement natives. WhatsApp, Spotify, Discord, Slack, Notion, Zoom et même des parties du propre écosystème de Microsoft… Microsoft Teams (avant sa réécriture), Clipchamp et plusieurs expériences propriétaires utilisent WebView2.
Bien sûr, il est devenu si simple de créer une application Web une seule fois et de la diffuser partout. Il peut fonctionner sous Windows, macOS, Linux et même dans un navigateur sans maintenir de bases de code distinctes. Des frameworks tels qu’Electron, WebView basé sur Chromium et Progressive Web Apps ont rendu la distribution plus simple, les mises à jour plus rapides et les coûts de développement réduits. Les entreprises ont du mal à l’ignorer.
Le pivot de Microsoft vers WebView2 intègre le moteur Edge (Chromium) dans les applications. Cela fonctionne bien pour des raisons de cohérence, mais cela signifie également que de nombreuses applications « de bureau » ne sont que des pages Web exécutées dans un conteneur.
Et l’inconvénient évident est que ces applications consomment plus de RAM, semblent moins réactives et ne s’intègrent pas aussi profondément au système d’exploitation. L’exécution simultanée de plusieurs applications Electron peut facilement consommer des ressources système, ce que les applications natives gèrent traditionnellement bien mieux.
Sur macOS et iOS, les développeurs donnent toujours la priorité aux applications natives. Même les entreprises qui disposent de technologies Web ailleurs créent des versions natives pour les appareils Apple. C’est parce qu’Apple a maintenu une voie de développement beaucoup plus claire. Des frameworks comme Cocoa, AppKit et maintenant SwiftUI ont été constamment pris en charge et évolués. Les développeurs savent quoi utiliser et, plus important encore, ils savent que cela sera toujours pertinent des années plus tard.
Windows n’a pas la même clarté et les développeurs réagissent en conséquence.
Ainsi, au lieu de miser sur un framework qui pourrait encore changer de direction, beaucoup choisissent le web. Ce n’est pas parfait et, dans de nombreux cas, c’est objectivement pire pour les performances des ordinateurs de bureau. Mais cela élimine le plus grand risque de dépendre de la prochaine décision de Microsoft.
Microsoft essaie de résoudre ce problème, mais il est peut-être trop tard
Certains signes indiquent que Microsoft est conscient du problème. Des efforts récents suggèrent qu’ils s’orientent vers l’amélioration des performances, la réduction de la dépendance à l’égard des composants Web et la création de davantage d’expériences natives sur Windows. Le post X de Rudy Huyn invitant les développeurs Windows à créer des applications 100 % natives a été considéré sous un jour positif.
Mais réparer les applications elles-mêmes ne constitue qu’une partie de l’équation.
Même si Microsoft propose de meilleures applications natives à l’avenir, les développeurs continueront d’hésiter. L’hésitation ne vient pas de ce que WinUI 3 peut ou ne peut pas faire aujourd’hui. Cela vient de ce qui est arrivé à tout ce qui l’a précédé. Des années de changements de priorités ont rendu les développeurs prudents, et ce genre d’hésitation ne disparaît pas du jour au lendemain.
Si Microsoft veut changer cela, il doit s’engager pleinement dans un seul cadre et bien le communiquer aux développeurs. Cela signifie également s’en tenir à un cadre suffisamment long pour qu’il mûrisse, en précisant sa direction et en le soutenant. Les développeurs ont besoin d’une feuille de route à laquelle ils peuvent faire confiance, ainsi que de chemins de migration clairs lorsque des changements surviennent.
Le vrai problème n’est pas la technologie, c’est la cohérence
Microsoft ne manque pas de capacités. L’entreprise possède certains des meilleurs talents en ingénierie du secteur et une longue histoire dans la création d’outils de développement puissants. La plupart des cadres introduits étaient véritablement solides d’un point de vue technique.
Ce qui manque, c’est et c’est toujours la cohérence.
L’analyse de Rebecca Sutter mentionne que le problème n’est pas une défaillance technique, mais un modèle de décisions internes qui changent de direction à plusieurs reprises.
Cela s’est traduit à plusieurs reprises par une incertitude pour les développeurs. Vu de l’extérieur, la raison pour laquelle ces changements se sont produits n’a pas d’importance. Ce qui compte c’est le résultat. Les développeurs se sont retrouvés face à plusieurs voies, dont aucune ne semblait garantie de durer.
C’est pourquoi la situation est telle qu’elle est aujourd’hui. Le problème n’est pas que Windows propose trop peu d’options. C’est qu’aucun d’entre eux ne semble définitif. Les développeurs ne demandent pas plus de frameworks. Ils en demandent un en qui ils peuvent avoir confiance.
Les applications Web sont un symptôme, pas le problème
Les applications Web ne prennent pas le dessus sur Windows car elles sont mieux adaptées à l’informatique de bureau. Dans de nombreux cas, ce n’est pas le cas. Ils prennent le relais car ils offrent de la fiabilité aux développeurs qui ne souhaitent plus investir dans la plateforme Windows.
On ne peut pas reprocher aux développeurs de prendre une décision calculée basée sur leur expérience passée.
Si Microsoft souhaite améliorer la qualité des applications sur Windows, la solution ne consiste pas seulement à réparer Windows 11 et à créer des applications natives natives, mais à reconstruire la confiance avec les développeurs et à prouver que cette fois, la plate-forme (WinUI3, j’espère) restera cohérente.
Accueil
Partager
Bulletin
Bulletin WL
Newsletter WL !
Gardez une longueur d’avance grâce aux dernières mises à jour Windows, informatiques et IA. Approuvé par plus de 50 000 abonnés.
Nom
Courriel
Inscrivez-vous gratuitement
*️⃣ Lien source :
souligne , les applications Windows les plus populaires ne sont pas vraiment natives, créant davantage d’expériences natives sur Windows, les développeurs Windows doivent créer des applications 100 % natives, analyse de Rebecca Sutter , Accueil , Newsletter ,