Im Vergleich zu "normalen" Toolkits ist das immer noch ätzend, funktionsarm und auch langsam (schnellere JS-VMs helfen da wohl schon etwas, aber man muss auch die HTTP-Requests etc mit einrechnen). Letztendlich ist HTML eben ein Dokumentenformat wie PDF und es zu einem GUI-Toolkit umzubauen engt einen hier und dort ein.sma hat geschrieben:Warum aber hältst du "so Sachen" für sinnlos? Anspruchsvolle UIs in JavaScript zu schreiben, ist doch big-PIA, da finde ich jeden Ansatz, der hier verspricht, Abhilfe zu schaffen, interessant.
Fragen - Framework, Interaktive Website, Steuerung
-
Leonidas
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
PDF-Dateien können auch Formulare und JavaScript (ja sogar Flash) enthalten, aber das wolltest du jetzt nicht hören, denke ich mal. Ja, HTML + JavaScript wird zu einem UI-Toolkit umgebaut. Aber das ist eben der Lauf der Zeit und wenn es schon passiert, dann bitte so, dass ich als Entwickler damit möglichst wenig Probleme habe. Der Browser wird auf die eine oder andere Weise immer mehr Desktop-Anwendungen ablösen und so selbst zum Desktop - dem Webtop - werden.
Abgesehen davon: Wenn Cappuccino es wirklich schafft, NextStep aka Cocoa in's Web zu übertragen - dann haben wir damit nicht nur ein UI-Toolkit sondern ein Anwendungsrahmenwerk, welches seines gleichen sucht und IMHO einfachen UI-Toolkits wie wx, tk oder auch Swing und SWT überlegen ist. Qt ist da dann eher vergleichbar aufgestellt - aber eben nicht für's Web.
Stefan
Abgesehen davon: Wenn Cappuccino es wirklich schafft, NextStep aka Cocoa in's Web zu übertragen - dann haben wir damit nicht nur ein UI-Toolkit sondern ein Anwendungsrahmenwerk, welches seines gleichen sucht und IMHO einfachen UI-Toolkits wie wx, tk oder auch Swing und SWT überlegen ist. Qt ist da dann eher vergleichbar aufgestellt - aber eben nicht für's Web.
Stefan
-
Leonidas
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Das ist mir bekannt. Aber Formulare gehen so wie die HTML-Formulare noch unter "Dokument" und JS + Flash sieht man so gut wie gar nicht. Ich weiß nicht ob außerdem Reader noch irgend ein anderer Viewer das unterstützt. Ich halte es auch für keine gute Idee.sma hat geschrieben:PDF-Dateien können auch Formulare und JavaScript (ja sogar Flash) enthalten, aber das wolltest du jetzt nicht hören, denke ich mal.
Momantan sind aber nur zwei Teile portiert: Foundation und AppKit. Und vor allem Hardwarezugriff wird es nie haben, was es auf ewig von Browsern abhängig macht. Wenn man dann sieht wie langsam und verbuggt einige sind, dann hat man da gleich keine Lust mehr, wenn dann den meisten die eigene Applikation um die Ohren fliegt.sma hat geschrieben:Abgesehen davon: Wenn Cappuccino es wirklich schafft, NextStep aka Cocoa in's Web zu übertragen - dann haben wir damit nicht nur ein UI-Toolkit sondern ein Anwendungsrahmenwerk, welches seines gleichen sucht und IMHO einfachen UI-Toolkits wie wx, tk oder auch Swing und SWT überlegen ist. Qt ist da dann eher vergleichbar aufgestellt - aber eben nicht für's Web.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
-
Leonidas
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Ich habe hier einen kleinen Vergleich zwischen Cappuccino und jQuery, da hat jemand das Demo portiert.
Es ist auch nicht alles so unproblematisch, so ist bei mir die Cappuccino-Version wesenlich langsamer, während man bei der jQuery-Version nicht alle Listen entfernen kann und sie etwas weniger als Cappuccino macht (via).
Edit: SproutCore-Version hinzugefügt
Edit: SproutCore-Version hinzugefügt
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Die SproutCore-Demo ist IMHO am Überzeugendsten, weil sie Databinding zeigt. Es geht ja nicht bei den Rahmenwerken darum, den Effekt nachzustellen, sondern wie und mit welchem Aufwand diese "Anwendung" gebaut werden konnte. Das lässt sich an den Demos ohne Quelltext nicht nachvollziehen.
Cappuccino sagt, nutze Objective-J, denn dann hast du zusammen mit unserem Cocoa-kompatiben Rahmenwerk ein mächtiges Werkzeug an der Hand, die Anwendung zu haben - insbesondere wenn du Cocoa schon kennst. Gerüchtehalber soll man sogar den Apple InterfaceBuilder nutzen können, um die Oberflächen zu bauen.
SproutCore sagt, wir benutzen die selben Konzepte wie Cocoa, aber portiert auf JavaScript und mit MVC und Databinding (moderne) Konzepte für die GUI-Entwicklung.
JQuery sagt: Wir sind klein und fein und es kostet nicht viel, die Bibliothek auf Webseiten einzubinden. Bei der Entwicklung von Anwendungen hilft das aber IMHO nicht viel.
Stefan
Cappuccino sagt, nutze Objective-J, denn dann hast du zusammen mit unserem Cocoa-kompatiben Rahmenwerk ein mächtiges Werkzeug an der Hand, die Anwendung zu haben - insbesondere wenn du Cocoa schon kennst. Gerüchtehalber soll man sogar den Apple InterfaceBuilder nutzen können, um die Oberflächen zu bauen.
SproutCore sagt, wir benutzen die selben Konzepte wie Cocoa, aber portiert auf JavaScript und mit MVC und Databinding (moderne) Konzepte für die GUI-Entwicklung.
JQuery sagt: Wir sind klein und fein und es kostet nicht viel, die Bibliothek auf Webseiten einzubinden. Bei der Entwicklung von Anwendungen hilft das aber IMHO nicht viel.
Stefan
http://qooxdoo.org/ ist auch ein interessanter ansatz. Aber eher kompliziert und für die neueste Version gibt es noch nicht wirklich viel Dokumentation. Allerdings ist es recht schnell 
[Zumindest in der kompilierter version]
[Zumindest in der kompilierter version]Finde ich nicht. Qooxdoo benutzt ganz klassisch Listener und ahmt damit das schon vor 10 Jahre bei Swing alte Listener-Konzept nach. MVC gibt es seit 30 Jahren. Die Idee des Databinding mindestens auch schon 15 Jahre und dennoch trauen sich UI-Tookits auf den Markt, die das beides nicht unterstützen...apollo13 hat geschrieben:http://qooxdoo.org/ ist auch ein interessanter ansatz
Zudem läuft's nicht unter FF3.1 :)
Stefan