Flash (und clevere Alternativen)

[Centurion]

Ich hab noch mal zwei Fragen:

Komponenten aus der Flex-SDK benutzen wir kaum, bei uns werden die meisten Komponenten selbst gebaut, einfach weil wir 1) ziemlich viel graphischen Schnickschnack verwenden und 2) die Flex-Komponenten extreme Probleme machen sobald die Anwendung etwas größer oder aus mehreren SWF Dateien zusammengebaut wird.

Kannst Du hier ein bisschen ins Detail gehen? Was für Probleme machen die Komponenten? Was die Grafik angeht: Es ist doch eigentlich vorgesehen, dass man die vorhandenen Komponenten durch Skinning etc. im Aussehen komplett verändern kann. Warum wird das nicht gemacht?

Das stimmt leider. Warum es z.B. vier verschiedene Textboxen gibt, weiß auch kein Mensch. Meist kommt man mit einer einzigen aus und benutzt die immer wieder. Tatsächlich ist es in Flash auch einfach üblich, sich UI-Komponenten selbst zu basteln.

Verwandte Frage zu oben: Warum ist das üblich? Werden die Flex-Komponenten als zu sperrig, zu inperformant oder zu unflexibel in Gestaltung und Verhalten wahrgenommen?

[Centurion]

Und noch eine Bemerkung am Rande: Die Tatsache, dass die meisten Eclipse IDEs schlecht skalieren liegt ziemlich sicher nicht am Eclipse Framework. Das macht Dir nämlich im Prinzip keinerlei Vorgaben, was ein Projekt ist, wie Dein Workspace aussieht oder was alles passiert, wenn Du was änderst, sicherst oder einen Build anstößt.

Bei uns sind sie ja seit einiger Zeit dabei, eine Eclipse-basierte IDE für ABAP zu bauen (Alex' und mein ehemaliger Kommilitone Klaus arbeitet daran). In der gibt es z.B. keine Projekte und keinen lokalen Workspace. Man arbeitet üblicherweise in einer Codebase von zig Millionen Zeilen auf die man gleichermaßen zugreifen kann (in ABAP gibt es zwar Pakete, aber kein import-Statement). Dafür dass das ganze noch im Beta-Stadium ist, funktioniert es eigentlich ziemlich gut. Ich glaube das Problem ist eher, dass sich die Leute die "mal eben" eine Entwicklungsumgebung mit Eclipse bauen wollen, meistens keinerlei Gedanken über Skalierbarkeit machen.

[Behemoth]

Das Problem ist bei Komponenten, dass sie teilweise einfach nicht funktionieren, sobald man mehrere SWF Dateien benutzt. Es ist z.B. üblich, verschiedene Teile einer Anwendung als eigenständige SWF zu bauen und dann in einer übergeordneten SWF die anderen Dateien zu laden und anzuzeigen. Das Problem ist aber, dass es teils merkwürdige Verhalten beim Code gibt, was das betrifft. Z.B. muss der gesamte Code in der übergeordneten Datei liegen und wird von den anderen nur noch aufgerufen. Adobe ist jetzt halt so cool, dass sie Komponenten bauen, die man in den aufgerufenen Dateien nicht fehlerfrei aufrufen kann, weil der Code in einer anderen Datei liegt.

Was die Grafik angeht: Wie gesagt, wir reden hier nicht von einer "normalen" Programmiersprache sondern von Designerwerkzeugen. Du kannst mit Skinning zwar das Aussehen der Komponenten eigentlich beliebig verändern, nicht aber das Verhalten. Z.B. wenn du animierte Effekte haben willst (z.B. pulsierender Knopf so lange man mit der Maus drüber ist) oder einfach ungewöhnliche Formen (runde Knopfe) stößt du mit Skinning schnell an Grenzen.

Die Sache mit den Textboxen habe ich auch nicht so wirklich verstanden. Es gibt irgendwie TextInput, TextEditbox, TextField und sonst noch kA was. Aber im Prinzip kann man immer TextField nehmen und mit Parametern so einstellen dass es sich wie die anderen verhält. Oder irgendwas in der Art.

Wenn du dich nicht aus Performanzgründen schon gegen JavaScript ausgesprochen hättest, hätte ich dir mal empfohlen, einen Blick auf Dojo zu werfen. Ist ein ziemlich umfangreiches JavaScript-Framework, praktisch der große Bruder von JQuery (und von Google entwickelt). Dokumentation ist hier aber auch Mangelware, wobei sich das in letzter Zeit langsam ändert.

[LiMuBei]

Eclipse ist so ne Sache. Gibt die einen die schwören drauf und die anderen die es verteufeln. Ich hab es auch ne ganze Weile gehasst was sich aber mittlerweile relativiert hat. Ich habe bisher die C++-Umgebung, die Latex-Umgebung und die Python-Umgebung getestet. Die beiden letzteren sind echt gut und im Vergleich zu den Alternativen das beste. Die C++-Umgebung ist unter Linux das beste was man haben kann, hat meiner Meinung nach aber gegen Visual Studio immer noch keinen Stich.

Ich habe bei diesen sehr verschiedenen Plugins auch festgestellt dass sich die Performance mal so und mal so verhält. Dementsprechend gebe ich Dominik recht dass das einfach mit dem jeweiligen Plugin zusammenhängt und nicht generell Eclipse angelastet werden kann. Ich persönlich finde Eclipse aber trotzdem sehr unintuitiv, gerade dieses Workspace- und Perspektiven-Konzept leuchtet mir nicht ein.

[Centurion]

Danke für den Tipp über Dojo. Das kannte ich noch gar nicht. Sieht ähnlich aus wie JQuery UI, wahrscheinlich noch etwas mächtiger. Aber da sieht man auch wieder das Problem: Öffnet mal die Widget-Demo-Seite im IE 8 oder niedriger und spielt ein bisschen damit rum, insbesondere dort wo sich was bewegt, z.B. bei den Slidern oder links bei dem Baum etc. Da schränkt die Performance die Usability meiner Meinung nach schon stark ein und ich habe noch einen relativ guten Rechner. Ist echt zum heulen.

[LiMuBei]

Hmmm...hab hier schon IE9 und da läuft das ganz prima Ist echt übel wenn man auf Leute Rücksicht nehmen muss die mit so einem bescheidenen Browser unterwegs sind...

[Centurion]

Ich weiß. Die JavaScript-Performance von IE9 muss sich vor keinem anderen Browser verstecken, Chrome eingeschlossen und das ist wirklich eine Leistung. Aber darunter ist's echt grottig.

[Centurion]

Hab noch mal was gefunden, was ich nicht kannte: Google Native Client. Eine Sandboxing-Technologie die noch im Entwicklungsstadium ist und es ermöglichen soll, Binaries (bisher wohl nur C) in einer sicheren Sandbox im Browser auszuführen. Ist also ähnlich wie ActiveX oder Java Applets nur eben mit einer anderen Sprache. Finde ich interessant, weil es zeigt, dass Google wohl auch nicht daran glaubt, dass clientseitig interpretierte Sprachen wie JavaScript für jede Anwendung geeignet sind. Passt außerdem ganz gut zu Sungi's ursprünglicher Frage in diesem Thread.

Bei Flash / Actionscript ist mein Verständnis inzwischen gewachsen und ich komme ein bisschen vorwärts, bin aber nicht begeistert. Ich hatte eigentlich erwartet, dass man da eine etwas professionellere Umgebung bekommt, als z.B. bei JavaScript aber dem ist nicht so. Letztendlich hat man die gleichen Ärgernisse wie bei den meisten Skriptsprachen: Der Interpreter ist viel zu "fehlertolerant" was dazu führt, dass man nur schwer herausbekommt, warum etwas nicht funktioniert. Zwei Beispiele: Vieles ist viel zu schwach typisiert, z.B. ist der data provider von der Komponente AdvancedDataGrid vom Typ Object. Wenn man da jetzt ein Objekt reingibt, dass nicht das passende Format hat, dann passiert einfach... nichts. Zweitens: Ich hatte in meinem Code versucht, auf eine Objektreferenz zuzugreifen, die zu dem Zeitpunkt noch nicht gebunden war. Der Zugriff war in einem Aufruf verschachtelt, wo ich ein data binding anlegen wollte. Aus irgendeinem Grund dachte Adobe jetzt, es wäre bei data bindings eine gute Idee die entsprechende Exception zu fangen und stumm zu ignorieren. D.h. das Binding wurde nicht angelegt und es gab keinerlei Rückmeldung, dass etwas nicht geklappt hat. Um dem ganzen die Krone aufzusetzen ist er durch das Fangen der Exception in den Main Loop zurückgesprungen, d.h. mein gesamter Code nach dem data binding wurde ebenfalls nicht mehr ausgeführt. Gefunden hab ich's nur durch Zufall, hätte auch Tage dauern können, insbesondere wenn das Projekt schon größer gewesen wäre.

Wenn man diese ganzen Probleme eh hat, kann man's vielleicht auch gleich mit JavaScript versuchen. Wir schauen uns jetzt wahrscheinlich noch mal Dojo genauer an (nochmals danke für den Tipp).

[LiMuBei]

Ich nehme an Google Native Client is auf Chrome OS zurückzuführen Da würde das für mich total Sinn machen.

[Centurion]

Stimmt, denn nach allem was ich darüber gehört habe, hätte man da ja gar keine Möglichkeit, eine Binary herunterzuladen und quasi direkt auf der Hardware laufen zu lassen. Aber auch für Sungi's Fall macht es Sinn: Kein Source Code auf Client-Seite, gute Performance erreichbar, aber dennoch halbwegs sicher direkt im Internet abrufbar.

[LiMuBei]

Grade noch was gefunden, was eventuell interessant ist: AmpleSDK

EDIT: Stack Overflow hat hier auch eine nette Übersicht zum Thema JS GUI.

[Magic]

Hey, interessante Diskussion. Hab eben erst alles durchgelesen. Übrigens bin ich selbst in Android-Programmierung für Smartphones eingestiegen. Habe ich letztes Mal erwähnt - weiß bloß nicht, ob auch Dominik gegenüber.

Von meinem Verständnis her scheint mir Flash nicht das Richtige für Dominik. Bescheid weiß am besten wohl nur Jan. Ist bei Flash der Schwerpunkt nicht Graphik und Animation aus der Retorte? Wenn ich z.B. möglichst fix ein interaktives Comic-Spielchen mit viel Effekten bauen will, scheint es die geeignete Wahl. Ohnehin schwöre ich auf Typisierung. Selbst wenn man das untypisierte Programm zum Laufen bekommt, was für ein Nachfolger soll das denn dann warten?

Konstruktives habe ich leider wenig. Die geeignete Programmiersprache für den Browser habe ich nicht gefunden und die Suche dann aufgegeben. Meine Kriterien waren Binärcode, Typisierung, Performanz. Verstehe ich das richtig, dass dir auch vorgefertigte Bibliotheken wichtig sind, Dominik?

[Centurion]

Ja genau, denn sonst sehe ich nicht wie ich in der gegebenen Zeit ein Projekt stemmen soll. Wir haben kein riesiges Zeitbudget für das Frontend, weil wir auch noch jede Menge neue Backend-Logik in ABAP entwickeln müssen.

[Centurion]

Falls es noch jemanden interessiert: Wir haben uns für unser Projekt inzwischen für Dojo entschieden und angefangen, damit ein kleines eigenes, modularisiertes UI-Framework zu bauen. Javascript ist zwar wirklich ätzend (definitiv ätzender als ActionScript) und wir werden schon ein bisschen Stress mit Browser-Kompatibilität und Performance haben, aber am Ende schien es die beste Wahl zu sein. Nochmal danke für den Tipp, Jan.

[LiMuBei]

Ich probiere mich auch gerade an Dojo und ich kann dazu nur eins sagen: FUCK YOU JavaScript! So einen dämlichen, unausgegorenen Mist hab ich wirklich noch nie gesehen