Le modèle de développement selon Microsoft est très complexe car il est permissif. En effet, Microsoft n’impose rien, Microsoft propose des technologies au fur et à mesure des années et des nouveaux kits de développement. Mais comment décider ; que choisir pour développer une application ?

Si on suit la BUILD 2020, on parle de MAUI et de WinUI3. Soyons clair, ce n’est pas sérieux. Voici le détail de mon analyse.

Un rappel historique

Dans les années 90, 2000, le modèle était le suivant : Windows C Win32, C++ MFC ou Visual Basic, voir Delphi (Borland). Le modèle de ces années là est la domination du monde fenêtré. Soit SDI (Single Document Interface) soit MDI (Multi Document Interface). Le modèle MDI était populaire avec Word, Excel et consistait à avoir plusieurs fenêtres ouvertes dans la même application. Avec le modèle MDI, le paradigme était la programmation objet et le modèle des User Controls et de OLE2. OLE2 c’est les composants COM, les contrôles ActiveX, le pilotage OLE Automation et les Compound Documents ou documents composites qui consistent par exemple, à mettre un bout d’Excel (des graphiques) dans un document Word. Ce modèle OLE2 n’a jamais été égalé par se sophistication et sa beauté (oui c’est beau). Il faut reconnaitre qu’il y avait une certaine complexité avec toutes ces interfaces COM mais le résultat était magnifique. Les contrôles ActiveX ont eu un certain succès et l’avènement a été Visual Basic 6 avec ses multitudes de contrôles OCX.

L’arrivée de NET en 2001

En 2001, Microsoft présente NET avec Windows Forms. C’est un succès immédiat.

WPF en 2006 dans Vista

En 2006, Microsoft distribue WPF dans Windows Vista. Nom de code Avallon, de grandes ambitions ais l’OS Vista est une catastrophe et le projet est retardé et l’OS ne contiendra rien fait en NET. Tout sera implémenté en C++ cat WinDiv n’est pas content de NET (fiabilité, robustesse, vitesse). Il y a des incompréhensions entre DevDiv (qui produit NET) et WinDiv et le fossé est toujours présent en 2020 !

La mort de Windows Phone et Silverlight

Quand Microsoft sort le Windows Phone, avant 2010, seul le C# et WPF sont autorisés. XAML everywhere. L’adoption en terme d’apps est un fiasco. Le C++ est alors supporté mais le mal est fait. Le Store ne contient aucune apps ou si peu. De plus, WPF et Silverlight ne tiennent pas leurs promesses. C’est lourd, c’est lent, le modèle MVVM est indebuggable. La cata. La division WInDiv reprend les choses en main et coupe la branche. Silverlight est dead. Enfin en LTS mais il n’y auara plus d’évolutions. On sait ce que Microsoft veut dire dans ces cas-là. Quand les réponses ne sont aps données et que l’on en parle plus, on sait ce que cela veut dire.

Windows 8

En parallèle, en 20011, Windows 8 sort son modèle d’applications Metro. Les fans du NET pensent que NET est enfin dans Windows ! Manqué ! C’est des contrôles natifs fait en C++, les fameuses API WinRT faites… en COM. Microsoft ne parle plus de WPF et le modèle c’est WinRT, COM et XAML.

Pire, les applications Store et Accessoires sont faites en JS avec WinJS. Courrier est le parfait exemple. Pour le camp WPF, c’est une trahison. JS est mis en avant à la place de C# et NET et surtout WPF. Le Manager de WPF démissionne après avoir vidé son sac sur reddit et enflammé la toile. Microsoft ne bouge pas et confirme que le retour est au Win32 et à COM et surtout que les erreurs Windows Phone se seront plus commises ! Dans le monde Windows, on ne renie pas la famille Win32 sans impunité. Win32, c’est GDI32, USER32 et KERNEL32, c’est l’héritage de Dave Cutler, le père de Windows NT, Dieu. Les Boss de Windows ont sifflé la fin de la récréation. Les ISV ont indiqué que WPF ne permet pas de faire des applications Desktop comme ils le désirent. Le problème, c’est que de nombreux développeurs ont rejoint le rang de la communauté NET pour faire du XAML et du WPF. Il y a un certain désarroi dans la communauté WPF. Ils se sentent trahi par Microsoft. Il faut dire que Microsoft joue sur les deux tableaux en prônant la modernité et nous ressort du COM et des extensions à IUnknown… Moi à ça me plait car c’est mon monde et je sais que chaque classes C# est un composant COM mais le commun des développeurs NET ne le sait pas.

Windows 10

Depuis WinRT, Microsoft a sorti un framework pour ocntinuer l’avenir OLE2. Oui Monsieur ! WinRT arrive avec un framework nommé WRL (Windows Runtime Language) et surtout C++/CX, un C++ qui supporte WinRT et le XAML. Ce sont des templates C++ qui prennent la suite de ATL/COM. ATL est une suite de templates C++ pour faire du COM et de OLE2. C’est très efficace et toujours utilisé.

NET Core

Microsoft fusionne NET Framework et NET Core 3.1 pur faire NET 5. Il va y avoir un nouveau designer pour WinForms et WPF.

MAUI

La fusion de Xamarin.Forms, Mono avec GTK+ va fournir un environnement multi-plateforme qui va séduire de nombreux nouveaux venus dans le monde Microsoft. A suivre…

WinUI

En 2019, Microsoft annonce un projet open-source XAML Island permettant l’inclusion des contrôles Windows 10 dans les application NET et Win32. Rapidement renommé WinUI, se projet open-source prend de l’importance chez Microsoft et c’est propulsé comme l’avenir de l’UI selon Microsoft à la BUILD 2020. L’application de référence est XAML Control Gallery et présente les contrôles simples et la panoplie de contrôles XAML disponibles dans Microsoft.UI.Xaml.Controls.dll. Ces contrôles natifs sont livrés avec leur code source et disponible sous forme de package Nuget pour C# mais aussi utilisable en WinRT avec CPP/WinRT de Kenny Kerr.

La Question à 1 million de dollars : Que choisir ?

Là c’est ouvert. Les développeurs s’accrochent aux branches. NET Core leur ouvre un second souffle. Mais le grand gagnant est le retour de WinForms pour NET Core. Pourquoi ? Parce que c’est simple, orienté objet et évènementiel et surtout utilisable par tous. IL n’y a pas de modèle foireux comme MVVM. Les évènements arrivent dans des routines et on gère tout dedans. Même en faisant de la délégation à une classe centrale, tout est débuggable. Bref, ce n’est pas WPF et MVVM. Quand une technologie n’est pas simple, elle n’est pas adoptée.

XAML

Je suis très sceptique sur XAML. C’est le cœur de WPF et la mayonnaise n’a jamais prise. Déjà, le XAML est illisible. Le modèle MVVM est complexe est non standardisé. Tout le monde fait le sait. C’est foireux ! WinUI se veut l’avenir mais c’est du XAML. Alors je dis oui mais à une condition. Pas de modèle MVVM. Pas de commandes, pas de routing, pas de messages, pas de binding. On fait du XAML évènementiel comme ne WinForms. Les samples Microsoft me donnent raison, il n’y a pas de MVVM.

Win32 et C/C++ (for ever)

Le cœur de Windows est fait en C et en C++. Le modèle Windows repose toujours (et encore plus maintenant) sur le C++ Moderne (C++17) et la base de code installée en C/C++ est tellement importante que Microsoft ne fera pas la révolution. WinUI passera par l’introduction simple de contrôles XAML dans les applications existantes. Cela fera partie de Windows et du Windows SDK comme CPP/WinRT. Il n’y a que les néophytes qui pensent que Microsoft fera la révolution en NET et en C#. Microsoft fait 95% de ses logiciels en C++. La performance est primordiale. D’ailleurs, le projet Réunion à pour but de délivrer du C++ pour tous les langages via des projections (principes de CPP/WinRT) via les nouvelles API faites en WinRT. Les packages VCLibs et Microsoft.XAML sont la preuve de ce mouvement.  Autre application faites en WinUI, le Windows Terminal. Il incorpore cmd, powershell et bash. Il y a un support WinUI pour les Settings et les onglets (Tabs).

La stratégie floue de Microsoft

Microsoft produit des technologies et des produits. D’un côté, il y a Azure et de l’autre Windows, Office et les produits serveurs. Microsoft veut de nouveaux développeurs sur sa plateforme donc il y a aussi du TS, du Rust/WinRT et du React Native. Microsoft est une grosse machine et il est parfois nécessaire d’avoir le point de vue des vieux gurus pour s’en sortir. Chez Microsoft, il y a des technologies pour les POC et des technologies pour faire des vrais logiciels qui durent mais aussi du jetable.

Conclusion

Ce n’est pas parce que ça existe qu’il faut l’utiliser

Confucius.