Développer plutôt un site ou une application ? Un site en ASP, MVC, appli WPF, WinForms ou appli Mobile Xamarin ? Le décideur a parfois à faire ce choix lui-même.

Développer un site, ce peut être imparable pour beaucoup de cas, lorsque par exemple on doit s’adresser au grand public.

De nombreux sites sont écrits avec des technologies non Microsoft. Quelques-unes de ces technologies sont satisfaisantes, les sites écrits en PHP restent honorables. C’est un moteur de taille moyenne plutôt fermé, auquel on peut adjoindre tous les éléments qu’on veut mais dont on ne peut pas dire qu’ils font partie du moteur. Il ne faut pas confondre JavaScript et Java. Java a beaucoup marché en France, parce qu’étant libre de droits il faisait partie des enseignements des diplômes du public. Il est depuis pas mal d’années en perte de vitesse. Peut-être parce qu’il a été racheté. Et donc les droits ne sont plus libres. La preuve, le procès contre J# de Microsoft.

Un développement avec les WebForms de Microsoft permet un assemblage de couches horizontales dans le domaine du Web. Le Web est à l’origine un simple langage de présentation. Ce qu’apporte ces couches est une panoplie surprenante d’outils et de fonctionnalités plates. Les WebForms, c’est comme une pâte à faire pas mal de choses, mais on ne peut pas lui demander d’être structuré partout, et en fait, chaque couche a son propre langage, avec des couches annexes qui ont-elles aussi leur propre langage : Serveur, Client, JavaScript, Ajax, JSON, Services, IIS, ActiveX, réseau… Il faut être forcément plusieurs pour développer de sites. On voulait l’utiliser parce qu’il n’y a rien à installer, je connais bien des outils en entreprise qui nécessitent d’installer des ActiveX ou autres composants tiers, qu’il faut installer séparément, et qui coupent la frontière de sécurité sans qu’on le sache, et qui sont de toute façon des applications eux-mêmes.

On voulait l’utiliser parce que le rendu aurait été identique partout, et on constate que les écrans sont tous différents entre les versions des explorateurs, les marques d’explorateurs, les marques de systèmes d’exploitation et la taille de l’écran, sans compter les problèmes qui surviennent sur certains d’entre eux. On peut considérer que les applications faites en WebForms ont très rarement un rendu qui satisfera les chefs d’entreprise qui ne sont pas largement tolérants. A l’ors actuelle, on a l’impression qu’il est normal d’être tolérant quand on fait un site plutôt qu’une application. J’étais encore hier en train d’ouvrir un menu Microsoft sur le Web, rien ne se passait quand je cliquais sur le sous-menu. On trouve des cas comme ça sur chaque grand site connu. Dans les applications en client lourd spécifiquement conçues pour Windows, on est bien au-dessus de cette barre de largesses, on réalise souvent des logiciels ne comportant pas de bugs graphiques, sans grand délai.

Le développement en mode MVC de Microsoft est là pour faire du développement de sites aussi, mais dans le but de remédier au grand problème des WebForms de n’être qu’une pâte multi-ingrédients. Ce qui permet d’avoir du code structuré et de s’occuper uniquement des tâches principales. C’est un peu un lecteur Web d’une structure écrite dans un langage précis. On a tout de suite accès à toutes ses possibilités, mais elles sont limitées, et on ne peut pas en ajouter plus, à moins de faire une apposition à côté. C’est plutôt bien pour l’intranet, bien que la présentation puisse être très jolie, en tout cas, c’est surtout prévu pour l’accès aux fenêtres de données d’information.

Pour l’instant, il n’existe pas de solution qui permette de détrôner les pouvoirs magiques jusqueboutistes des logiciels écrits directement pour Windows, particulièrement en WPF et XAML. Le WPF et ses acolytes est récent, il bénéficie d’une épuration de tout ce qui gênait ailleurs. Il n’a pas de limite graphiquement, et dès qu’on veut faire quelque chose d’un peu ou de très complexe, grâce à la synergie de l’emboîtage de piles d’objets les uns dans les autres, dont des objets pour améliorer grandement la puissance de l’exécution, le pouvoir est exponentiel lorsqu’on construit ses propres briques. Ce qui permet un gain de temps énorme, au minimum 3 fois moins coûteux qu’une application WebForms, généralement 5, pour des possibilités accessoires énormément accrues, un développement graphique propre, et une assurance qualité qui ne dépend pas des techniques employées. Généralement, les couches sont standardisées, sobres, et toutes écrites dans deux uniques langages, le code et le XAML. Il existe plusieurs moyens de déploiement parfaitement efficaces, même courant sur toute la planète, mais ce concepteur a pour vocation a être exécuté en entreprise, ou faire guise d’utilitaire, d’application, style Word de Microsoft, ou logiciel de gestion. Un de ses grands intérêts est d’avoir accès à tous les composants de l’ordinateur. Un petit problème est d’ordre sécuritaire, qui peut vite être résolu en faisant transiter les données par le cloud plutôt que de les traiter sur place. Le WPF est lourd mais pas compliqué sans raison, surtout utile pour monter en synergie.

Pour développer de toutes petites applications, il peut être intéressant de revenir à l’ancêtre qui a précédé WPF, le WinForms. Ce concepteur d’interface est beaucoup plus simple, ce qui permet d’éviter la lourdeur du WPF. Mais on peut aussi mélanger les composants écrits en WinForms et ceux écrits en WPF. Mais il peut se produire des impacts de non réponse avec les toutes nouvelles technologies, car il n’évolue plus.

Des acolytes du WPF ont été développés par Microsoft spécifiquement pour chaque version de Windows, dont Windows Mobile. Personnellement, je pense qu’il vaut mieux les éviter, ils possèdent beaucoup moins d’éléments que le WPF, et le principe de non réécriture des applications entre mobile et PC n’était pas au rendez-vous de la part de Microsoft jusqu’à leur rachat récent de Xamarin, une société qui a développé un langage compatible Microsoft, avec un genre de WPF incompatible Microsoft, mais qui joint le principal des trois types courants de mobiles, et avec un principe efficace de non réécriture des applications entre les trois. A noter que des bruits courent que Microsoft ne va pas continuer les mobiles Windows.

Cela va permettre sans-doute à Microsoft d’adjoindre à ce principe l’écriture simultanée de ces applications mobiles avec les applications Windows comprises, et peu à peu rapprocher la compatibilité des écritures ‘genre WPF’. En tout cas, on ne perçoit pas d’avenir où l’une ou l’autre des solutions soit avec un client lourd soit avec un serveur lourd seraient abandonnées. A noter aussi que désormais, dans toutes les solutions, il y a l’intervention du cloud, et dans beaucoup, le ‘genre WPF’.

Print | posted on Friday, July 6, 2018 12:35 AM

Copyright © Frédéric Decréquy

Design by Bartosz Brzezinski

Design by Phil Haack Based On A Design By Bartosz Brzezinski