IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Autres EDI Discussion :

Comparaison des outils de développement de bureau, Qt, Electron et macOS Native (Objective-C et Swift)


Sujet :

Autres EDI

  1. #1
    Nouveau candidat au Club
    Homme Profil pro
    Inscrit en
    Novembre 2024
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme

    Informations forums :
    Inscription : Novembre 2024
    Messages : 1
    Par défaut 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

    Nom : 1.jpg
Affichages : 40948
Taille : 75,5 Ko


    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 :

      Nom : 2.jpg
Affichages : 1820
Taille : 37,1 Ko
      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.

        Nom : 3.jpg
Affichages : 1816
Taille : 37,0 Ko
        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 :

        Nom : 4.jpg
Affichages : 1813
Taille : 37,2 Ko
        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 ?
    Quel est votre avis sur le sujet ?

    Voir aussi :

    La version 6.7 de Qt est disponible avec de nombreuses améliorations pour construire des applications modernes et une meilleure expérience utilisateur

    Electron 12 est disponible avec la prise en charge de l'API Web Serial et de nouvelles API pour activer/désactiver le correcteur orthographique

    OrbStack : un outil permettant d'exécuter des conteneurs Docker et des distributions Linux sur macOS qui se veut rapide, léger et simple. Il est présenté comme un substitut natif à Docker Desktop sur macOS

  2. #2
    Membre chevronné Avatar de der§en
    Homme Profil pro
    France
    Inscrit en
    Septembre 2005
    Messages
    936
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : France
    Secteur : Industrie

    Informations forums :
    Inscription : Septembre 2005
    Messages : 936
    Par défaut
    Il aurait dû aussi évaluer Delphi et son framework FMX ou Lazarus / FPC !

  3. #3
    Membre éclairé
    Femme Profil pro
    Inscrit en
    Juillet 2012
    Messages
    273
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Italie

    Informations forums :
    Inscription : Juillet 2012
    Messages : 273
    Par défaut
    Flutter, Fyne.io avec go, Maui, Uno platform ...
    Si je lis la license de QT, ça me passe l'envie de l'utiliser

  4. #4
    doc
    doc est déconnecté
    Membre expérimenté

    Profil pro
    Inscrit en
    Août 2002
    Messages
    105
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2002
    Messages : 105
    Par défaut
    multiplatforme -> java
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  5. #5
    Membre averti
    Profil pro
    Chef de projet
    Inscrit en
    Septembre 2008
    Messages
    51
    Détails du profil
    Informations personnelles :
    Localisation : France, Vosges (Lorraine)

    Informations professionnelles :
    Activité : Chef de projet

    Informations forums :
    Inscription : Septembre 2008
    Messages : 51
    Par défaut Qt reste un outil de choix
    J'adore l'environnement Qt, je ne le cache pas. Il permet de faire du C++ "à la façon" de langages plus modernes (Java, C#). Il permet de faire de l'UI comme maintenant (plein de scripts) ou à l'ancienne (en glisser/déposer sous Qt creator).
    Et c'est un environnement complet et cohérent: pas besoin d'un autre environnement pour traiter le XML, les pages web, l'impression ou les accès BDD.
    Je l'utilise d'ailleurs autant pour l'UI que pour des outils en ligne de commande.

    Alors oui, soit on fait de l'opensource, soit on passe durement à la caisse. Mais c'est un des rares environnement qui est compétitif par rapport à Visual Studio par exemple.

  6. #6
    Membre éclairé
    Profil pro
    retraité
    Inscrit en
    Décembre 2010
    Messages
    851
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : retraité

    Informations forums :
    Inscription : Décembre 2010
    Messages : 851
    Par défaut
    Pour Qt, la licence LGPL autorise la liaison statique ou dynamique, à condition que l'utilisation puisse changer la version de Qt.
    Il faut donc prévoir, un répertoire qui contient les DLL par exemple OU la possibilité de "créer" l'exécutable en embarqué en donnant le code objet et un mécanisme permettant la liaison statique.

    Là où c'est compliqué c'est que l'entreprise qui fabrique le système doit permettre que celui-ci puisse être flashé, par le client, qu'il puisse faire cela. Pas évident pour des IHMs médicales ou de voiture.

    Si quelqu'un a déjà fait cela pour l'embarqué son témoignage serait sympa.

Discussions similaires

  1. 57 % des employés de bureau américains utilisent des outils d'IA
    Par Jade Emy dans le forum Intelligence artificielle
    Réponses: 0
    Dernier message: 08/08/2023, 12h00
  2. Outils gratuits de comparaison des bases de données
    Par B_333333 dans le forum Décisions SGBD
    Réponses: 1
    Dernier message: 07/02/2014, 12h12
  3. Outils de comparaison des fichiers d'extension .ear
    Par B_333333 dans le forum Général Java
    Réponses: 1
    Dernier message: 05/02/2014, 10h21
  4. [Java] Jasper & FOP : comparaison des outils servant pour la génération de PDF
    Par sovop dans le forum Autres outils décisionnels
    Réponses: 1
    Dernier message: 13/06/2007, 10h46
  5. [WINDOWS] Barre des outils NT/2000 - intercept msg creation
    Par esa dans le forum API, COM et SDKs
    Réponses: 2
    Dernier message: 24/11/2003, 11h19

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo