Dabei möchte ich in der Serie einer gewissen Logik folgen (zumindest versuche ich es). Im ersten Teil werden wir auch den Bereich der Webanwendungen nicht sofort verlassen, denn wir werden uns anschauen, wie wir diese Anwendung mit HTML, CSS und JavaScript umsetzen können.
Doch warum nutzen wir JavaScript, geschweige denn, ob es überhaupt möglich ist? Obwohl JavaScript ihren Ursprung bei Webseiten findet, bietet sie gerade in den letzten Jahren mit Frameworks wie React, Svelte oder Vue viele Möglichkeiten, komplexe und aufwendige Anwendungen umzusetzen. Doch wie kamen wir überhaupt dazu?
Von Plain JavaScript zu Electron
JavaScript als Programmiersprache besitzt das Monopol im Browser, als de facto die einzige Programmiersprache zu sein, die von Browsern für interaktive Dokumente verwendet zu werden. Sie sollte nur eine kleine Sprache für Scripts sein, anstelle einer Sprache, die große Anwendungen trägt. Die Einfachheit war dabei wichtiger als die Geschwindigkeit. Dies sollte sich aber für JavaScript als ein Problem herausstellen. Damals war Java für größere Anwendungen vorgesehen, was aber nicht als Websprache überlebte. Die Sprache für kleine Scripts wurde jetzt also eine zentrale Komponente. Es brauchte erst eine Weile, bis Browser, mithilfe ihrer Engines Wege gefunden haben, JavaScript performanter zu machen. Googles V8 Engine (Chromium) war damals die Erste, die dieses Ziel zu großen Teilen erfüllen konnte. Wie WebEngines näher funktionieren oder die Entwicklungsgeschichte von JavaScript war, wird in diesem Heise Artikel erklärt. Nun eignete sich JavaScript auch für größere Projekte. Es dauerte auch nicht lange, bis JavaScript den Browser verlassen hat. Mit Node.js, das auf der V8 Engine fußt, gab es nun einen Weg, JavaScript wie ein normales Programm auszuführen.
So kommen wir nun zu Electron. Dies ist der bekannteste Weg, mit Webtechnologien Cross Plattform Anwendungen zu entwickeln, denn es kombiniert Nodejs und den Chromium Browser. Hierbei erhält man den großen Vorteil, dass das Programm wie eine normale Anwendung mit dem File System kommunizieren kann, ohne den Umweg über die Web Apis gehen zu müssen. Jedoch entfällt Electron mit dem nicht zu unterschätzenden Nachteil, dass man in seiner Anwendung einen separaten Browser mitschickt. Im Fall von Chromium war meistens eine sehr ressourcenintensive Anwendung entstanden. Jedoch gibt es eine Alternative zu Electron, die ich in diesem Artikel auch verwenden werden: Tauri. Dieses Rust-basierte Open Source Framework bietet fast die gleichen Funktionalitäten wie Electron, kann aber durch seine eigene WebEngine „Wry“ kleinere und effizientere Anwendungen ermöglichen.
Schreibe einen Kommentar