Comparaison des outils de développement de bureau, Qt, Electron et macOS Native (Objective-C et Swift)
Comparaison des outils de développement de bureau, Qt, Electron et Native macOS (Objective-C et Swift) , par BumbleMeow
Introduction
Lorsque nous avons planifié le développement de l'application de bureau OEDcoder, nous avons examiné différentes solutions pour trouver celle qui répondrait le mieux à nos exigences techniques, financières, de performance, d'interopérabilité, d'UX ... etc. Il y a beaucoup d'options disponibles sur macOS et encore plus si l'on considère les solutions multiplateformes. macOS est notre principale plateforme cible mais nous pourrions distribuer notre application sur d'autres plateformes (Windows/Linux/ChromeOS). Après avoir examiné et prototypé de nombreux outils, nous avons rédigé un comparatif de nos trois premiers choix :
- Qt avec C++
- Electron avec JavaScript/TypeScript
- macOS Native (en Swift et/ou Objective-C)
Comparaison rapide
Exigences
Distinguer OEDcoder des autres outils d'encodage/décodage base64 existants :
- Simplicité d'utilisation : Doit être simple à utiliser pour tous les utilisateurs, quel que soit leur bagage technique.
- Haute performance
- Doit être capable d'encoder et de décoder rapidement avec un minimum d'étapes
- Doit être capable de maintenir un fonctionnement normal du bureau pendant l'utilisation en optimisant l'utilisation des ressources, notamment l'unité centrale, la mémoire et l'espace disque.
- Doit prendre en charge tous les fichiers d'entrée, quelle que soit la taille du fichier ou du lot.
- Sécurité
- Doit utiliser les meilleures pratiques de sécurité de macOS, y compris la notarisation, le sandboxing et le runtime renforcé.
- Ne doit pas utiliser de serveurs en ligne, de services ou de bibliothèques tierces non fiables.
- Confidentialité : Tous les traitements doivent être effectués sur l'appareil local. Personne d'autre que l'utilisateur ne doit avoir accès aux données encodées ou décodées dans notre application.
- Support de première classe pour macOS : Utiliser les éléments natifs de l'interface utilisateur de macOS et bien s'intégrer à macOS, comme le glisser-déposer.
- Prise en charge de la distribution via le macOS App Store : Utiliser le macOS App Store pour le traitement des paiements, la distribution et les révisions.
- Documentation : Doit fournir une documentation claire dans l'application, disponible en ligne et téléchargeable.
- Multiplateforme (souhaitable) : Doit prendre en charge macOS avec la possibilité de distribuer sur d'autres plateformes
Voici la démo du produit fini :
Comparaison des outils
Qt
L'un des premiers outils que nous avons essayé est Qt. Qt présente les avantages suivants :
- Multiplateforme : Qt fournit d'excellents outils et une assistance pour macOS, Windows et Linux. Il prend également en charge les plates-formes mobiles, bien que cela ne fasse pas partie du champ d'application d'OEDcoder.
- Choix du langage de programmation : Le langage de programmation « primaire » associé à Qt est le C++, avec un support pour d'autres langages, y compris leur propre langage Quick/QML qui ressemble à du JavaScript. Python est probablement le deuxième langage le mieux supporté en termes de liaisons et il existe une liste d'options parmi lesquelles choisir.
- Soutien commercial de la Qt Company : Nous n'avons pas nécessairement besoin ou besoin d'un support de niveau "entreprise" pour nos outils, mais il est bon de savoir que c'est une option.
- Excellent EDI C++ : Qt Creator est un excellent choix pour un EDI C++ et le concepteur d'interface utilisateur intégré fonctionne bien pour créer rapidement des interfaces utilisateur.
- Aspect quasi natif et intégration au système d'exploitation : Widgets d'interface utilisateur à l'aspect natif, mode sombre, glisser-déposer ... etc.
- Haute performance : Les versions de Qt App pour macOS pèsent environ 200 Ko (sans les dylibs, 47 Mo avec les dylibs intégrés ou 17 Mo statiques) et ont le même nombre minimum de threads, mais une utilisation minimale de la mémoire plus importante :
Pour une application minimale de type « Hello, World », Qt utilise deux fois plus de mémoire qu'Objective-C.- Une documentation abondante : La Qt Company et sa Qt Academy fournissent de bonnes ressources d'apprentissage et il existe des tonnes de tutoriels, de livres et de vidéos YouTube de qualité variable.
La principale considération pour l'utilisation de Qt dans les logiciels commerciaux est le prix. Bien qu'il soit possible d'utiliser Qt sous la LGPL, le respect de la LGPL pour les logiciels commerciaux peut s'avérer délicat. OEDcoder étant un projet à source fermée, nous sommes réticents à utiliser Qt sous LGPL, même si nous pouvions le faire légalement. De plus, Qt n'a pas une apparence native sur la plupart des plateformes.
Electron
La solution multiplateforme suivante que nous avons étudiée est Electron. Nous avons réalisé une petite démonstration de faisabilité basée sur un navigateur et il a été facile de l'intégrer dans une application de bureau. Voici quelques-uns des avantages d'Electron
- Multiplateforme : Avec un bon support pour macOS, Windows et Linux
- Choix du langage de programmation : Electron permet d'utiliser JavaScript, TypeScript ou tout autre langage pouvant se compiler en JavaScript.
- Mise en page standard : Pouvoir utiliser HTML et CSS pour la mise en page au lieu d'avoir à apprendre un autre système de mise en page propriétaire.
- Open Source avec le soutien d'une entreprise : Electron est soutenu par Github, qui appartient à Microsoft. Ils ont donc les ressources pour corriger les bugs et maintenir les choses à
jour.
- Bonne documentation : Le site principal d'Electron dispose d'une documentation bien rédigée et de nombreuses autres ressources sont disponibles en ligne.
- Utilisé par des entreprises de renom : De nombreuses entreprises de renom utilisent Electron pour leurs applications, notamment Github (pour Github desktop), Microsoft (VS Code, Skype, Teams), Figma, Twitch, Slack et d'autres.
Si l'utilisation d'Electron présente de nombreux avantages, elle présente également des inconvénients évidents :
- Utilisation élevée des ressources :
- L'utilisation de l'espace disque est énorme. Une application Electron « hello world » pour macOS pèse plus de 240 Mo pour une architecture à un seul processeur.
Pour une application minimale de type « Hello, World », Electron utilise 120 000 % d'espace disque en plus qu'une application minimale en Objective-C.- Utilisation de la mémoire et du CPU/thread :
Pour une application minimale « Hello, World », Electron utilise plus de 400% de mémoire qu'une application minimale en Objective-C.- Un poids important pour un petit outil : Il existe de nombreuses applications basées sur Electron qui fonctionnent bien (nous utilisons VS Code et Github Desktop presque tous les jours). Cependant, la comparaison est difficile pour le développement d'un outil léger comme OEDcoder.
- Performance de JavaScript vs C/C++/Swift : Les performances de JavaScript sur le moteur V8 sont bonnes, mais elles ne sont pas comparables à celles des langages compilés.
- Aspect non natif ressenti et vu : Vous pouvez créer de superbes interfaces utilisateur avec HTML et CSS, mais en général, elles n'auront pas un aspect "natif". Des choses comme la prise en charge du mode sombre dans macOS et Windows sont possibles, mais pas aussi faciles qu'une solution native.
- Architecture de l'application : Les applications Electron sont divisées en processus back-end et front-end et vous devez utiliser la communication inter-processus pour communiquer entre les deux. Ce n'est pas rédhibitoire, mais ce n'est certainement pas aussi simple qu'un exécutable monolithique.
Native MacOS
Après avoir passé en revue toutes les solutions possibles, nous avons décidé de nous concentrer sur la fourniture de la meilleure expérience pour macOS en utilisant des outils natifs. Il nous restait à choisir le langage de programmation et la boîte à outils à utiliser. Nous avons essayé Swift, à la fois avec SwiftUI et Storyboards, mais nous avons finalement opté pour Objective-C. Les principaux avantages de l'utilisation d'Objective-C avec AppKit sont les suivants :
- Taille réduite de l'application : Bien moins de 1 Mo pour l'ensemble de l'application
- Excellentes performances : Les frameworks Objective-C d'AppKit sont hautement optimisés et il est difficile de battre le C en termes de performances d'exécution. L'utilisation de la mémoire est également l'une des plus faibles parmi les solutions que nous avons essayées.
- Aspect natifs vu et ressenti : Le glisser-déposer, le mode sombre, les widgets de l'interface utilisateur et les jeux de couleurs ont un aspect familier et fonctionnent exactement comme l'attendent les utilisateurs de macOS.
- Support commercial : Objective-C, AppKit et Xcode sont tous "pris en charge" par Apple, même si les développeurs individuels ne bénéficient pas toujours de l'attention nécessaire.
- Concepteur visuel facile : Les Storyboards et Autolayout sont relativement faciles à utiliser et vous pouvez créer une interface utilisateur rapidement.
- Documentation hétéroclite : Le site web d'Apple destiné aux développeurs contient des tonnes de documentation et il existe de nombreux livres, vidéos et réponses Stack Overflow à consulter.
Quelques inconvénients liés à l'utilisation de la plateforme native macOS :
- Pas multiplateforme : Si nous décidons de distribuer OEDcoder sur Windows ou Linux, nous devrons écrire de nouvelles versions à partir de zéro.
- Outils et langages de programmation propriétaires : Xcode ne fonctionne que sur macOS, tandis que Objective-C et Swift peuvent être utilisés en dehors de macOS/iOS techniquement, mais dans des cas d'utilisation de niche tels que GNUStep. Swift est mieux supporté par Linux et Windows que Objective-C, mais l'accent est toujours mis sur les plateformes Apple, ce qui est compréhensible.
- Xcode : Nous ne nous attendons pas à ce qu'il n'y ait pas de bogues, mais les fonctions critiques telles que le contrôle de la source doivent être fiables. Lors de l'utilisation du seul contrôle de source intégré (c'est-à-dire Git), l'interface utilisateur de Xcode se désynchronise régulièrement avec le dépôt Git. Fermer et rouvrir Xcode résout temporairement le problème, mais après avoir remarqué des divergences de temps en temps et avoir perdu du travail par la suite, nous sommes passés à l'utilisation de Github Desktop pour le contrôle de version.
- Plusieurs solutions "officielles" : Apple fournit de nombreuses solutions "officielles" pour le développement macOS (Swift vs Objective-C, AppKit, Catalyst, Storyboards, SwiftUI, etc.) L'approche "recommandée" est toujours "la dernière et la meilleure", mais il se peut que vous deviez vous rabattre sur des technologies plus anciennes pour prendre en charge certaines fonctionnalités ou du matériel plus ancien.
- La documentation peut être difficile à trouver : Apple fournit une documentation abondante, mais il arrive que les réponses à des bogues ou à des "fonctionnalités" obscures ne se trouvent que dans des articles de blog et des vidéos WWDC datant de plusieurs années. Nous avons été touchés par une "fonctionnalité" de macOS mal documentée et sans détails spécifiques, la limite de fichiers de macOS Sandbox (qu'est-ce que cette limite exactement ?). La façon dont elle est mise en œuvre signifie qu'il n'y a pas de réponse définitive.
Réflexions finales
Les performances impressionnantes d'OEDcoder ont prouvé que le développement natif sous macOS était le bon choix pour répondre à nos besoins. Nous aurions probablement opté pour Qt si OEDcoder devait être multiplateforme ou si nous disposions d'un budget plus important. Electron est parfait pour les développeurs et les entreprises qui se concentrent principalement sur le développement web, mais ce n'est pas notre cas.
Si vous êtes un développeur web et que vous vous demandez « Qu'en est-il de Wails ou de Tauri ? Ils résolvent certains des problèmes d'utilisation des ressources d'Electron ». Nous les avons essayés, mais le fait de devoir utiliser plusieurs langages de programmation (Go ou Rust pour le back-end, JavaScript/TypeScript pour le front-end) augmente la complexité et le changement de contexte. De plus, seul Electron permet d'accéder au chemin d'accès complet des fichiers lorsqu'on les fait glisser depuis le Finder (c'est-à-dire notre condition sine qua non). Electron intègre une version de Chrome qui a été modifiée pour fournir le chemin d'accès complet lors du dépôt de fichiers depuis le Finder, tandis que Wails et Tauri utilisent tous deux WKWebView sur macOS, qui ne permet pas d'accéder au chemin d'accès complet.
Source : "Desktop Development Tool Comparison"
Et vous ?
Pensez-vous que cette comparaison est crédible ou pertinente ?
Voir aussi :
Répondre avec citation
Partager