Warum haben wir uns für Electron entschieden?

Hintergrund


Wir sind ein kleines Entwicklungsteam und erstellen ein neues Tool für die Arbeit mit dem API Testmace . Tatsächlich handelt es sich hierbei um einen erweiterten Rest-Client mit der Möglichkeit, automatisierte API-Tests mithilfe einer grafischen Oberfläche zu erstellen, die mit nützlichen Funktionen wie einem erweiterten Variablenmechanismus ausgestattet ist, der in allen Eingabefeldern automatisch vervollständigt wird und die gesamte Syntax hervorhebt.

Ich möchte Ihnen erzählen, wie wir als Technologie zum Schreiben unserer Anwendung zu Electron gekommen sind.

Warum Desktop


In den letzten 10 bis 15 Jahren hat das Web ein explosives Wachstum verzeichnet und wächst weiterhin schnell. Ständig gibt es immer mehr neue Tools, um immer funktionalere und komplexere Webanwendungen zu erstellen. Sogar ganze Programmiersprachen werden erstellt, für das Schreiben von Webanwendungen geschärft und fast ohne vorgefertigte Lösungen außerhalb dieses Bereichs. Und in unserem täglichen Leben haben wir Microsoft Office und Thunderbird bereits teilweise durch Google Docs und die Google Mail-Oberfläche ersetzt.

Das Web kann Desktop-Anwendungen jedoch aus folgenden Gründen noch nicht vollständig ersetzen:

  • Mangelnde Reaktionsfähigkeit von Webanwendungen. Irgendwo die Schuld für die Client-Server-Synchronisation und das langsame Internet, irgendwo die Single-Thread-Natur von Javascript und irgendwo nur die Völlerei des Browsers auf Ihrem nicht sehr leistungsfähigen Computer. Es ist erwähnenswert, dass die Lösung der oben genannten Probleme nur eine Frage der Zeit ist. Insbesondere werden Web-Worker bereits von allen modernen Browsern unterstützt, wodurch das Problem des Multithreading teilweise gelöst wird, und Funktionen wie SharedArrayBuffer können den Aufwand für das Kopieren von Speicher zwischen dem Hauptthread und den Workern verringern.
  • Zugriff auf lokale Systemressourcen. Es gibt ganze Klassen von Anwendungen (Dateimanager, Tweaker, Daemons und Dienste), die (zumindest in dieser Entwicklungsphase) nicht als Webanwendungen implementiert werden können.
  • Einschränkungen der Funktionen des Browsers. Beispielsweise wird die Netzwerkinteraktion nur durch Senden einer http-Anfrage und Herstellen einer Verbindung über Web-Sockets eingeschränkt. Dinge auf niedrigerer Ebene (TCP, Upd-Sockets) sind leider nicht verfügbar.
  • Künstliche Einschränkungen von Browsern aus Sicherheitsgründen. CORS, arbeiten mit Cookies, Einschränkungen für gesendete Header.
  • Eine begrenzte Anzahl von Sprachen und Ansätzen. Im Gegensatz zu Webanwendungen, bei denen Javascript die einzige Sprache zum Schreiben von Anwendungen bleibt, können Sie mit Desktopanwendungen jede Programmiersprache bis hin zu Assemblern verwenden und Systemressourcen mithilfe von Multithread-Programmierung und Anweisungen auf niedriger Ebene effektiv nutzen. Es ist erwähnenswert, dass sich die Situation in diesem Bereich verbessert - Transpiler aus einigen Sprachen erscheinen in Javascript. Darüber hinaus können Sie durch die Kompilierung in der Webassembly die Betriebszeit aus anderen Sprachen (C ++, C #, Rost usw.) übertragen, wodurch häufig eine gute Leistungssteigerung erzielt wird.

In Anbetracht der oben aufgeführten Gründe können wir den Schluss ziehen, dass TestMace eine typische Desktop-Anwendung sein sollte:

  • Wir benötigen Zugriff auf das Dateisystem, um mit dem Projekt arbeiten zu können.
  • Die Einschränkungen beim Abrufen ermöglichen keine vollständige Kontrolle über die Konfiguration und Ausführung der Anforderung.
  • In Zukunft benötigen wir möglicherweise Optimierungen auf niedriger Ebene, um die Anwendungsleistung zu verbessern.

Technologieauswahl


Wir haben beschlossen, dass unsere Anwendung Desktop sein wird, haben uns jedoch noch nicht für die Sprache und Technologien entschieden, auf denen wir dies implementieren werden. Für Programmiersprachen gelten folgende Anforderungen:

  1. Es muss eine statisch typisierte Sprache sein.
  2. Die Sprache sollte eine große und ausgereifte Infrastruktur haben - es sollte sowohl bewährte Bibliotheken als auch Unterstützung durch die IDE und andere Tools geben.
  3. Die Sprache sollte den meisten Teammitgliedern vertraut sein.

Der letzte Punkt ist ebenfalls wichtig. Als Startup sind wir an der schnellsten Markteinführung (innerhalb von sechs Monaten) des Produkts interessiert, wobei die internen Ressourcen des Teams maximal genutzt werden. Das Erlernen einer neuen Sprache und Infrastruktur verringert die Vorhersehbarkeit der Planung und ist mit Fehlern bei der Annahme bestimmter Entscheidungen behaftet.

Wie dem auch sei, die Liste der Anforderungen scheint nicht zu starr zu sein, und Sprachen wie C #, TypeScript, Go erfüllen sie. Wir werden die weitere Auswahl der Technologien unter Berücksichtigung der Verfügbarkeit von Implementierungen der für diese Sprachen erforderlichen Komponenten durchführen.

Bei der Auswahl der Lösungen für die Entwicklung einer Benutzeroberfläche sind die Dinge viel interessanter. Die Anforderungen für sie sind wie folgt:

  1. Plattformübergreifend (Windows, Linux, MacOS)
  2. Ein umfangreiches Set an integrierten Komponenten und Komponenten von Drittanbietern
  3. Anpassbarkeit der Komponenten
  4. Auszeichnungssprache für die Schnittstellenbeschreibung
  5. Gute Unterstützung

Überlegen Sie, welche Lösungen für diese Anforderungen geeignet sind.

Qt (Qml)


Qt ist ein leistungsstarkes Toolkit zum Schreiben plattformübergreifender Anwendungen. In den neuesten Versionen dieses Frameworks wurde die Qt Quick-Komponente zum Schreiben von Anwendungen mit der deklarativen QML-Markup-Beschreibungssprache angezeigt. Qt im Allgemeinen und QML im Besonderen sind kampferprobte Lösungen, die in fast allen Bereichen Anwendung finden - von eingebetteten bis hin zu Software-Shells von Betriebssystemen.

Die Hauptprogrammiersprache in Qt ist C ++ (Sie können Javascript in QML verwenden). Für Qt und QML gibt es jedoch Ordner für andere Programmiersprachen (z. B. für C # ). Es wird jedoch offiziell nur die Python-Integration unterstützt. Alles andere sind Implementierungen von Drittanbietern. Ich stimme zu, ich möchte nicht den grundlegendsten Teil der Anwendung der Bibliothek anvertrauen, die von einer kleinen Gruppe von Enthusiasten als Hobby entwickelt wurde.

Es gibt auch ein Brig- Projekt. Dies sind NodeJS-Ordner für QML. Eine Besonderheit dieses Projekts ist eine beeindruckende Demo . Wie es jedoch häufig bei Open-Source-Projekten der Fall ist, schenken die Autoren dem Projekt keine gebührende Aufmerksamkeit und verlieren daher auch den Überblick.

GTK


Eine Bibliothek zum Erstellen einer Benutzeroberfläche, die als Teil eines GIMP-Projekts begann und anschließend in ein separates Projekt aufgeteilt wurde. Es gibt ein Glade- Tool für die schnelle Entwicklung von Benutzeroberflächen. Die Hauptsprache für die Entwicklung von GTK ist C, aber es gibt Ordner für viele gängige Programmiersprachen . Darüber hinaus wurde mit C # -Bindemitteln MonoDevelop erstellt - eine der leistungsstärksten IDEs für die Entwicklung unter C #. Bei näherer Betrachtung stellen wir jedoch fest, dass sich das GTK # -Projekt in einem halb aufgegebenen Zustand befindet - das letzte Commit war im Februar 2018, das nächste im Januar 2017 und dann 2016. Durch Commit pro Jahr. Es ist nicht dick, wenn man bedenkt, dass sich das Haupt-GTK-Repository aktiv entwickelt. Und das Glück war so nah ...

Electron


In letzter Zeit ist mit diesem Framework viel Lärm verbunden. Jemand lobt ihn für die Möglichkeit, die Errungenschaften von Webanwendungen auf den Desktop zu übertragen, jemand hasst übermäßige Völlerei. Beides kann verstanden werden. Electron under the Hood verwendet node.js und die Chromium-Rendering-Bibliothek. Tatsächlich wird eine reguläre Webanwendung erstellt und in eine ausführbare Datei eingeschlossen. Darüber hinaus enthält jede Anwendung eine eigene Version von Node.js und Chrome.

Tatsächlich gibt es nur ein Minus, aber es ist ziemlich schwerwiegend - dies ist ein großer (im Vergleich zu anderen Technologien) Speicherverbrauch: Ein leeres Projekt benötigt 100 bis 200 Megabyte Speicher. Für einige ist dies der Grund, die Verwendung solcher Anwendungen (Hallo, Skype) abzulehnen. Analysieren wir jedoch die Marktsituation. Derzeit sind viele beliebte Anwendungen in Electron geschrieben (Slack, Skype, Discord, VSCode, Atom, Postman, Insomnia usw.). Viele von ihnen sind Standards auf ihrem Gebiet oder erobern schnell die Herzen der Benutzer (wie der gleiche VSCode und Insomnia). Menschen verwenden einfach Werkzeuge, die ihre täglichen Aufgaben trotz einiger Nebenwirkungen gut lösen. Auf der anderen Seite werden Computer immer leistungsfähiger (zumindest hat das RAM-Wachstum nicht aufgehört ), und Sie hören immer weniger Rückmeldungen von unzufriedenen Kunden, dass "Ihr Chrom meinen gesamten Speicher verschlungen hat". Zusammenfassend glauben wir, dass ein erhöhter RAM-Verbrauch keine große Rolle spielen wird, wenn das Produkt auf seinem Gebiet wirklich gut ist.

Die Vorteile dieser Technologie liegen auf der Hand:

  1. Die Fähigkeit, die Best Practices aus dem Web zu verwenden.
  2. Es ist einfacher, Spezialisten auf diesem Gebiet zu finden.
  3. Der erfüllte Workflow „Designer“ - „Layout-Designer“ - „Programmierer“ bietet in jeder Phase zahlreiche praktische Tools.

Ein weiterer Vorteil ist die Tatsache, dass das Team über umfangreiche Erfahrung in der Erstellung von Front-End-Anwendungen verfügt.

Infolgedessen haben wir uns für Electron als Hauptwerkzeug für die Entwicklung unseres Projekts entschieden. Automatisch haben wir TypeScript als Sprache für die Entwicklung der Anwendung ausgewählt.

Fazit


Eine der Hauptaufgaben eines Startups ist die schnelle Markteinführung eines Produkts. Cool, wenn du es mit minimalen Kosten schaffst. Der Zweck dieser Analyse war es, ein Werkzeug zu finden, mit dem wir diese Probleme lösen können. Unserer Meinung nach passt Electron perfekt zu uns. Drei Monate nach Beginn der Entwicklung ist es immer noch außer Konkurrenz und es scheint, dass bei uns alles ernst ist.

Source: https://habr.com/ru/post/de439946/


All Articles