Applications modernes

Quels langages utiliser pour développer des applications modernes ?

Rachel Appel

À l'heure actuelle, plus personne ne développe des logiciels modernes avec un seul langage. En effet, la programmation a évolué vers un modèle polyglotte composé de langages spécifiques à un domaine pour chaque niveau du développement. Par exemple, il est fréquent d'utiliser SQL et C# pour le serveur principal et HTML, JavaScript et CSS comme langages de l'interface utilisateur. Il est toujours conseillé à un développeur d'ajouter de nouvelles compétences à sa palette, mais l'utilisation d'un trop grand nombre de langages risque de réduire ses connaissances dans chacun d'entre eux. En outre, vous souhaitez généralement mettre les produits rapidement sur le marché, ce qui laisse souvent peu de temps pour l'apprentissage d'un nouveau langage et de toutes ses particularités. Idéalement, vous cherchez donc à vous familiariser avec des compétences complémentaires des vôtres. Lorsque vous créez des applications Windows Phone ou du Windows Store, plusieurs langages peuvent être utilisés dans chaque scénario de projet et au moins l'un d'entre eux complètera parfaitement votre expérience. Au cours de cet article, je présenterai les langages adaptés aux divers scénarios de développement. J'examinerai en outre les options que vous devez considérer et la façon dont des critères tels que l'accès aux données ou le portage d'une application ont un impact sur le langage que vous devez utiliser.

Le paysage des langages utilisés dans les applications modernes

Les ensembles de langages suivants sont disponibles pour le développement d'applications du Windows Store :

• HTML, JavaScript et CSS
• XAML et C#, ou XAML et Visual Basic .NET
• XAML et C++, ou DirectX et C++

Si vous développez sur la pile Microsoft, vous connaissez probablement certains de ces langages. Quant aux développeurs Web, bien évidemment, ils maîtrisent déjà HTML et ses amis. Il est logique qu'un grand nombre de ces ensembles de langages soient disponibles pour le développement Windows Phone : XAML et C#, Visual Basic .NET, et C++.

Qu'en est-il de HTML, JavaScript et CSS pour Windows Phone ? À l'heure où cet article est rédigé, la seule façon d'écrire du HTML dans une application Windows Phone est d'utiliser un contrôle WebView, une technique que l'on trouve généralement dans les applications hybrides (ce sont des applications mutantes moitié Web, moitié natives).

Si vous créez une application native interplateforme (et non un site Web) en dehors de l'écosystème Microsoft, le paysage des langages disponibles change et vous disposez des deux options suivantes :

• Java pour Android
• Objective-C pour iOS (d'un point de vue technique, d'autres options sont disponibles, mais j'aborderai uniquement Objective-C ici)

Fort heureusement, Xamarin est venu à la rescousse des développeurs .NET et Windows qui souhaitent écrire des applications interplateformes. Nul besoin d'apprendre Java (bien qu'il soit très proche de C#) ni Objective-C, le langage du développement iOS (nous reviendrons sur ce point plus tard).

Maintenant que vous avez une idée précise des langages à votre disposition, je vais décrire le degré de facilité ou de difficulté d'apprentissage de chacun d'entre eux.

Courbe d'apprentissage des langages

La solution de facilité est souvent la meilleure et sans aucun doute la plus rapide. Il est important de tenir compte des langages que votre équipe et vous-même connaissez déjà lorsque vous arrivez sur un nouveau territoire. Tout le monde n'est pas capable de passer aisément d'un langage à l'autre, notamment en ce qui concerne les langages qui se comportent totalement différemment. Cette adaptation est encore plus difficile pour certains développeurs juniors car ils manquent d'expérience avec les différents paradigmes de langage et commettent donc plus d'erreurs ou n'ont pas conscience des pièges courants. Même les développeurs expérimentés qui passent d'un langage compilé tel que le C# au JavaScript interprété peuvent rencontrer de nombreuses difficultés dans la mesure où ils ne voient pas les petites spécificités du langage, par exemple un mot clé qui se comporte différemment, un déplacement éventuel ou la myriade de particularités de JavaScript.

Heureusement, les développeurs Web continuent à apprécier le fait de travailler avec les mêmes HTML, CSS et JavaScript que dans le cadre de tout projet Web client, la seule différence lorsqu'ils écrivent pour Windows 8 étant l'ajout de la bibliothèque Windows pour JavaScript (WinJS). WinJS facilite l'écriture d'applications natives sur Windows 8 avec les langages Web. Vous continuez à utiliser les mêmes API standard ouvertes que lors d'un développement Web, mais vous utilisez également des bibliothèques propres à Windows pour accéder à l'expérience native.

Les développeurs qui sont habitués aux langages Web trouveront que la spécificité des contrôles HTML dans les applications du Windows Store est qu'il s'agit simplement d'éléments marqués d'attributs data-win*. L'utilisation de ces attributs permet au code WinJS principal et à certaines CSS de transformer ces éléments en magnifiques widgets de l'interface utilisateur qui créent une expérience native riche. Le code WinJS qui rend les contrôles contient des règles CSS qui appliquent l'ergonomie de l'interface utilisateur moderne de Windows 8. Le code WinJS principal crée également les contrôles plus complexes tels que les sélecteurs de dates et les grilles lors de l'exécution. Il peut en outre ajouter des éléments HTML de liaison des données aux tableaux ou objets JavaScript.

Les développeurs XAML des camps Windows Presentation Foundation (WPF) et Silverlight continuent à écrire le même XAML déclaratif pour la disposition de l'interface utilisateur, tout en utilisant C#, Visual Basic .NET ou C++ comme compagnon compilé. Vous ne serez pas surpris d'apprendre que XAML comporte de nouveaux espaces de noms et bibliothèques dédiés à l'expérience moderne de Windows 8.

Il existe de nombreuses parités parmi les langages déclaratifs (c'est-à-dire tout langage ML) en termes de quantité et de qualité des contrôles d'interface utilisateur. En général, si vous trouvez un contrôle dans le XAML, il y a de grandes chances pour qu'il existe dans le HTML ou la bibliothèque WinJS, et inversement. Il existe toutefois une ou deux différences entre les deux.

Les développeurs XAML remarqueront à peine un changement, à l'exception de quelques espaces de noms et de diverses autres modifications simples. Expression Blend reste un outil exceptionnel pour la conception d'interfaces utilisateur en XAML, tandis que Visual Studio est plus adapté au langage compilé en arrière-plan. Il existe un vaste écosystème tiers autour des contrôles d'interface utilisateur XAML, par exemple des grilles pour XAML sur la plateforme WPF, et un grand nombre de ces contrôles fonctionnent de façon identique ou similaire entre les applications Windows Phone et celles du Windows Store.

En dernier lieu, si vous êtes développeur Windows Forms, il est temps d'apprendre le XAML car vous n'avez presque pas d'autre choix. Vous ne pouvez pas utiliser de langage d'interface utilisateur comparable car Windows Forms n'en a pas ; seuls C# ou Visual Basic .NET se trouvent derrière une palette de conception. Bien que vous puissiez utiliser vos compétences générales en .NET et en différents langages, vous devez apprendre le DSL de l'interface utilisateur : XAML. Vous pourriez apprendre le HTML, mais vous devriez alors ajouter CSS et JavaScript, et donc apprendre trois langages. Or cet apprentissage n'est pas une mince affaire.

L'accès aux données a une incidence sur le choix du langage

Le mode d'accès aux données varie, et parfois beaucoup, entre les langages. En outre, le type de données auquel vous avez affaire détermine également la façon dont vous accédez aux données. Tout d'abord, certaines techniques sont disponibles uniquement pour un ensemble de technologies ou un autre, comme c'est le cas avec le stockage Web (également connu sous le nom de Stockage DOM et avec lequel vous pouvez vous familiariser en consultant le billet de mon blog intitulé « Gestion des données dans les applications Web avec le stockage Web HTML5 », sur bit.ly/lml0Ul) et IndexedDB. Vous pouvez utiliser ces deux technologies uniquement avec les langages basés sur le navigateur, par exemple JavaScript.

Les Services mobiles Windows Azure (au sujet desquels vous trouverez des informations complémentaires dans un autre billet du blog intitulé « Utiliser les Services mobiles Windows Azure pour alimenter les applications Windows Phone et celles du Windows Store » sur bit.ly/15nhO8d) et la plateforme Windows Azure offrent plusieurs API natives pour toutes les plateformes populaires, ainsi que des API REST qui sont interplateformes par nature. Étant donné que REST est une norme ouverte, vous pouvez accéder à ses données depuis n'importe quel langage, n'importe où et à tout moment depuis une interface cohérente. Les interfaces REST facilitent le développement interplateforme car, malgré la syntaxe et les spécificités du langage, le code a une cohérence ou un modèle global. Les API publiques, telles que celles fournies par Twitter, Facebook, les services météorologiques, etc., retournent généralement du JSON ou XML (ou les deux) que vous utilisez par l'intermédiaire de REST ou de XMLHttpRequest (XHR).

SQLite est une option de base de données locale disponible sur toutes les plateformes et pour tous les langages. SQLite est disponible sous forme de package NuGet pour les applications Windows Phone et celles du Windows Store dans Visual Studio 2012. Vous pouvez également y accéder à l'aide de l'ensemble d'outils Xamarin et utiliser ses bibliothèques afin d'accéder aux bases de données SQLite sur iOS et Android. SQLite est plus facile à utiliser avec les applications XAML qu'avec les applications HTML.

L'accès aux fichiers et les E/S de fichiers sur la plateforme Windows sont au même niveau entre les applications XAML et HTML du Windows Store. C'est pourquoi le langage n'a pas vraiment d'importance lorsque votre application a besoin des capacités de lecture et d'écriture pour le système de fichiers. Bien que le HTML et le JavaScript standard dans le navigateur aient de nombreuses restrictions sur les opérations d'E/S du fichier et l'accès aux ressources du système, le modèle de développement des applications du Windows Store permet un accès plus que suffisant au système de fichiers tout en garantissant la sécurité.

Afin d'obtenir plus d'informations sur les technologies d'accès aux données pour les applications Windows Phone et celles du Windows Store, consultez mon article publié en mars 2013, « Accès aux données et options de stockage dans les applications du Windows Store » sur msdn.microsoft.com/magazine/jj991982.

Considérations interplateformes

Objective-C est différent des autres langages d'un point de vue syntaxique et opérationnel, alors que Java et C# se comportent de façon similaire dans la mesure où il s'agit de langages gérés. Toutefois, si vous écrivez des applications interplateformes, vous n'êtes pas condamné à avoir des codes base distincts, par exemple Objective-C pour iOS, Java pour Android et C# pour les plateformes Windows, car les outils Xamarin mentionnés précédemment facilitent l'écriture en C# et la génération de Java et Objective-C. Xamarin fournit un ensemble d'outils de génération de code natif pour le développement d'appareils interplateformes (c'est-à-dire les tablettes et les appareils mobiles) et il s'agit du plus petit dénominateur commun pour le développement natif interplateforme. Par conséquent, quelle que soit la plateforme de prédilection d'un développeur, il peut aisément utiliser ses compétences sur la plateforme Windows ou sur plusieurs plateformes à l'aide de Xamarin et C#. Les développeurs spécialisés dans les plateformes iOS et Android gagneront à sélectionner C# comme langage de prédilection s'ils souhaitent publier sur la plateforme Windows, ainsi que sur les autres plateformes. Notez toutefois qu'à Redmond, tous les développeurs ne sont pas d'accord et certains soutiennent qu'il est plus pratique de développer des bibliothèques en C++ et C car iOS et les applications Windows peuvent y accéder, directement dans le premier cas et via les composants Windows Runtime, WinRT, dans le second. Ils rappellent que cette approche est « gratuite » (alors que la plupart des outils Xamarin ont un coût) et plus performante que les outils tiers. Pour ma part, je pense qu'il est préférable de créer et de partager simplement les composants Xamarin car le délai de commercialisation est un critère plus important que les avantages négligeables en termes de performances. En outre, je ne suis pas un adepte de l'utilisation du C++.

Le portage depuis des codes base hérités a un impact sur le choix du langage    

Toutes les applications ne sont pas totalement nouvelles ou réécrites. En fait, la plupart sont même héritées, plus particulièrement si le code que vous écrivez est destiné à une entreprise. La plupart des applications font véritablement partie d'un écosystème plus important de logiciels constitué de plusieurs applications ou de plusieurs interfaces utilisateur qui interagissent avec la logique métier, les couches de service, les API ou les bibliothèques publiques.

La migration des applications Web en particulier peut poser quelques problèmes dans la mesure où vous devez souvent garder intact le contenu d'un site Web existant, tout en intégrant ce même contenu dans l'application cliente et en donnant l'impression qu'il s'agit d'une expérience native. En effet, les entreprises exigent souvent que le site Web ou l'architecture d'origine restent inchangés. C'est la raison pour laquelle l'ergonomie de l'application peut sembler différente de celle du système d'exploitation hôte, ce qui complique l'utilisation et peut bloquer le flux de travail naturel de l'utilisateur. Heureusement, si vous portez un site ou une application Web qui existe déjà, vous avez souvent la possibilité de choisir l'intégration à la place. Le cas échéant, l'infrastructure Apache Cordova (anciennement PhoneGap) peut vous être utile. Cordova vous permet de créer des applications natives Web hybrides grâce à l'intégration du contenu Web et des composants d'interface utilisateur natifs et à la publication interplateforme. Inversement, l'intégration d'un contenu Web avec une application du Windows Store WinJS native n'est pas difficile à effectuer à l'aide de WinJS et l'expérience est généralement plus agréable pour l'utilisateur. Les applications natives bénéficient d'une expérience d'intégration plus proche avec le système d'exploitation que les applications Web clientes car elles ont accès aux ressources matérielles modernes, telles qu'une caméra, un microphone, les paramètres d'appareils, les accéléromètres, la géolocalisation, etc. En outre, les applications natives ont un cycle de vie distinct et contiennent un état, contrairement aux applications Web qui sont légères et sans état.

Le but de l'application est important

Dans une certaine mesure, le type et l'objectif de votre application déterminent le langage utilisé. Les jeux à forte intensité et les applications graphiques sont adaptés aux langages tels que le C++ et DirectX (qui fait désormais partie du Windows SDK) dans la mesure où vous pouvez être plus proche de l'ordinateur et améliorer ainsi vos performances tout en bénéficiant d'un meilleur contrôle de l'appareil. DirectX est une collection complète d'API de base auxquelles vous pouvez accéder par l'intermédiaire du C++ afin de créer des applications et des jeux exceptionnels. L'inconvénient de C++/DirectX est le code complexe qui peut facilement créer des problèmes. C++ n'est pas non plus la seule option pour les jeux. Les applications JavaScript (oui, vous avez bien lu, JavaScript) offrent des performances exceptionnelles, notamment pour les jeux en réseau. Le conteneur d'exécution de l'application du Windows Store décharge le traitement des scripts vers le GPU et JavaScript peut ainsi être exécuté parallèlement, sans être affecté par la présentation effectuée par le moteur de disposition Trident. Cette notion de déchargement fait de JavaScript un langage très rapide dont les performances peuvent être aussi satisfaisantes que celles d'un code natif. Si les performances sont importantes pour vous, mais que vous ne souhaitez pas apprendre C++, optez pour le canvas HTML.

Si vous écrivez des applications métier et de productivité, vous pouvez généralement choisir le langage qui vous convient car les performances et les contrôles d'interface utilisateur, entre autres, sont extrêmement similaires. Ces applications ont tendance à être du type courant « formulaires sur données ». L'ensemble actuel de technologies détermine généralement les choix en matière de langage et de technologie pour ces types d'applications.

Qu'en est-il de F# ?

Vous vous demandez ce qui est arrivé à F# ? Bien que F# ne soit pas l'un des modèles de base pour le développement des applications Windows Phone et celles du Windows Store, vous pouvez référencer et utiliser des composants créés en F#. Ce langage est également très intéressant pour traiter les analyses et exécuter le code sur le serveur principal (et toutes les applications ont besoin d'un serveur principal).

Les développeurs Web utilisent souvent un mélange de CSS pour donner un style au HTML et au JavaScript qui permettent tous deux de créer des interfaces utilisateur modernes. Les développeurs natifs disposent d'un ensemble de langages simultanés pour ces mêmes interfaces. Il vous revient donc de considérer tous les facteurs susceptibles d'avoir un impact sur votre application lorsque vous choisissez un langage.

Rachel Appel est consultante, auteure, mentor et a travaillé pour Microsoft. Elle dispose de plus de 20 ans d'expérience dans le secteur informatique. Elle participe aux conférences majeures du domaine, par exemple Visual Studio Live!, DevConnections, MIX, etc. Elle est experte en développement de solutions répondant aux exigences professionnelles et technologiques, et se concentre sur la pile de développement Microsoft et le Web ouvert. Pour plus d'informations sur Rachel Appel, consultez son site Web à l'adresse rachelappel.com.

Merci aux experts techniques Microsoft suivants d'avoir relu cet article : Eric Schmidt (erschmid@microsoft.com) et John Kennedy (jken@microsoft.com)