Krautkanal.com

Veröffentlicht am 2015-04-17 22:59:5 in /prog/

/prog/ 6969: Schreibtischanwendungen mit webkit, html5 und js?

cbracco Avatar
cbracco:#6969

Expertenbernd, eines der in letzter Zeit stark ventilierten Dinge ist es ja, Schreibtischanwendungen mit einem abgespeckten Brauser (webkit), html5, css usw. und einem node/io-Hinterende zu machen. Also eigentlich so, wie man heute eine hüfte Webanwendung macht. Bernd stellt sich die Frage, wie toll das ist bzw. was es gegenüber "klassischen" Lösungen, wie z.B. Qt bringt. Denn: Dieses html5-Zeugs, ja Webanwendungen allgemein, ist ja bereits eine Erweiterung der reinen Auszeichnungssprache, um damit Dinge zu tun, die eigentlich nicht vorgesehen waren. Jetzt erweitert man dies nochmals mit diversen Frickeleyen, um noch das Schreibtisch-Fühl aufkommen zu lassen. Das ist ja nicht schlimm, solange es funktioniert, aber Bernd befürchtet, dass dadurch unnötig komplizierter wird. Kann ein Bernd etwas dazu sagen, der schonmal mit webkit UND einem klassichen GUI-Werkzeugkasten gearbeitet hat?

andrewgurylev Avatar
andrewgurylev:#6971

>>6969
Nun, es ist einfacher, Nicht-standard-GUIs und Spezialeffekte einzubauen.
Wie leuchtende Schrift bei Atom.

Um aber gleich beim Thema zu bleiben: Bernd hat vielleicht mitbekommen, dass selbiger Editor Probleme mit großen Dateien hat.

Und dass es für viele Webseiten Äpps gibt, weil der Browser zu viel Strom verbrauchen würde.

Und dass jede Version von Blingbling/Webkit kleine aber relevante Darstellungsfehler/Abweichungen hat. Nicht, dass das bei anderen Browsern nicht auch so wäre, aber Webbrowser sind halt per Definition scheiße.
Immerhin kann man sich bei Firecocks auf die Fehler verlassen, da Mozilla lieber an eingebauten Chat/Hatebook-APIs bastelt und IE/Safari nutzt eh kein vernünftiger Mensch.

Und dass die Browserversion von Anwendungen, die sich als solche bezeichnen dürfen wenn überhaupt Alibiqualität für die Marketingabteilung haben.

Dazu kommt, dass standardkonformes und zugängiges Verhalten auch nicht so leicht umzusetzen ist wie in einem vernünftigem Framework(http://doc.qt.io/qt-5/accessible.html).

Daher: Scheiß drauf.

herkulano Avatar
herkulano:#6972

Es wirkt auf mich (Web-Entwickler) schlanker, Event-Handler und GUIs mit HTML/JS umzusetzen, als z. B. mit Java. Was mir auch häufig auffällt ist, dass man um etwas mit Java auszudrücken deutlich mehr Code braucht, als mit JavaScript. Dafür ist die Java-Lösung dann allerdings auch solider.

woodydotmx Avatar
woodydotmx:#6973

>>6971
Und ich vergaß natürlich die tollen Technologien, auf die Bernd sich freuen darf.

Allem voran natürlich JavaScript, der Programmiersprache mit ohne import-Anweisungen, einem lausigen Typenmodell und dysfunktionalem Scoping.

Und die flächendeckende Umsetzung des Standards, der alles reparieren soll, werden wir vermutlich nicht mehr erleben.

Die einzigen Nachteile von Qt, die ich jetzt entdecken kann, wenn man es beherrscht:

- Compilezeiten von moc + compiler
- das SDK ist ... recht umfangreich, andererseits ist VS ja nun auch mehrere GB groß und da beschwert sich auch keiner der Lüfter

Sonst bekommt man halt seminativen Look und nativen Fühl von Leuten, die ihr Handwerk verstehen.
Es ist so gut, dass C++-Hasser dazu greifen.

hibrahimsafak Avatar
hibrahimsafak:#6974

>>6973

>mit ohne import-Anweisungen

Sind nicht notwendig, bzw. falls gewünscht kann man das selbst machen, z. B. so:

>var MyModel = MyApp.Model.MyModel;

... und schon hat man eine Referenz.

>einem lausigen Typenmodell

Subjektiv. JSON (welches eine Teilmenge der JS-Objektnotation darstellt) ist wohl nicht ohne Grund so populär.

>und dysfunktionalem Scoping

Was genau soll daran dysfunktional sein?

gojeanyn Avatar
gojeanyn:#6975

>>6974
Gesprochen wie so ein richtiger Netzfaggotist, der noch nie mehr als seinen Hipster 2000-Zeilen Blog gekotet hat.

>Sind nicht notwendig, bzw. falls gewünscht kann man das selbst machen, z. B. so:
>var MyModel = MyApp.Model.MyModel;
>... und schon hat man eine Referenz.

Und schon sieht der Quelltext scheiße aus.
Und schon kann eine IDE nicht wirklich etwas damit anfangen.
Und schon kann Bernd bessere Analysewerkzeuge vergessen.
Und schon geschieht das zur Laufzeit.

>Subjektiv. JSON (welches eine Teilmenge der JS-Objektnotation darstellt) ist wohl nicht ohne Grund so populär.
Objektiv. Python und Ruby, dynamische Typisierung, Standalone-Interpreter, JIT-compiler und anderer Scheiß sind auch nicht ohne Grund populär geworden. Die Gründe waren auch nicht gut, genau wie bei JSON.


>Was genau soll daran dysfunktional sein?
Var begrenzt den Scope auf Funktionen. Nicht auf andere Blöcke.

andrewgurylev Avatar
andrewgurylev:#6976

>>6975

>Gesprochen wie so ein richtiger Netzfaggotist, der noch nie mehr als seinen Hipster 2000-Zeilen Blog gekotet hat.

Falsch.

>Und schon sieht der Quelltext scheiße aus.

Falsch, mindestens jedoch subjektiv. Ob ich nun

>import Bla.Blubb

oder

>var Blubb = Bla.Blubb

schreibe macht IMO keinen großen Unterschied, wobei ein import natürlich etwas sauberer ist.

>Und schon kann eine IDE nicht wirklich etwas damit anfangen.

Falsch.

>Und schon kann Bernd bessere Analysewerkzeuge vergessen.

Das kommt auf die Analysewerkzeuge an.

>Und schon geschieht das zur Laufzeit.

Und das hat praktisch relevante Auswirkungen? Wohl kaum.

>Objektiv.

Lerne, was subjektiv/objektiv bedeutet, bevor du so einen Schwachsinn schreibst.

JSON ist populär, weil es sehr viel handlicher und praktischer ist, als z. B. ein XML.

>Var begrenzt den Scope auf Funktionen. Nicht auf andere Blöcke.

Ja, das nennt sich function scope. Und was ist daran dysfunktional? Es ist offensichtlich einfach anders, als das was du gewohnt bist/magst, deswegen aber nicht gleich dysfunktional.

craigelimeliah Avatar
craigelimeliah:#6977

>>6976
>Ob ich nun

>import Bla.Blubb

>oder

>var Blubb = Bla.Blubb

>schreibe macht IMO keinen großen Unterschied

Nette Meinung, leider falsch. Es ist quantifizierbar mehr Noise. Es ist immer schlecht, Sprachmittel als Bibliotheken nachzubauen, denn sowohl für Maintainer als auch für Entwickler von Analysetools ist das nervige Extraarbeit ohne guten Grund.

>Und schon kann eine IDE nicht wirklich etwas damit anfangen.

>Und schon kann Bernd bessere Analysewerkzeuge vergessen.

>Das kommt auf die Analysewerkzeuge an.

Unsinn, es gibt für JavaScript keine hinreichend gute IDE und mit der Semantik ist es auch schlicht nicht möglich.
Selbst WebStorm kann an vielen Stellen nur wild raten.

>Lerne, was subjektiv/objektiv bedeutet, bevor du so einen Schwachsinn schreibst.

Lerne für die Prüfung des Computerführerscheines, bevor du einen benutzt und so einen Schwachsinn über etwas Relatierendes schreibst.

>JSON ist populär, weil es sehr viel handlicher und praktischer ist, als z. B. ein XML.

Und das hältst du für einen guten Grund?

Das eine Hand von Versagern erst XML in den Browser gestopft hat, dann erkannt hat, dass Parsen + Namespace-Analyse + DTD-Validierung/Schemata nicht wirklich echtzeitfähig ist und dann überlegt hat ein Subset von JavaShit zu verwenden, wobei standardisiertes Encoding, Kommentierbarkeit etc. auf der Strecke geblieben sind.
Zumal es nicht wirklich viel handlicher und praktischer ist, wenn man von Stellenweise vereinfachter Serialisierung und der enttäuschenderweise durchschnittlich nur etwa 2x besseren Parsezeit absieht.

>Ja, das nennt sich function scope. Und was ist daran dysfunktional? Es ist offensichtlich einfach anders, als das was du gewohnt bist/magst, deswegen aber nicht gleich dysfunktional.

Es ist ein Schritt von ordentlichem Blockscoping weg zu, hin zu "alles ist global", eine unnötige Fehlerquelle. Sowas bin ich tatsächlich gewohnt. Von C89. Aus einer Zeit, wo man bereits besseres kannte.

Das ist keine Geschmackssache. Das ist ein Fehler im Sprachdesign. Sowas baut auch heutzutage niemand mehr in Programmiersprachen ein. Sogar JavaScript bekommt ja eine Korrektur, nur leider zu spät.

kimcool Avatar
kimcool:#6978

>>6977

>Nette Meinung, leider falsch.

Nein. Du hast immer noch nicht aufgezeigt, warum es einen großen Unterschied machen sollte. Bitte übe nochmal einfaches Textverständnis.

>Unsinn, es gibt für JavaScript keine hinreichend gute IDE

Auch hier offenbart sich wieder dein nicht vorhandenes Textverständnis. Ich schrieb eindeutig:

>Das kommt auf die Analysewerkzeuge an.

In meiner IDE (ich habe das gerade wirklich mal getestet) funktionierte das in einem einfachen Szenario ohne Probleme!

>und mit der Semantik ist es auch schlicht nicht möglich.

Falsch, es ist über die Analyse von ParseTrees möglich.

>Und das hältst du für einen guten Grund?

Ja. Es gibt Zahlen, Strings, Objekte und Arrays. Für die meisten Anwendungsfälle völlig ausreichend.

>Das ist keine Geschmackssache. Das ist ein Fehler im Sprachdesign.

Du hast immer noch nicht gezeigt, was daran dysfunktional sein soll. Nur weil du etwas nicht magst, heißt das nicht, dass es dysfunktional ist.

polarity Avatar
polarity:#6979

>>6978
>Textverständnis
Wie auch Grammatik und Rechtschreibung das Erste, wenn die Argumente ausgehen. Nur Fagottspieler, die einem Helden machen sollten, wenden das an. Siehe auch: Racist Card

>Nein. Du hast immer noch nicht aufgezeigt, warum es einen großen Unterschied machen sollte.
Warum sollte ich es zeigen? Es ist doch völlig offensichtlich.

Falls nicht:
http://stackoverflow.com/questions/950087/include-a-javascript-file-in-another-javascript-file

Alle diese Möglichkeiten passieren zur Laufzeit.
Wenn deine IDE das kann, ist es ein Spezialfall der umständlich reingefrickelt wurde, um Framework x zu unterstützen. Das gibt es ja auch bei PyCharm, mit expliziter Unterstützung für Bibliothek x. Gute Entwickler, leider müssen sie den falschen Markt bedienen. Viel Spaß, falls sich was an x ändert.

Bei einer echten import-Anweisung können auch triviale Werkzeuge zuverlässig eben mal fehlende Dateien finden.

>Ich schrieb eindeutig:
>Das kommt auf die Analysewerkzeuge an.
Nun, das war halt falsch.

>einfachen Szenario
Wen interessiert das.

>Falsch, es ist über die Analyse von ParseTrees möglich.
Nein kann man nicht. Damit kann man nur prüfen, was die Semantik der Sprache hergibt. Und raten, was zur Laufzeit passieren könnte. Und so tun, als hätte man ein vernünftiges Typsystem. Das reicht nicht aus.

>Ja. Es gibt Zahlen, Strings, Objekte und Arrays. Für die meisten Anwendungsfälle völlig ausreichend.
Nein, was es gibt sind Zahlen, Strings, assoziative Arrays, die als Objekte missbraucht werden und Arrays.

>Du hast immer noch nicht gezeigt, was daran dysfunktional sein soll.

Weil auch das ziemlich offensichtlich ist. Nicht nur ist es ziemlich nervig, alle Variablen am Anfang der Funktion zu deklarieren und zu hoffen, dass man nicht zwei Schleifen/Verzeigungen hintereinander hat, in der gleiche Namen Sinn macht. Es nervt auch Leute, die den Garbage Collector implementieren dürfen.


Der springende Punkt ist doch jener: All diese Dinge werden in ferner Zukunft behoben, d.h. Leute die ihr Gehirn benutzen sind zu dem selben Schluss gekommen wie ich.

Es gibt nur keinen Grund, warum sich jetzt mit dem Müll Desktopanwendungen bauen sollte.

Es sei denn, man kann keine vernünftige Alternative.

fluidbrush Avatar
fluidbrush:#6981

>Wie auch Grammatik und Rechtschreibung das Erste, wenn die Argumente ausgehen. Nur Fagottspieler, die einem Helden machen sollten, wenden das an. Siehe auch: Racist Card

Ich schrieb:

>Nein. Du hast immer noch nicht aufgezeigt, warum es einen großen Unterschied machen sollte. Bitte übe nochmal einfaches Textverständnis.

Das hast du - entweder aus Unfähigkeit oder Ignoranz (ich vermute beides) - immer noch nicht getan. Stattdessen zitierst du ein einziges Wort und schreibst irgendeinen irrelevanten Schwachsinn dazu.

>Falls nicht:
>http://stackoverflow.com/questions/950087/include-a-javascript-file-in-another-javascript-file

So langsam wird es peinlich. Ein @import im CSS ist etwas völlig anderes, als ein import in z. B. Java.
Der Faden ist außerdem 5 Jahre alt, jeder node.js-Entwickler (für dich: Das ist JavaScript) arbeitet mit requires.

>Wenn deine IDE das kann, ist es ein Spezialfall der umständlich reingefrickelt wurde

Auch hier merkt man wieder, dass du keinerlei Ahnung hast, wovon du überhaupt redest.

Man benötigt im Grunde nur eine Symboltabelle mit Referenz auf das Objekt:

https://en.wikipedia.org/wiki/Symbol_table

Auf "Argumente" wie

>Weil auch das ziemlich offensichtlich ist.

und

>Leute die ihr Gehirn benutzen sind zu dem selben Schluss gekommen wie ich.

gehe ich gar nicht erst ein, da es Zeitverschwendung wäre.

>Es gibt nur keinen Grund, warum sich jetzt mit dem Müll Desktopanwendungen bauen sollte.

Es wurden IDF bereits Gründe angeführt, aber es freut mich, dass die Welt für dich so schön einfach ist.

p_kosov Avatar
p_kosov:#6982

>>6981

>So langsam wird es peinlich.
Für dich. Hör auf, dir irgendwelche Kontexte aus dem Arsch zu ziehen. Wir reden hier nicht von irgendeinem Nichtstandardgefrickel von Node, sondern von dem Standardgefrickel im Browser, mit dem man dann ekligerweise in Kontakt kommt.

Und das Nodegebastel an sich ist auch kein Grund zum Feiern.
Naja, mit Glück setzt sich ja io.js durch und dann geht es brutal nach dem Standard.

>Ein @import im CSS ist etwas völlig anderes, als ein import in z. B. Java.
Keine Ahnung, woher du jetzt CSS nimmst.

Und den Rest von dem Post kann man ja getrost ignorieren.

fluidbrush Avatar
fluidbrush:#6983

>>6982

>Hör auf, dir irgendwelche Kontexte aus dem Arsch zu ziehen. Wir reden hier nicht von irgendeinem Nichtstandardgefrickel von Node, sondern von dem Standardgefrickel im Browser, mit dem man dann ekligerweise in Kontakt kommt.

Wieder einmal demonstrierst du dein Unwissen: node.js baut auf CommonJS auf, für das es auch Browser-Implementierungen gibt.

>Keine Ahnung, woher du jetzt CSS nimmst.

Aus dem von dir verlinkten Stackoverflow-Faden. Lässt vermuten, dass du ihn nicht mal selbst gelesen hast (oder nicht verstanden; ich würde dir beides zutrauen).

ryandownie Avatar
ryandownie:#6984

>>6983

>node.js baut auf CommonJS

Alias unwichtiger Pseudostandard, auf das man sich nicht auf allen Browsern verlassen kann.
Alles was nicht im ES-Sprachstandard steht UND in allen Browsern implementiert ist -> in die Tonne geht es. Das gilt auch für bei manchen Browsern mitgelieferte Bibliotheken.

>Aus dem von dir verlinkten Stackoverflow-Faden.

Es geht dort um überhaupt eine Möglichkeit, so etwas Gutes wie symbolische Importe kennt der OP nicht oder erwartet er natürlicherweise gar nicht von JavaScript.

soyeljuaco Avatar
soyeljuaco:#6985

>>6984

>Alias unwichtiger Pseudostandard

>Alles was nicht im ES-Sprachstandard steht

ES6 hat ein von CommonJS inspiriertes Modulsystem:

http://www.2ality.com/2014/09/es6-modules-final.html

>"The goal for ECMAScript 6 modules was to create a format that both users of CommonJS and of AMD are happy with"

>UND in allen Browsern implementiert ist

Dann wünsche ich dir viel Spaß mit NetScape-Kompatibilität.

>in die Tonne geht es

Sowas bestimmen zum Glück nicht Personen wie du, sondern solche die Ahnung haben.

>Es geht dort um überhaupt eine Möglichkeit, so etwas Gutes wie symbolische Importe kennt der OP nicht oder erwartet er natürlicherweise gar nicht von JavaScript.

Mal abgesehen davon, dass deine Satzstruktur mehrdeutig ist, habe ich deinen Einwand ja bereits widerlegt (Mit dem Verweis auf die Tatsache, dass man import-Funktionalität leicht nachahmen kann, ohne größere Probleme zu bekommen). Jetzt fängst du wieder an, drum herum zu reden.

Um es kurz zusammenzufassen:

JS bietet durch Modulsysteme oder alternativ selbst definierbare Namespaces (verschachtelte Objekte) sehr wohl eine Möglichkeit, Ordnung und Struktur in eine Anwendung zu bringen. Der function scope ist für Entwickler aus anderen Sprachen gewöhnungsbedürftig, ermöglicht aber - sofern man damit vertraut ist - effektives und sauber gekapseltes Arbeiten. All das sage ich aus Erfahrung, da ich schon JS mit Struktur für größere Anwendungen geschrieben habe.

ritapetrilli87 Avatar
ritapetrilli87:#6986

>>6985
>[bullshit davor]
>JS bietet durch Modulsysteme oder alternativ selbst definierbare Namespaces (verschachtelte Objekte) sehr wohl eine Möglichkeit, Ordnung und Struktur in eine Anwendung zu bringen.
Ich glaube, du bringst hier Namespaces, nur in Quelltextebene, mit Modulen, sowohl auf Quelltextebene und Dateiebene durcheinander.
Irgendwelche globalen Objekte dafür zu missbrauchen ist Mist.

>Der function scope ist für Entwickler aus anderen Sprachen gewöhnungsbedürftig, ermöglicht aber - sofern man damit vertraut ist - effektives und sauber gekapseltes Arbeiten.
Der war wirklich gut. Schau mal:
>Das manuelle Einfügen von Bytecode in die VM um Funktionen zu invokieren ist für Entwickler aus anderen Sprachen gewöhnungsbedürftig, ermöglicht aber - sofern man damit vertraut ist - effektives und sauber gekapseltes Arbeiten.

>All das sage ich aus Erfahrung, da ich schon JS mit Struktur für größere Anwendungen geschrieben habe.
Sicher Bernd. Dann zeig mal dein 1m Zeilenwerk mit der Funktionalität von Photoshop.

shoaib253 Avatar
shoaib253:#6987

>>6985
>ES6 hat ein von CommonJS inspiriertes Modulsystem
Solange dies im Sprachkern ist, ist das ja kein Problem.

mshwery Avatar
mshwery:#6988

>>6969
Expertenbernd hier.

Es kommt drauf an, was Bernd machen will. Bei einfachen Datenbankfrontends spielt es wohl kaum eine Rolle, aber für Ernsthafte Anwendungen(TM) wie die nächste DAW gibt es nichts, was native Anwendungen nicht besser könnten.

Säge, weil Nodeschuchtel und Sprachexpertenschuchtel über mir turingvollständig im Gange bzw. Zugange sind.

joshjoshmatson Avatar
joshjoshmatson:#6989

>>6986

>Ich glaube, du bringst hier Namespaces, nur in Quelltextebene, mit Modulen, sowohl auf Quelltextebene und Dateiebene durcheinander.

Ich bringe gar nichts durcheinander, du hast nur Verständnisprobleme.

Ich schrieb:

>JS bietet durch Modulsysteme oder alternativ selbst definierbare Namespaces (verschachtelte Objekte)

Das Zauberwort hier ist alternativ, hier kannst du dessen Bedeutung nachlesen:

https://de.wiktionary.org/wiki/alternativ

>Irgendwelche globalen Objekte dafür zu missbrauchen ist Mist.

Das ist ein gängiges Pattern der JS-Entwicklung (von der du offensichtlich nichts verstehst).

>Der war wirklich gut. Schau mal:

Und was hast du jetzt durch das dümmliche Verändern meines Satzes bewiesen? Gar nichts.

>Sicher Bernd. Dann zeig mal dein 1m Zeilenwerk mit der Funktionalität von Photoshop.

Deine Beweisforderung ist ungefähr so sinnvoll, wie von Physikbernd zu fordern "Na dann zeig mir mal deinen Nobelpreis!".

adriancogliano Avatar
adriancogliano:#6990

>>6989
Mal wieder hart am rauswinden, was?

>Das Zauberwort hier ist alternativ,
ES5 hat aber kein Modulsystem. Irgendwelche bloatloader.js-Dateien einzubinden sind keine Alternative zu einem richtigen Modulsystem.

>Das ist ein gängiges Pattern der JS-Entwicklung
Das mag ja sein, heißt jedoch nicht, dass das in irgendeiner Form akzeptabel wäre.

>Deine Beweisforderung ist ungefähr so sinnvoll, wie von Physikbernd zu fordern "Na dann zeig mir mal deinen Nobelpreis!".

Wohl eher so sinnvoll, wie einen reinen Webdev zu fragen, ob er zu dem offensichtlich halbwissentlichen und extra falsch verstandenen, schwammigen Schwachsinn, den er den ganzen Tag verzapft ohne auch nur einen Beleg liefern zu können auch nur irgendetwas von Gestalt liefern kann, obwohl man genau weiß, dass diese Leute nichts können, außer Polyfills und Frameworks der Woche einzubinden und zu beten dass es funktioniert.

Andererseits kann man ja sagen, dass es keine nennenswerte browserbasierte Anwendung gibt. Wobei man Google schon fast Respekt zollen könnte, dass die mit Docs soweit gekommen sind.

>Und was hast du jetzt durch das dümmliche Verändern meines Satzes bewiesen? Gar nichts.
Mein Satz hat eine ähnlich schwachsinnige Aussage wie deiner.

Sicher, man kann auch in COBOL größere Anwendungen entwickeln. Oder mit UraltBASIC. Aber freiwillig? Wenn es bessere Alternativen gibt? Und das als angenehm empfinden? Du hast echt einen Riss in der Glocke.

bobwassermann Avatar
bobwassermann:#6991

>>6990

>ES5 hat aber kein Modulsystem. Irgendwelche bloatloader.js-Dateien einzubinden sind keine Alternative zu einem richtigen Modulsystem.

Das sehen sehr viele JS-Entwickler offensichtlich anders, von daher ist deine Meinung irrelevant, sofern du keine guten Argumente dafür liefern kannst.

>Das mag ja sein, heißt jedoch nicht, dass das in irgendeiner Form akzeptabel wäre.

Subjektiv. Ich traue da eher namhaften Entwicklern als einem Bernd, der die Sprache nicht einmal richtig kennt. Ich sag ja auch nicht einfach "Das und das an C ist Kacke", obwohl ich nie wirklich mit C gearbeitet habe.

>Andererseits kann man ja sagen, dass es keine nennenswerte browserbasierte Anwendung gibt. Wobei man Google schon fast Respekt zollen könnte, dass die mit Docs soweit gekommen sind.

Mal abgesehen davon, dass Docs m. E. schon nennenswert ist, gibt es dafür einen ganz einfachen Grund: Die Webtechnologien bieten erst seit relativ kurzer Zeit die Möglichkeiten, anspruchsvolle Anwendungen zu bauen.
Desweiteren muss man bedenken, dass Web-Entwickler im Durchschnitt weniger fähig sind, als z. B. Java-Entwickler. Erst durch die zunehmende Wichtigkeit von JS (wegen interaktiven Seiten) ändert sich das langsam etwas.

>Aber freiwillig? Wenn es bessere Alternativen gibt? Und das als angenehm empfinden? Du hast echt einen Riss in der Glocke.

Wollen wir uns darauf einigen, dass es Geschmacksache ist?

judzhin_miles Avatar
judzhin_miles:#6992

>>6969
Ich habe eine Desktopanwendung in Python gemacht, Basis auf Qt mit integriertem Webkit und die Oberfläche dann in html5.

Wieso?

Die Anwendung sollte sowohl auf Mac, Linux und auch Windows gleich aussehen und den Designstil der Webseite erhalten.

Man kann mit Qt eigene Objekte in Javascript exponieren und so seinen Code von Javascript ausführen lassen.
Man verbindet eigentlich viele Vorteile von Browser und nativer Anwendung...

Was auch mehr oder weniger toll für den Benutzer war: Social Media Krebs Logins konnte man direkt umsetzen in einem Fenster, auch das Bezahlen mit Paypal war so in der eigenen Anwendung möglich. Man hat keinen Contentbruch, dass nicht irgendein vorinstallierte Browser anspringen muss.

Für mich als Programmierer war es deutlich einfacher und schneller als jede andere UI Entwicklung, die ich zuvor gemacht habe.

souuf Avatar
souuf:#6993

>>6991
>Das sehen sehr viele JS-Entwickler offensichtlich anders, von daher ist deine Meinung irrelevant, sofern du keine guten Argumente dafür liefern kannst.
Ist "die meisten werden von ihrer Marktingabteilung gezwungen kewle Webapps zu entwickeln" kein gutes Argument?

>Subjektiv. Ich traue da eher namhaften Entwicklern als einem Bernd, der die Sprache nicht einmal richtig kennt. Ich sag ja auch nicht einfach "Das und das an C ist Kacke", obwohl ich nie wirklich mit C gearbeitet habe.

Ich kenne halt weniger das Ökosystem und eher Teile des Sprachkerns aus "JavaScript: The good parts". Die bad parts waren da schon eklig.
Aber da sich das Ökosystem scheinbar alle 6 Monate komplett ersetzt... sorry, ich bin lernfreudig, aber so sehr dann doch nicht.

>Wollen wir uns darauf einigen, dass es Geschmacksache ist?

OK, bis auf den Teil mit dem function scope.

>>6992
>Design der Webseite übernehmen
>Social Media
>PayPal
OK, das klingt alles echt eklig, aber da hast wohl das Beste draus gemacht.

>Man kann mit Qt eigene Objekte in Javascript exponieren und so seinen Code von Javascript ausführen lassen.

Geht das eigentlich immer noch, jetzt, wo Qt für das eigene Skripting einen eigenen JS-Motor gebaut haben und für den Webkram aber trotzdem noch Webkit mit verschiffen?

posterjob Avatar
posterjob:#6995

>>6993
Laut Doku geht das noch.

http://doc.qt.io/qt-5.4/qwebframe.html#addToJavaScriptWindowObject

polarity Avatar
polarity:#6996

Danke Expertenbernds! Vielleicht etwas zum Hintergrund: Bernd kombt aus dem Embedded-/Mikrocontroller-Umfeld. Gelegentlich muss eine Art Thin-Client zur Parametrisierung/Prozessvisualisierung erstellt werden. Das ist üblicherweise ein kleiner x86 oder auch oft ein ARM, mit Touchscreen, fest eingebaut im zu steuernden Gerät (Managementschuchteln nennen es HMI, human machine interface). Darauf läuft ein minimales Linux, Anbindung an das Gerät oft per CAN. Eine Prozesslogik oder Regelung wird (wenn überhaupt benötig) von einem daemon erledigt. Das GUI selbst muss also in 99% der Fälle nur einen Status anzeigen und Dinge parametrisieren. Es gibt keinen Fensterverwalter, oft auch nichtmal einen X-Server. Die Anwendung läuft immer im Vollbild. Bislang hat Bernd dies in klassischem Qt (noch 4.7) bzw. auch einmal mit den Pythonbindings dazu gemacht, eigentlich ganz ok! Interessant wäre, ob man für etwas kompliziertere Widgets (bswp. mit Multitouch!!11 zoombare/verschiebbare Temperaturkurven) mit dem Webzeugs schneller ist. Auch wollen viele Kunden ihren Dscheiß auch per iPad bedienen können, da liegt es natürlich nahe, die ja dann sowieso schon vorhandene Oberfläche als Webapp anzubieten.
>>6988
> aber für Ernsthafte Anwendungen(TM) wie die nächste DAW gibt es nichts, was native Anwendungen nicht besser könnten.
Spaßfakt: Das GUI von bitwig ist in Java geschrieben :3

malgordon Avatar
malgordon:#7004

>>6996
Da die Qt-Entwickler in letzter Zeit verdächtig den Mobilmarkt und andere Touchoberflächen wie Auto im Fokus haben, würde ich das jetzt nicht ausschließen.
Aber um sicher zu gehen, sollte man diese Frage vielleicht direkt an die Qt-Entwickler richten.

>Spaßfakt: Das GUI von bitwig ist in Java geschrieben :3
Bernds Punkt? Expertenbernd hat mit DAWs gar nicht so das tolle Beispiel gewählt. GUIs von DAWs sind oft so oder so echt scheiße, weil die Hersteller meinen, ihren eigenen Müll entwickeln zu müssen.
Kleine, nicht vergrößerbare Schrift, miese Kontraste, keine Skalierbarkeit bzgl. der Auflösung usw. uvm., aber Hauptsache, der Effekthardware nachempfunden. Mit physikgetreuer Kabelsimulation.

Ich denke, Expertenbernd meinte auch eher GUI-Bibliotheken, die nicht auf Webtechnologie aufbauen.
Sonst hat man u.U. eventuelle Umstände, die in "Richtigen" GUIs eingelöstes Problem sind.
Wie scheinbar das Validieren von Doppelklicks.

cmzhang Avatar
cmzhang:#7005

>>7004
> GUIs von DAWs sind oft so oder so echt scheiße, weil die Hersteller meinen, ihren eigenen Müll entwickeln zu müssen.
Kleine, nicht vergrößerbare Schrift, miese Kontraste, keine Skalierbarkeit bzgl. der Auflösung usw. uvm., aber Hauptsache, der Effekthardware nachempfunden. Mit physikgetreuer Kabelsimulation.

Leider dies! Aber es kling ja soviel wärmer!!!111

Neuste Fäden in diesem Brett: