HTML5 für Desktop Anwendungen



  • Es würde mich mal interessieren, wie ihr das mit der Entwicklung von Desktop GUIs mit HTML5 seht. Die Javascript-Bibliotheken für sämtliche GUI-Features nehmen kein Ende und alles Erdenkliche von normalen GUI-Elementen über 2D Diagramme bis zu 3D Spielen sind vorhanden und frei verfügbar.

    Aber wie sieht es mit der Performance aus? Eine einfache App für simple Aufgaben läuft sicher sehr flüssig aber was ist mit aufwendigen 3D-Programmen? Glaubt ihr, dass sich die Performance noch signifikant verbessert und HTML5+Javascript an z.B. Qt herankommen könnte?

    Die Flexibilität durch HTML+CSS+Javascript ist enorm und die Entwicklung sehr einfach. Über Node.js kann man Teile sogar in C++ programmieren und die Logik lässt sich gut von der Oberfläche trennen. Hat jemand Erfahrung mit größeren Projekten und wie es dort mit der Übersichtlichkeit aussieht?

    Außerdem würde mich mal ein Vergleich interessieren zwischen Node+Webkit+JS+C++ und QML+JS+C++. Wo liegen die Vor- und Nachteile oder sollte man für Desktop-Anwendungen doch direkt bei Qt+C++ bleiben?



  • Naja, der Atom Editor basiert auf Node.js und ist recht lahm und kommt mit großen Dateien nicht zurecht. Ich weiß aber nicht genau, woran das liegt, vielleicht kann man da noch viel verbessern.

    Ich persönlich mag JavaScript und diese ganze Entwicklung nicht. Das Problem ist jetzt nicht die Sprache an sich... Die hat zwar paar Macken, aber damit kann ich schon leben, wenn ich paar kleinere Scripte schreiben muss, auch wenn mir C++ einfach viel lieber ist.
    Ich bin aber absolut kein Fan von dynamisch typisierten Sprachen für große Projekte. Wenn der Compiler Fehler abfangen kann, dann ist es ein Riesenvorteil. Bei größeren Projekten mit Scriptsprachen funktioniert schon die IDE Unterstützung fast nie zufriedenstellend (kann es ja auch nicht, du schreibst irgendwo eine Funktion foo(param) und gibst dann param. ein, woher soll die IDE wissen, was das sein soll? Die Info kann höchstens später dazu kommen, wenn die Funktion irgendwo aufgerufen wird, oder man braucht zusätzliche type annotations. Aber dann kann man sich die Scriptsprache auch gleich sparen.). Und vor allem Refactoring wird ziemlich übel. Und die ganzen dynamischen Features sind bei kleinen Projekten sehr nett, aber bei großen Projekten führt es dann oft dazu, dass man sehr lange suchen muss, was da eigentlich passiert.
    Was die Performance angeht, glaube ich auch nicht, dass JS wirklich an C++ herankommen wird. Die Sprache ist vom Design her dynamisch, der JIT Compiler kann das nicht alles wegoptimieren. Und ich gehe wieder davon aus, je größer und komplexer ein Programm, desto schwieriger wird es. Wenn du irgendwo eine Funktion hast, die ein Objekt reinbekommt, und es gibt hundert Stellen, wo diese Funktion aufgerufen wird und übergebenen Objekte haben jeweils unterschiedliche Eigenschaften, wird der Compiler da nicht viel machen können. Außerdem hat mans mit C++ einfach besser im Griff und kann genau abschätzen, was im Programm passiert.
    Was mir auch nicht gefällt ist, dass man mit JS quasi alles als Open Source freigibt, Obfuscation hin oder her. Das mag für viele Firmen vielleicht nicht so relevant sein, für uns aber schon. Beim Kunden geht es oft um Details, wenn die Basisfunktionen passen. Und dann denkt man sich, ah die können auch das, cool. Wenn der Konkurrent das das nächste mal auch kann, ist es nicht mehr so cool.
    Meine subjektive Meinung.



  • Danke für die Antwort. Der Atom Editor ist aber ansonsten wirklich ganz cool und nutze ihn um kleine Julia Skripte zu schreiben, da man sich aus den ganzen Pakete eine nette Umgebung schaffen kann. Mit großen Dateien hab ich es noch nicht ausprobiert aber das werde ich mal versuchen.

    Dass Fehler schon zur Compile-Zeit gefunden werden ist sicher auch das größte Argument, was gegen die HTML+CSS+JS-Kombi spricht in diesem Fall.

    Open Source ist in meinem Fall kein Problem, da ich es nur im akademischen und privaten Bereich nutze und alles unter OSS-Lizenzen veröffentlicht wird, wenn es sich lohnt.



  • Performance sehe ich auch die Probleme. Hauptsächlich wegen dem DOM. JavaScript ist recht fix und die Grafikdarstellung von Chrome auch, aber gerade bei einem Texteditor in dem viel Syntaxhighlightung und andere Annotationen dargestellt werden, sind es einfach unglaublich viele Objekte die unnötig komplex sind. Bei Atom haben sie schon versucht mit Hilfe von React auf einen abgespeckten virtuelles DOM zu setzen, aber ich finde es immer noch unnötig langsam.

    Was die Sprache angeht kann ich eigentlich nur empfehlen von purem JavaScript weg zu gehen. Typescript hat mit Visual Studio (normal und Code) einfach unglaublich gute IDE Unterstützung (volles Intellisense + einfaches Refactoring). Microsoft steckt da aktuell sehr viel Zeit und Geld rein und ist, was die aktuelle Entwicklung im Web Frontend angeht, ganz vorne mit dabei (Angular 2 und React).



  • An dem Node.js-Ansatz reizt mich, dass man mit den gleichen Mitteln von der Desktop-Anwendung mit 2D- und 3D-Elementen und mit einer riesigen Anzahl von Bibliotheken, bis hin zur Website alles umsetzen kann. So hat man die Möglichkeiten für wenige Sachen noch besser zu werden. Ich bin auf jeden Fall auf die zukünftige Entwicklung gespannt und hoffe, dass die Performance und die Unterstützung bei der Programmierung noch weiter verbessert wird.



  • JavaScript eignet sich für große Codebasen überhaupt nicht 😕
    Vielleicht wird alles irgendwann besser, aber aktuell würde ich keine großen Codebasen in JS warten wollen.

    Auch Destruktion ist ein riesen Problem.



  • Meistens wird doch JavaScript aus einer anderen typsicheren Sprache generiert, oder?



  • Tobiking2 schrieb:

    Was die Sprache angeht kann ich eigentlich nur empfehlen von purem JavaScript weg zu gehen. Typescript hat mit Visual Studio (normal und Code) einfach unglaublich gute IDE Unterstützung (volles Intellisense + einfaches Refactoring).

    Artchi schrieb:

    Meistens wird doch JavaScript aus einer anderen typsicheren Sprache generiert, oder?

    Was heißt meistens? Von ein paar bestimmten Firmen ab und zu vielleicht. TypeScript an sich gefällt mir auch besser. Allerdings habe ich das noch nie benutzt, weil ich mir denke, dass es doch besser ist, beim Standard zu bleiben. Unsere Mobile und Webabteilung programmiert zumindest tatsächlich normales JavaScript und die paar Webklitschen, die ich kenne, setzen auch kein TypeScript ein.



  • Artchi schrieb:

    Meistens wird doch JavaScript aus einer anderen typsicheren Sprache generiert, oder?

    Es gibt eigentlich nur Coffee Script und Type Script. Beide Sprachen sind im Grunde nicht viel besser als JavaScript was Destruktion und Resourcen Management betrifft. Sie helfen idR durch starke Typisierung und einem besseren Objekt-Model.

    Aber dann gibt es natürlich den Nachteil der Einbindung von externen JavaScript Bibliotheken (funktioniert natürlich, aber macht die Codebasis nicht wirklich kohärenter)

    In der Firma schreiben wir JS direkt - weil die Vorteile von Coffee Script die Nachteile für den extra Übersetzungsschritt nicht aufwiegen bei uns.



  • Ich bin kein Webentwickler. Aber ich habe das immer so verstanden, das JavaScript nicht wirklich programmiert wird. Sondern man nur fertige JS-Libs, z.B. GWT, Primefaces u.a., nimmt und diese von Java, Ruby, C# oder C++ aus benutzt.

    Aber es sitzt doch nicht wirklich jemand da, und programmiert eine Anwendung in JS? 😕 Irgendjemand war so masochistisch und hat die GWT, Primefaces usw. vielleicht in JS implementiert, aber doch nicht der Anwendungsprogrammierer?

    Typescript usw. sind ja dann wieder eine andere Geschichte, an die ich jetzt erstmal nicht gedacht habe. Aber selbst die zeigt doch, das niemand wirklich größere Anwendungen in JS implementiert?

    Sieht für mich eher so aus, als ob JS so eine Art Maschinencode für Webbrowser/-Seiten ist. Und das meiste für JS aus was anderem generiert oder angesteuert (JS-Libs) wird.



  • Artchi schrieb:

    Aber es sitzt doch nicht wirklich jemand da, und programmiert eine Anwendung in JS? 😕

    So schlimm ist es dann doch nicht. 😉

    In Sachen Webentwicklung wird doch fast ausschließlich reines Javascript mit irgendeinem von Tausenden, immer wieder neuen, super innovativen Frameworks genutzt, um 5% andere Syntax zu haben und 10000% produktiver zu werden.

    Ich finde es schon super, dass so viele verschiedene Sachen entwickelt werden und alles Erdenkliche vorhanden ist aber man muss sich erst durch einen Wald von Frameworks kämpfen und das Rad wird in Javascript gefühlt jedes Mal neu erfunden.



  • bitte löschen



  • Artchi schrieb:

    Ich bin kein Webentwickler. Aber ich habe das immer so verstanden, das JavaScript nicht wirklich programmiert wird. Sondern man nur fertige JS-Libs, z.B. GWT, Primefaces u.a., nimmt und diese von Java, Ruby, C# oder C++ aus benutzt.

    Nein, das macht eigentlich Niemand.

    Aber es sitzt doch nicht wirklich jemand da, und programmiert eine Anwendung in JS? 😕 Irgendjemand war so masochistisch und hat die GWT, Primefaces usw. vielleicht in JS implementiert, aber doch nicht der Anwendungsprogrammierer?

    Was schockiert dich daran so? Leute schreiben auch Anwendungen in C oder C++. JavaScript ist für viele Sachen ziemlich ideal - gerade wenn du sehr Eventbasierend bist. Wo es suckt ist Resourcen Verwaltung. Aber Webanwendungen haben hier idR keine großen Anforderungen da eine Webanwendung ja keine 10 Minuten läuft bis sie neu geladen wird. Resourcen Leaks sind also nicht so dramatisch.

    Anders natürlich bei Desktop Anwendungen (weswegen ich hier ja gegen JS argumentiere).

    Sieht für mich eher so aus, als ob JS so eine Art Maschinencode für Webbrowser/-Seiten ist. Und das meiste für JS aus was anderem generiert oder angesteuert (JS-Libs) wird.

    Nein, das ist falsch. Dazu ist JavaScript viel zu high leveling. Es gibt Ansätze und Ideen wie man genau so eine Maschinensprache machen kann, es gibt zb asm.js - was ein minimales JavaScript ist dass sich effizient als Maschinensprache umsetzen lässt, aber so ganz weit ist man da noch nicht.

    JS ist aber eigentlich eine coole Sprache und hat auch viele Innovationen im Webbereich vorangetrieben. Was halt suckt ist das Object Model und die Resourcen Verwaltung. Das sind aber 2 Sachen die im Web vernachlässigbar sind.



  • Shade Of Mine schrieb:

    Es gibt eigentlich nur Coffee Script und Type Script.

    Du hast ClojureScript vergessen. 😉

    (Klar ist das eher obskur, aber ich habe das jetzt schon zwei Mal in freier Wildbahn gesehen und es dürfte für größere Sachen auch sehr sehr nett sein.)

    Artchi: Shade hat ja schon erklärt, dass das nicht stimmt, aber wie genau kommst du denn auf die Idee, dass niemand selbst Javascript schreibt?

    Tobiking2: IIRC verwendet Atom mittlerweile nicht mehr React, sondern hat seine eigene Virtual-DOM-Implementierung.



  • Solche Schrottsprachen wie Javascript finden ihr Publikum bei Entwicklern, die den Wert von vernünftigen Werkzeugen mangels Erfahrung noch nicht erkannt haben. Unitypisierte Sprachen sind objektiv Schwachsinn, aber ja so viel komfortabler beim Herumtippen. Ein Mensch kann die Datentypen angeblich gut genug überblicken. Echte Programmierer brauchen keine Werkzeuge, die Tipp- oder Flüchtigkeitsfehler sofort finden.



  • TyRoXx schrieb:

    Unitypisierte Sprachen sind objektiv Schwachsinn

    Objektiv. Aha. Ahso.
    Alles klar.
    Kthxbye



  • ich finde http://www.awesomium.com/ cool, kann man sich laden und ausprobieren wie gut es laeuft. ansonsten ist auch in QT ein browser lement integriert oder du kannst ein browser fenster selbst in MFC einbinden (vor jahren hab ich hier im forum irgendwo ein snippet dafuer gesehen).

    so traurig das auch ist, aber mittlerweile sollten CPUs schnell genug sein um den groesten dreck den leute coden performant zu verarbeiten. selbst handies haben blinky blinky elemente die animiert sind, mit aufwendigen blurs etc. und laufen ewig auf akku, da mueste man schon was maechtig falsch machen (mit absicht) damit ein PC die UI nicht verarbeiten kann, selbst wenn man sie in brainfuck schreibt.



  • TyRoXx schrieb:

    Unitypisierte Sprachen sind objektiv Schwachsinn

    ääähm.. nein. plädiere für vielfalt.



  • rapso schrieb:

    ich finde http://www.awesomium.com/ cool, kann man sich laden und ausprobieren wie gut es laeuft. ansonsten ist auch in QT ein browser lement integriert oder du kannst ein browser fenster selbst in MFC einbinden (vor jahren hab ich hier im forum irgendwo ein snippet dafuer gesehen).

    Ich seh den Vorteil aber auch nicht. Ich komme mit Qt GUIs viel besser zurecht, als mit HTML und JavaScript und will das überhaupt nicht haben.


Anmelden zum Antworten