Contexte
Nous sommes une petite équipe de développement, nous créons un nouvel outil pour travailler avec l'API
Testmace . En fait, il s'agit d'un client de repos avancé avec la possibilité de créer des tests d'API automatisés à l'aide d'une interface graphique, équipé de fonctionnalités intéressantes telles qu'un mécanisme de variable avancé, une saisie semi-automatique dans tous les champs de saisie et une coloration syntaxique totale.
Je veux vous raconter comment nous sommes arrivés à Electron en tant que technologie pour écrire notre application.
Pourquoi le bureau
Au cours des 10 à 15 dernières années, le Web a connu une croissance explosive et continue de croître rapidement. Il existe constamment de nouveaux outils pour créer des applications Web de plus en plus fonctionnelles et complexes. Même des langages de programmation entiers sont créés, affinés pour l'écriture d'applications Web et presque sans solutions prêtes à l'emploi en dehors de cette zone. Et dans notre vie quotidienne, nous avons déjà partiellement remplacé Microsoft Office et Thunderbird par Google Docs et l'interface Gmail.
Cependant, le Web ne peut pas encore complètement remplacer les applications de bureau, et pour les raisons suivantes:
- Manque de réactivité des applications Web. Quelque part, la raison est la synchronisation client-serveur et Internet lent, quelque part la nature à un seul thread de javascript, et quelque part la gourmandise du navigateur sur votre machine pas très puissante. Il convient de noter que la solution aux problèmes ci-dessus n'est qu'une question de temps. En particulier, les travailleurs Web sont déjà pris en charge par tous les navigateurs modernes, ce qui résout partiellement le problème du multithreading, et des fonctionnalités telles que SharedArrayBuffer peuvent réduire la surcharge de copie de mémoire entre le thread principal et les travailleurs.
- Accès aux ressources du système local. Il existe des classes entières d'applications (gestionnaires de fichiers, tweakers, démons et services) qui ne peuvent pas être implémentées en tant qu'applications Web (au moins à ce stade de développement).
- Limitations des capacités du navigateur lui-même. Par exemple, l'interaction réseau n'est limitée que par l'envoi d'une demande http et la connexion via des sockets Web. Les choses de niveau inférieur (TCP, sockets de mise à jour), hélas, ne sont pas disponibles.
- Limitations artificielles des navigateurs pour des raisons de sécurité. CORS, travailler avec des cookies, restrictions sur les en-têtes envoyés.
- Un ensemble limité de langues et d'approches. Contrairement aux applications Web, où javascript reste le seul langage pour écrire des applications, les applications de bureau vous permettent d'utiliser n'importe quel langage de programmation jusqu'aux assembleurs, d'utiliser efficacement les ressources système en utilisant une programmation multithread et des instructions de bas niveau. Il convient de noter que la situation s'améliore sur ce problème - les transpilers de certaines langues apparaissent en javascript. De plus, la compilation dans webassembly vous permet de transférer le temps de fonctionnement à partir d'autres langages (C ++, C #, rust, etc.), obtenant souvent une bonne amélioration des performances.
Compte tenu des raisons énumérées ci-dessus, nous pouvons conclure que TestMace devrait être une application de bureau typique:
- Nous devons avoir accès au système de fichiers pour travailler avec le projet.
- Les limitations de l'extraction ne permettent pas un contrôle total sur la configuration et l'exécution de la demande.
- À l'avenir, nous aurons peut-être besoin d'optimisations de bas niveau pour améliorer les performances des applications.
Sélection de technologies
Nous avons décidé que notre application sera de bureau, mais nous n'avons pas encore décidé du langage et des technologies sur lesquels nous allons l'implémenter. En ce qui concerne les langages de programmation, nous avons les exigences suivantes pour eux:
- Il doit s'agir d'un langage tapé statique.
- Le langage devrait avoir une infrastructure large et mature - il devrait y avoir à la fois des bibliothèques éprouvées et le support de l'IDE et d'autres outils.
- La langue doit être familière à la plupart des membres de l'équipe.
Le dernier point est également important. En tant que startup, nous souhaitons le lancement le plus rapide (dans les six mois) du produit sur le marché, en utilisant au maximum les ressources internes de l'équipe. L'apprentissage d'une nouvelle langue et d'une nouvelle infrastructure réduit la prévisibilité de la planification et est semé d'erreurs dans l'adoption de certaines décisions.
Quoi qu'il en soit, la liste des exigences ne semble pas trop rigide, et les langages tels que C #, TypeScript, Go le satisfont. Nous procéderons à la sélection supplémentaire des technologies en tenant compte de la disponibilité des implémentations des composants nécessaires pour ces langages.
Les choses sont beaucoup plus intéressantes avec le choix des solutions pour développer une interface utilisateur. Les exigences pour eux sont les suivantes:
- Multiplateforme (Windows, Linux, MacOS)
- Un riche ensemble de composants intégrés et tiers
- Personnalisation des composants
- Langage de balisage pour la description de l'interface
- Bon support
Considérez quelles solutions conviennent à ces exigences.
Qt (Qml)
Qt est une puissante boîte à outils pour l'écriture d'applications multiplateformes. Dans les dernières versions de ce framework, le composant Qt Quick est apparu pour l'écriture d'applications à l'aide du langage de description de balisage QML déclaratif. Qt en général, et QML en particulier, sont des solutions éprouvées au combat qui ont trouvé leur application dans presque tous les domaines - de l'embarqué aux coques logicielles des systèmes d'exploitation.
Le langage de programmation principal de Qt est C ++ (vous pouvez utiliser javascript en QML). Cependant, pour Qt et QML, il existe des liants pour d'autres langages de programmation (par exemple, pour
C # ). Cependant, seule l'intégration python est
officiellement prise en charge. Tout le reste est une implémentation tierce. D'accord, je ne voudrais pas confier la partie la plus élémentaire de l'application à la bibliothèque, qui est développée comme passe-temps par un petit groupe de passionnés.
Il y a aussi un projet
Brig . Ce sont des liants NodeJS pour QML. Une caractéristique distinctive de ce projet est
une démonstration impressionnante . Cependant, comme cela arrive souvent dans les projets open source, les auteurs ne prêtent pas l'attention voulue au projet et, par conséquent, il perd également sa trace.
GTK
Une bibliothèque pour construire une interface utilisateur, qui a commencé dans le cadre d'un projet GIMP et a ensuite été séparée en un projet distinct. Il existe un outil
Glade pour le développement rapide de l'interface utilisateur. Le langage principal pour développer GTK est C, mais il existe des liants pour de nombreux
langages de programmation populaires . De plus, à l'aide de
liants C # , MonoDevelop a été créé - l'un des IDE les plus puissants pour le développement sous C #. Cependant, après une étude plus approfondie, nous comprenons que le projet GTK # est dans un état semi-abandonné - le dernier commit a été en février 2018, le prochain en janvier 2017 puis 2016. Par commit par an. Ce n'est pas épais étant donné que le
référentiel gtk principal se développe activement. Et le bonheur était si proche ...
Electron
Récemment, beaucoup de bruit est associé à ce cadre. Quelqu'un le félicite pour l'opportunité de transférer les réalisations des applications Web sur le bureau, quelqu'un déteste la gourmandise excessive. Les deux peuvent être compris. Electron sous le capot utilise node.js et la bibliothèque de rendu Chromium. En fait, une application Web standard est créée et enveloppée dans un fichier exécutable. De plus, chaque application est livrée avec sa propre version de Node.js et Chrome.
En fait, il n'y a qu'un seul inconvénient, mais assez grave - c'est une consommation de mémoire importante (par rapport à d'autres technologies): un projet vide prend 100 à 200 mégaoctets de mémoire. Pour certains, c'est la raison de refuser d'utiliser de telles applications (bonjour, Skype). Analysons cependant la situation du marché. Actuellement, de
nombreuses applications populaires sont écrites en Electron (Slack, Skype, Discord, VSCode, Atom, Postman, Insomnia, etc.). Beaucoup d'entre eux sont des standards dans leur domaine ou gagnent rapidement le cœur des utilisateurs (comme les mêmes VSCode et Insomnia). Les gens utilisent simplement des outils qui résolvent bien leurs tâches quotidiennes, malgré certains effets secondaires. D'un autre côté, les ordinateurs deviennent plus puissants (au moins la croissance de la RAM n'a
pas cessé ), et vous entendez de moins en moins de commentaires de clients mécontents que "votre chrome a mangé toute ma mémoire". En résumé, nous pensons que l'augmentation de la consommation de RAM ne jouera pas un grand rôle si le produit est vraiment bon dans son domaine.
Les avantages de cette technologie sont évidents:
- La possibilité d'utiliser les meilleures pratiques du Web.
- Il est plus facile de trouver des spécialistes dans ce domaine.
- Le «concepteur» - «concepteur de mise en page» - «programmeur» de workflow épuisé, regorge d'outils pratiques à chaque étape.
Un plus, nous incluons le fait que l'équipe possède une vaste expérience dans la création d'applications frontales.
En conséquence, nous avons choisi Electron comme principal outil de développement de notre projet. Automatiquement, nous avons choisi TypeScript comme langage de développement de l'application.
Conclusion
L'une des principales tâches d'une startup est le lancement rapide d'un produit sur le marché. Cool si vous pouvez le faire à moindre coût. Le but de cette analyse était de trouver un outil qui nous permettrait de résoudre ces problèmes. À notre avis, Electron nous convient parfaitement. Trois mois après le début du développement, il est toujours hors compétition, et il semble que tout soit sérieux chez nous.