Frage an die Entwickler

[peuter]

Ich möchte hier mal eine Idee zur Diskussion stellen, die mir schon seit einigen Monaten im Kopf rumschwirrt. bzw. meinen persönlichen Wunsch für die Zukunft der CometVisu der in der letzten Zeit immer stärker geworden ist.

Zunächst zur Ausgangslage:
Ich habe zunehmend das Problem, im Code der CV die Übersicht zu behalten, vor allem die Templateengine ist mit den Jahren immer umfangreicher, mächtiger und damit zumindest für mich immer unübersichtlicher geworden. Ich finde es einigermaßen schwer im Code die Stelle zu finden in der das passiert, was ich gerade Suche. Das ist natürlich eine sehr subjektive Meinung und vielleicht bin ich der einzige mit dem Problem, aber gerade deswegen möchte ich mit diesem Thread mal die allgemeine Lage/Stimmung checken.

Ich hätte nun einen Vorschlag, wie man diesem Problem entgegenwirken könnte: nämlich die Portierung der CV auf das Qooxdoo Framework (http://www.qooxdoo.org). Damit lässt sich sehr sauber strukturierter Javascript Code erstellen und man könnte auf sämtliche bisher genutzte 3rd-Party Libraries (JQuery(-UI), RequireJS, usw.) verzichten, denn Qooxdoo bringt alles mit.

Hier mal eine kleine Liste der Vorteile die das aus meiner Sicht hätte:
Code sauberer strukturiert durch Klassenhierarchie, Interfaces, Mixins, Properties, usw.
- integriertes Build Tool, generiert Source inkl. Syntax-Check (für Entwickler) Build, Api (Doku), Abhängigkeiten werden automatisch augelöst und nur das integriert, was auch wirklich genutzt wird. Es können auch optimierte Builds für die gängigen Browser Engines erstellt werden.
- Ebenso kann man einzelne Parts erstellen, die nur bei Bedarf nachgeladen werden (könnte man z.B. für Plugins, den Editor und unterschiedliche Backends nutzen)
- Komplette Abstraktion der Browser Unterschiede, man schreibt nur einen Code für alles
- Vorhandene Layout Engines (HBox, VBox, Flow, ...), die mehr Möglichkeiten für das Layout der Seiten bieten.
- Qooxdoo intern ist da viel Optimierung in die Verbindung Javascript <-> DOM geflossen, von dem man sicherlich profitieren kann
- Zur Manipulation der Darstellung können Themes erstellt werden, die sich zur Laufzeit austauschen lassen. Mit CSS hat man hier direkt nichts zu tun. Könnte man zukünftige Designs mit erstellen, auch hier hat man eine sauberere Struktur als mit CSS

Ein paar Gedanken zur Portierung:
- Sollte dieselbe DOM-Struktur wie die alte Visu erzeugen um mit den vorhandenen Designs Kompatibel zu sein. Wobei man dafür einen Weg finden muss das von Qooxdoo automatisch generierte CSS zu teilweise umgehen. Denkbar wäre hier auch ein Kompabilitätsmodus für alte Designs und einen "nativen" für neue auf Themes basierende. Ggf. wären hier Unittests sinnvoll die die ausgegebene DOM-Struktur mit der alten vergleichen
- Plugin-Kompabilität wird wohl nicht möglich sein. Die müssten portiert werden. Dabei könnte man aber ein Plugin-Interface definieren, welches jedes Plugin implementieren muss => Saubere Schnittstelle
- KNX-Iconset in Webfont konvertieren und so nutzen. Ist einfach umsetzbar, auch unabhängig von der Portierung. So kann man jedes Icon beliebig skalieren/färben (wie normalen Text halt)


Der große Nachteil ist natürlich, dass man große Teile der CometVisu neu schreiben müsste und gerade daher möchte ich mal wissen wie Ihr so darüber denkt. Ein wenig habe ich damit schon in Richtung Proof-of-concept angefangen, nur um zu sehen ob das überhaupt realistisch umsetzbar ist und denke mittlerweile das dem so ist. Ebenso denke ich das die Vorteile die Nachteile überwiegen.

Wenn diese Idee hier nicht auf Gegenliebe stößt bleibts halt bei einem Proof-of-concept und wird nicht weiterentwickelt. Vor allem interessiert mich hier die Meinung von Chris M. als Gründer und Hauptentwickler des Projekts, aber auch von allen anderen die bei der Weiterentwicklung geholfen haben.

Das war jetzt ein wenig lang, aber ist ja auch ein komplexes Thema ;-)

[Chris M.]

Ich habe zunehmend das Problem, im Code der CV die Übersicht zu behalten, vor allem die Templateengine ist mit den Jahren immer umfangreicher, mächtiger und damit zumindest für mich immer unübersichtlicher geworden. Ich finde es einigermaßen schwer im Code die Stelle zu finden in der das passiert, was ich gerade Suche. Das ist natürlich eine sehr subjektive Meinung und vielleicht bin ich der einzige mit dem Problem, aber gerade deswegen möchte ich mit diesem Thread mal die allgemeine Lage/Stimmung checken.

Ich denke, das ist auch objektiv so. In der Vergangenheit haben wir ja schon einiges an Code ausgelagert um das ganze übersichtlicher zu gestalten - aber es ist immernoch ein gewachsener Zustand, dem ein Refactoring durchaus gut tun würde.

Ich hätte nun einen Vorschlag, wie man diesem Problem entgegenwirken könnte: nämlich die Portierung der CV auf das Qooxdoo Framework (http://www.qooxdoo.org).

Ich kenne Qooxdoo nicht, habe aber zumindest eine Erfahrung mit JQuery gemacht. Am Anfang ist's sehr komplex, dann hat man's kapiert und es sieht genial aus. Und dann merkt man mit der Zeit immer mehr wo's klemmt und knirscht

JQuery finde ich weiterhin einen Segen - für Rapid Prototyping! Für große, komplexe Anwendungen (wie es die CometVisu inzwischen ist) muss man schon sehr genau schauen, was wo Sinn macht.
So geht z.B. das ganze Textify darauf zurück, dass die Performance der ganzen JQuery Zugriffe auf den DOM nicht skaliert hat. Nun wird alles in einem String zusammen gebastelt und der auf 1x in den DOM gehängt. Das ist kein Fehler oder keine Schwäche von JQuery (außer etwas Overhead über die nativen Aufrufe) - aber ein Punkt wo man eben die ganze Funktionalität erst man in die Tonne kippen muss und es per Hand machen muss. (Spätere DOM Modifikationen können durchaus JQuery nutzen, die dauern aber auch nur kurz).

Das andere was man sieht, wenn man Bibliotheken oder Frameworks nutzt ist die Abhängigkeit von deren Entwicklung. Wird die eingestellt, muss man mit dem alten Code stehen bleiben oder auf etwas neues portieren.

Und am Schluss können Bibliotheken eigentlich nur Performance kosten und Komplexität hinzufügen. (Lassen wir mal einen ASM.js Kompiler außen vor - der ist aber nicht für DOM Modifikationen gedacht). Und wir vieles bereits selber und das teilweise besser machen.

Das ist jetzt bitte nicht als Veto gegen irgend eine solche Lösung aufzufassen (weder Qooxdoo noch was anderes), sollte aber meine Skepsis und die Basis auf der die entstanden ist, zeigen.

Wenn man übrigens über so etwas nachdenkt, so kann man auch an React (https://facebook.github.io/react/) denken. Da ist nicht nur 1&1 dahinter, sondern Facebook und gilt wohl zur Zeit als der hippe Trend dem alle hinterher hecheln...

- KNX-Iconset in Webfont konvertieren und so nutzen. Ist einfach umsetzbar, auch unabhängig von der Portierung. So kann man jedes Icon beliebig skalieren/färben (wie normalen Text halt)

Das ist ein unabhängiges Thema das man durchaus angehen kann.

Der große Nachteil ist natürlich, dass man große Teile der CometVisu neu schreiben müsste und gerade daher möchte ich mal wissen wie Ihr so darüber denkt. Ein wenig habe ich damit schon in Richtung Proof-of-concept angefangen, nur um zu sehen ob das überhaupt realistisch umsetzbar ist und denke mittlerweile das dem so ist. Ebenso denke ich das die Vorteile die Nachteile überwiegen.

Ich denke wir haben mehr von einem sauberen Refactoring der Template-Engine und ggf. von weiterem Code.
Auch wenn sich "was neues machen" erst mal besser anfühlt als im alten rumsortieren und immer Angst haben, etwas kaputt zu machen...

[peuter]

Ich kenne Qooxdoo nicht, habe aber zumindest eine Erfahrung mit JQuery gemacht. Am Anfang ist's sehr komplex, dann hat man's kapiert und es sieht genial aus. Und dann merkt man mit der Zeit immer mehr wo's klemmt und knirscht
...
JQuery finde ich weiterhin einen Segen - für Rapid Prototyping! Für große, komplexe Anwendungen (wie es die CometVisu inzwischen ist) muss man schon sehr genau schauen, was wo Sinn macht.

Man kann Qooxdoo nicht wirklich mit JQuery vergleichen, zumindest nicht den sehr mächtigen Desktop-Teil. Wir nutzen das seit längerer Zeit in der Firma für eine webbasierte durchaus recht komplexe Applikation. Aus dieser Erfahrung wage ich mal zu behaupten, dass man mit den aktuellen und zukünftigen Anforderungen der CometVisu hier nicht an den Punkt kommen wo man zuviel selbst machen muss weil das genutzte Framework die Funktionen einfach nicht hergibt oder die Umsetzung nichts taugt.
Wie Du schon gesagt hast. JQuery ist für größere Anwendungen nur noch teilweise tauglich und man kommt immer mehr dazu die Dinge selbst zu implementieren.
Ist halt mehr für Webseiten mit Javascript gedacht und weniger für komplexere Webapplikationen.

Das andere was man sieht, wenn man Bibliotheken oder Frameworks nutzt ist die Abhängigkeit von deren Entwicklung. Wird die eingestellt, muss man mit dem alten Code stehen bleiben oder auf etwas neues portieren.

Da würde ich mir weniger Sorgen machen. Klar ist, das Qooxdoo ein klares Marketing Problem hat, denn es ist ziemlich unbekannt (ich hatte davon auch noch nie gehört, bis ich es benutzt habe). Es gibt aber derzeit Vorbereitungen hinter den Kulissen sich der Community zu öffnen, damit nicht alles von 1&1 abhängt. Nichtsdestotrotz ist es Open-Source und es gibt genug Nutzer, dass ich mir da keine großen Sorgen mache, dass das Projekt eingestellt wird.

Und am Schluss können Bibliotheken eigentlich nur Performance kosten und Komplexität hinzufügen. (Lassen wir mal einen ASM.js Kompiler außen vor - der ist aber nicht für DOM Modifikationen gedacht). Und wir vieles bereits selber und das teilweise besser machen.

Klar, das kann ich auch nicht wirklich abschätzen inwieweit sich das auf die Performance auswirken würde. Aber das ist der Hauptgrund für mich das mal als Proof-of-concept umzusetzen, um das vielleicht besser abschätzen zu können.

Wenn man übrigens über so etwas nachdenkt, so kann man auch an React (https://facebook.github.io/react/) denken. Da ist nicht nur 1&1 dahinter, sondern Facebook und gilt wohl zur Zeit als der hippe Trend dem alle hinterher hecheln...

Auch das ist nicht wirklich mit Qooxdoo vergleichbar (zumindest nach meiner ersten Einschätzung). Qooxdoo entwickelt man eher wie eine Desktop GUI (z.B. vergleichbar mit Java-SWT oder auch QT), d.h. man hat mit HTML/CSS erstmal garnichts zu tun. Bei React sieht das nicht so aus, auf den ersten Blick würde ich das eher mit JQuery(-UI) vergleichen. Ist aber nur mein erster Eindruck, ich kenne React nicht wirklich.

Ich denke wir haben mehr von einem sauberen Refactoring der Template-Engine und ggf. von weiterem Code.
Auch wenn sich "was neues machen" erst mal besser anfühlt als im alten rumsortieren und immer Angst haben, etwas kaputt zu machen...

Ich will das Rad ja nicht neu erfinden, sondern so viel wie möglich einfach übernehmen und eben sauber Refactoren nach dem Prinzip "Ein Klasse für jede Aufgabe", im Grunde so wie es in der pure-structure bereits gemacht wird.

Dafür würde sich halt die Art und Weise wie in Qooxdoo die Klassen gehandhabt werden sehr gut anbieten, weil man hier klar strukturierte Klassenhierarchien mit Vererbung bauen kann. Das sieht z.B. so aus (für die Datei cv/ui/Templateengine.js):

qx.Class.define("cv.ui.Templateengine",
{
  extend : qx.ui.core.Widget,
  type : "singleton"
}

Im Gegensatz zu dem nativen Java-Prototyping Kram, ist das für jeden der schon mal ein eine OO-Sprache programmiert hat eigentlich selbsterklärend.
Noch dazu muss man hier nicht mühsam, wie bei Require-JS die Abhängigkeiten selbst definieren sondern das funktioniert einfach out-of-the-box.
Und wenn man dann schon Qooxdoo einsetzt kann man die anderen genutzten externen Bibliotheken gleich mit über Bord werfen, da man das auch mit Qooxdoo lösen kann. So war mein Gedankengang hinter der ganzen Idee.

Wie schon gesagt, die Vorteile sind immens, als Nachteil steht die Frage nach der Performance im Raum, was aber erstmal zu prüfen wäre ob dem so ist. Denn was Du mit mit dem Textify eingebaut hast um die DOM-Manipulationen einzuschränken, macht Qooxdoo intern permanent. Zunächst wird immer nur das in den DOM-Tree gehängt was man auch sieht (also wäre das ein Lazy-Loading der Pages), außerdem werden die DOM-Änderungen nie direkt ausgeführt sondern in eine Queue gehängt die dann bei Bedarf geflushed wird.

[peuter]

Für die Webfont Geschichte habe ich mal ein Enhancement-Issue bei Github angelegt. Ich würde das gerne auch so mit weiteren Ideen machen, die mit bei meiner Proof-of-concept Programmierübung so in den Sinn kommen. Einiges davon ist zwar auch hier im Forum schonmal erwähnt, aber hier geht das leicht verloren.

Auch wenn die Qooxdoo-Portierung wohl keine Weiterentwicklung der CometVisu wird, bringt mir das zumindest eine Menge, weil ich mich mit jeder Stelle der aktuellen CometVisu auseinandersetzen muss um das zu portieren. Und es gibt da viel mehr Dinge im Detail die ich noch gar nicht kannte bzw. Funktionalitäten die mir nicht bewusst waren. Und dabei wird mit vielleicht die ein oder andere Idee kommen, wo man noch was verbessern könnte, die muss nicht unbedingt immer richtig sein, aber zumindest diskussionswürdig ;-)

Also nicht wundern, wenn es in der nächsten Zeit noch mehr Enhancement-Issues gibt ;-)

[Chris M.]

Für die Webfont Geschichte habe ich mal ein Enhancement-Issue bei Github angelegt. Ich würde das gerne auch so mit weiteren Ideen machen, die mit bei meiner Proof-of-concept Programmierübung so in den Sinn kommen. Einiges davon ist zwar auch hier im Forum schonmal erwähnt, aber hier geht das leicht verloren.

So ein Forum ist halt keine LOP-Liste. Daher bitte, wie Du ja schon geplant hast, die Issues nutzen. Und dank den setzbaren Tags kann man da ja auch schön die Meta-Informationen setzen ob das dringend ist oder schöner Wohnen für irgendwann.

Auch wenn die Qooxdoo-Portierung wohl keine Weiterentwicklung der CometVisu wird, bringt mir das zumindest eine Menge, weil ich mich mit jeder Stelle der aktuellen CometVisu auseinandersetzen muss um das zu portieren. Und es gibt da viel mehr Dinge im Detail die ich noch gar nicht kannte bzw. Funktionalitäten die mir nicht bewusst waren. Und dabei wird mit vielleicht die ein oder andere Idee kommen, wo man noch was verbessern könnte, die muss nicht unbedingt immer richtig sein, aber zumindest diskussionswürdig ;-)

Wie ich schon oben geschrieben hatte: ein grundsätzliches Refactoring (ob mit oder ohne weiterer Lib) würde der Code-Wartbarkeit sicher gut tun

[peuter]

Fürs Refactoring gibts auch ein Issue:

https://github.com/CometVisu/CometVisu/issues/252

Ich habe mal kurz eine Code-Analyse, mit dem dort erwähnten Tool machen lassen (nur vom lib-Folder) ist schon ganz interessant und zeigt, dass es durchaus was zu tun gibt an der Refactoring-Front. Das hilft einem zwar nicht dabei wie man das Refactoring macht, aber immerhin kann man den Fortschritt in gewisser Weise quantifizieren.