Kolumne: Olis bunte Welt der IT

Die Zukunft ist für alle da, oder: Gegen HTML und JavaScript ist kein Kraut gewachsen
Kommentare

Blühende Wiesen gibt es in der Softwarewelt immer nur sinnbildlich, versprochen werden sie jedoch oft und gern. Zur Erstellung von UI gibt es mit HTML, CSS und JavaScript die eine Technologiekombination, die ihresgleichen sucht. Verpassen Sie nicht diesen wichtigen Schritt Richtung Zukunft!

Die Neunzigerjahre sind, wie ich soeben mit Schrecken feststelle, mittlerweile mehrere Jahrzehnte her. Der Schrecken hat mehrere Gründe. Mehrere Jahrzehnte stellen offensichtlich eine richtig lange Zeit dar, während die Neunzigerjahre zumindest in meinem Kopf gerade eben erst zu Ende gegangen sind. Den Anfang eines neuen Millenniums haben wir gefeiert, vielleicht sogar zweimal, wenn wir uns erst während des Jahrs 2000 von der Plausibilität des korrekten Jahrtausendanfangs in 2001 überzeugen ließen. Das ist schrecklich, dass das schon so lange her sein soll, aber noch furchtbarer finde ich, dass trotz der unglaublich schnellen Entwicklung in Bereichen der IT so vieles noch Bestand hat, dass es in den Neunzigern auch schon gab.

Neulich hatte ich Gelegenheit, eine Diskussion über modernes UI zu führen, mit einem Herrn aus dem letzten Millennium. Ich trug unter anderem vor, dass JavaScript sich in den letzten Jahren immer mehr als Programmiersprache auch für UI-Anwendungen verbreitet hat. Auch diese Aussage führte zu Schrecken, seinem in diesem Fall: „Ich hab‘ noch nie viel damit gemacht, aber ich dachte, JavaScript sei so eine Hintergrundsprache für Webseiten, die die meisten Leute aus Sicherheitsgründen im Browser ausschalten.“ Das klang nach Stand 1998 oder so, was sollte ich dazu sagen. Was macht der Herr beruflich? Software schreiben, mit VB.NET und Windows Forms, für eine Gruppe anscheinend glücklicher Kunden, die auf diesem Weg ihre Hardwareinvestitionen maximal ausreizen können.

Stabilität ist gut

Verstehen Sie meinen Sarkasmus nicht falsch. Grundsätzlich ist es sicher eine gute Idee, Software so zu entwickeln, dass sie lange nutzbar bleibt. Wer keinen neuen Computer braucht, sollte vermutlich auch keinen kaufen, und in jedem Fall sollte er nicht gezwungen sein, einen zu kaufen.

In der Realität ist es meist so, dass ein Dienstleister, der Software erstellt, sich nicht allzu genau auf die Bedürfnisse eines einzelnen Kunden einstellen kann. Schließlich hat man ja, falls irgendwie möglich, noch ein paar andere Kunden, und die haben alle unterschiedliche Hardware. Aus Sicht des Kunden ist eine extrem langfristige Zusammenarbeit auch nicht unbedingt erstrebenswert oder bedarf zumindest etwas Überlegung. So eine Windows-Forms-Anwendung kann heute schon bald fünfzehn Jahre alt sein – so stabil die Anwendung sein mag, wenn dem Vertrauensverhältnis zwischen Kunden und Dienstleister irgendetwas zustößt (oder auch einem der beiden direkt, natürlich im geschäftlichen Sinne), dann ist der Aufwand für eine Umstellung immens.

Flexibilität ist besser

Mit der Zeit gehen ist gut für Softwarefirmen, weil sie von modernen Techniken profitieren können, und – angenommen, dass diese das Erstellen der Software vereinfachen – junge Entwickler einstellen können, die relativ günstig arbeiten, idealistisch und motiviert sind und sich mit besagten Techniken auskennen, wodurch diese Unternehmen insgesamt sich durch aktuelle Fachkenntnisse sowie agile Programmierer und Entwicklungsmethoden einen Marktvorteil verschaffen können. Mit der Zeit gehen ist gut für Softwareabnehmer, da die Leistungsfähigkeit modern erstellter Software höher ist und weder Systeme noch Anwender Gelegenheit haben, gegenüber dem aktuellen Stand der Technik zu weit zurückzufallen. So bleibt man auch als Abnehmer agil und behält die Freiheit, ohne großen Verlust auf potenziell leistungsfähigere Systeme umzusteigen – wenn notwendig oder wie von Anwendern oder Investitionsträgern erwünscht.

Zurück zu den Neunzigern. Auch damals gab es bei der Softwareentwicklung bereits eine Priorität, die in den letzten Jahren zu neuem Ruhm gelangt ist: Plattformunabhängigkeit. Die Sprache und Plattform Java versprach dies von Anfang an – das war 1995 – und auch für die Erstellung von plattformunabhängigem UI gab es dort Lösungen, erst mit AWT und dann mit Swing. Ich selbst habe damals auch mal mit Amulet gearbeitet, das UI-Anwendungen auf Basis von C++ für Unix, Windows und den Mac möglich machte. Natürlich war Java mit seinem Bytecode besonders einfach von einer Maschine auf eine andere zu übertragen, aber seit der ersten Standardisierung der Sprache C war ja schon klar, dass viele Programmierer ihren einmal geschriebenen Code gern auch auf einem anderen als dem originalen System kompilieren wollten.

Das wichtigste Ziel, das man durch Plattformunabhängigkeit in den Neunzigern erreichen wollte, war die Sicherung von Investitionen. Mit anderen Worten, der Code, der einmal geschrieben worden war, sollte auch auf Systemen der Zukunft kompilierbar sein, sodass man ihn nicht neu schreiben musste. Mit Java kam aber ein anderer Vorteil in den Vordergrund, nämlich die Möglichkeit, den Code zur gleichen Zeit auf unterschiedlichen Systemen entwickeln und produktiv einsetzen zu können. Gerade in den Anfangszeiten von Java funktionierte das nicht besonders gut, vor allem, weil Java so gruselig langsam war – erinnern Sie sich an die Sun JavaStation? Längerfristig hat sich das Konzept aber als durchaus tragfähig gezeigt. Unter Windows war immer alles schwieriger, aber etwa auf dem Mac wurden viele Anwendungen sehr erfolgreich in Java implementiert und derartig gut ins System integriert, dass für den Anwender die Laufzeitumgebung völlig unsichtbar war.

Schnell und überall: Datenzugriff mit Entity Framework Core 2.0

Dr. Holger Schwichtenberg (www.IT-Visions.de/5Minds IT-Solutions)

C# 7.0 – Neues im Detail

Christian Nagel (CN innovation)

An dieser Stelle möchte ich nun die Brücke zu modernem UI schlagen. Nein, damit meine ich nicht Windows Forms und auch nicht WPF oder UWP oder irgendwas anderes, das aus einem bestimmten Softwarehaus stammt. Ich rede von der Kombination von HTML, CSS und JavaScript, der produktivsten Umgebung, in der ich selbst bisher Software entwickelt habe (mit oder ohne UI). Sie glauben mir das vielleicht nicht, aber ich kann tatsächlich das Stirnrunzeln auf Ihren Gesichtern sehen, liebe skeptische 50 Prozent (?) der Leserschaft.

HTML für die Zukunft

Ein paar Jahre ist es her (diesmal nur wenige, vielleicht fünf oder so), dass ich einen Workshop bei der BASTA! durchführte, in dem HTML und Co. als Plattform für Anwendungen mit grafischer Oberfläche zur Sprache kamen. Ein Teilnehmer fragte mich damals, etwas provokativ, ob ich es denn für möglich hielte, dass eine Anwendung wie Photoshop in JavaScript implementiert werden könnte. Ich weiß nicht, ob es bewusst gewählt war, aber natürlich wirft das Beispiel Photoshop einige Probleme auf: Große Datenmengen müssen effizient verarbeitet werden, etwa bei der Berechnung von Filtern, der Umgang mit großen Zahlen von lokalen Dateien ist gefragt, auch die direkte Kommunikation mit einer angeschlossenen Kamera. Außerdem muss natürlich eine ausreichend schnelle Darstellung auf dem Bildschirm her, gepaart mit reichlich Benutzerinteraktion. Schwierig zu beantworten, die Frage, oder?

Nachdem ich einen Moment nachgedacht hatte, sagte ich damals „Ja“, und dazu stehe ich auch heute noch. Mittlerweile gibt es viele komplexe Anwendungen, die in JavaScript geschrieben sind, zum Beispiel Office 365. Mir ist keine Implementation von Photoshop bekannt, aber bestimmt kommt die noch (oder ich finde sie zufällig in Google). Damals wie heute muss man feststellen, dass die grundlegende Architektur der UI-Plattform HTML/CSS/JavaScript nicht anders ist als die von anderen solchen Plattformen. Nehmen Sie XAML-basierte Anwendungen. Da gibt es XAML als Beschreibungssprache, dem entspricht leicht nachvollziehbar HTML. In vielen UI-Plattformen der Vergangenheit gab es gar keine Beschreibungssprache, wie etwa in Windows Forms – da musste einfach die Programmiersprache selbst zur Erzeugung der UI-Elemente herhalten. Zum Styling der Elemente (und zur Kapselung der Stile) dienen in XAML-Umgebungen die „Ressourcen“, und in der HTML-Welt gibt es dafür CSS. Letzteres gewinnt für den Zweck ganz klar, meiner Meinung nach, denn so einfach waren Eingriffe in die Darstellung einzelner Elemente noch nie. Erinnern Sie sich an die Komponenten in Delphi? Da gab es in Delphi selbst einen Button, auf dem ein Text stand, und von diversen Komponentenwebseiten konnte sich der geneigte Programmierer zahllose andere Buttons namens BoldTextButton oder ColorTextButton herunterladen. Klar, in XAML sind Buttons mit spezifischem Textformat etwas einfacher als in Delphi, aber häufig ist es auch dort erforderlich, unangenehm große Teile irgendwelcher kryptischer und schwer auffindbarer Templates zu kopieren und zu modifizieren, um kleine Änderungen an den Interna durchzuführen.

Abgesehen von der Beschreibungssprache und den Stilen gibt es natürlich immer auch eine Programmiersprache oder zumindest eine Ausführungs-Engine für die Sprache, die mit der UI-Plattform Hand in Hand geht. Das ist notwendig, um Event- und Datenbindungsmodelle zu unterstützen, Erweiterbarkeit zu ermöglichen und letztlich einfach die Bindung des UI an die Logik der Anwendung in die Wege zu leiten. Für XAML-Anwendungen ist die Sprachplattform eine Variante von CLR oder DLR mit C#, VB.NET und ähnlichen Sprachen. JavaScript spricht für sich selbst, aber auch hier gibt es Alternativen wie TypeScript, CoffeeScript und andere.

Also: Konzeptionell ist kein Unterschied zwischen einer Anwendung, die auf XAML-Basis läuft, und einer, die HTML/CSS/JS verwendet, zu erkennen. Warum also nicht Photoshop? Sicher, es kann sein, dass eine der beiden Plattformen unter bestimmten Umständen schneller oder langsamer arbeitet. Aber nun hat sich z. B. WPF auch noch nie mit Ruhm bekleckert für performante grafische Darstellung – ich höre häufig, dass Programmierer mit Hinweis auf bessere GDI-Performance auf Windows Forms ausweichen –, und auf der anderen Seite des Vergleichs gibt es WebGL, mit dessen Hilfe die Darstellung komplexer Grafik in HTML beachtlich leistungsfähig ist. Letztlich gilt: Sollte irgendwo die Performance von JavaScript oder HTML noch nicht ausreichend sein, kann das nur eine Frage der Zeit sein.

Alle machen mit

Diese Überlegung bringt mich zu einem Punkt, den ich persönlich für sehr wichtig bei der Einschätzung des Stellenwerts von HTML/CSS/JS als Plattform halte: Zum ersten Mal ist die Unterstützung aller wichtiger Gruppen vorhanden, gemeinsam eine Plattform zu entwickeln und voranzutreiben. Dabei sind die „Gruppen“ gleichermaßen kommerzielle Unternehmen, etwa Betriebssystemhersteller, aber auch Interessensgruppen aus dem Open-Source-Umfeld und Standardisierungsgremien. Das hat es bisher in der IT noch nicht gegeben, und deshalb messe ich dieser Entwicklung besondere Bedeutung bei.

Ich habe an dieser Stelle einmal meinen bisherigen Text durchgelesen und ich denke, Sie könnten durchaus argumentieren, dass ich kaum etwas wirklich Revolutionäres gesagt habe. Das sehe ich auch so – die beschriebenen Punkte und Argumente für HTML/CSS/JS sind derart gängig, einleuchtend, gar offensichtlich, dass ein gegensätzlicher Standpunkt kaum sinnvoll erscheint. In der Realität sehe ich allerdings oft, dass Entwickler enorme Hemmungen haben, sich der Idee vollständiger Anwendungen auf JavaScript-Basis wirklich zu öffnen.

Mehr Power dem Entwickler

Natürlich hängt jeder an dem Know-how, dass er oder sie sich über Jahre erarbeitet hat, das ist verständlich. Investitionen wurden bei der Erzeugung aktueller Anwendungsversionen betrieben, die möchte man ungern hinter sich lassen. Aber eine wichtige Entwicklung ist, dass Plattformunabhängigkeit heute nicht mehr der endlosen Wiederverwendbarkeit desselben Stücks Code dient, sondern vielmehr der gleichzeitigen Unterstützung einer breiten Auswahl von Zielsystemen. Mit anderen Worten: Wenn Sie auf HTML/CSS/JS setzen, können Sie Ihre Software an wesentlich mehr Kunden verkaufen. Da gibt es die mittlerweile durchaus zahlreichen Mac-Anwender oder die öffentlichen Dienste, die auf Linux setzen. Da gibt es, natürlich, die Anwender, die nur noch mit Tablets oder Handys arbeiten. Da gibt es, ganz wichtig, das System von morgen, das wir heute noch gar nicht kennen. Diesen Markt eröffnen Sie sich mit HTML/CSS/JS aus kommerzieller Sicht.

Als Entwickler gibt es viele weitere Gründe. Zunächst sind da die Entwicklungswerkzeuge und Libraries: leistungsfähig, flexibel und vielfältig sind sie. Sie fanden Datenbindung in WPF toll? Ich auch – 2006. 2017 gibt es aber Datenbindung à la JavaScript (bzw. unterschiedlicher Frameworks auf der Plattform), und die ist um so vieles mächtiger, dass ich mit den Details den Umfang dieser Kolumne sprengen würde. In ähnlicher Weise beantworten sich die Fragen nach jedem anderen Framework, nach jeder Hilfsbibliothek, die Sie bisher verwendet haben könnten – JavaScript kann das auch, sehr wahrscheinlich besser und mit weniger Code. Ich bin sicher, ich übertreibe objektiv betrachtet hier ein bisschen, um meinen Punkt deutlich zu machen. Das riskiere ich aber gern, denn der Unterschied ist wirklich so groß. Bei der Neuimplementation mancher Applikationsteile, die ich in der Vergangenheit bereits in WPF oder Windows Forms umgesetzt hatte, ist meine JavaScript-Implementation gewöhnlich wesentlich kürzer und einfacher ausgefallen.

Fazit

Meine unangenehmste Feststellung: Die meisten Argumente, die ich höre, warum es denn 2017 auch für neue Anwendungen immer noch Windows Forms oder WPF sein muss, lassen sich leider direkt auf Unwissen zurückführen. Anscheinend polarisiert die Plattform JavaScript, und auch HTML tut das zu einem gewissen Teil. Da gibt es viele Vorurteile aus dem vorherigen Millennium und oft wenig Bemühungen, sich kundig zu machen. Vielleicht haben Sie einen wirklich guten Grund, warum JavaScript für Sie nicht infrage kommt – schreiben Sie mir mal und erklären Sie! Wenn Sie allerdings solch einen Grund gar nicht kennen und trotzdem auf die großen Vorteile verzichten, die ich oben erklärt oder zumindest angedeutet habe, dann empfehle ich dringend, etwas Zeit in Nachforschungen zu investieren.

Windows Developer

Windows DeveloperDieser Artikel ist im Windows Developer erschienen. Windows Developer informiert umfassend und herstellerneutral über neue Trends und Möglichkeiten der Software- und Systementwicklung rund um Microsoft-Technologien.

Natürlich können Sie den Windows Developer über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. In unserem Shop ist der Windows Developer ferner im Abonnement oder als Einzelheft erhältlich.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -