YAML kleine Umfrage
 

Hallo liebe Leser,

kürzlich wurde ich über das CMS Papoo mit einem YAML Layout konfrontiert. Meine Aufgabe war, vorhande Layoutschwächen auszubügeln.

Da ich mein CSS vorzugsweise selbst schreibe, habe ich mir das vorher irgendwie nie angeschaut, höchstens mal überflogen - auch wenn alle Welt davon schwärmt. Mir ist aufgefallen, dass es hier zwar ein durchdachtes System gibt, aber die Fülle an Anweisungen ist ja Wahnsinn. Ehrlich gesagt hätte ich das komplette Layout in einer einzigen CSS-Datei mit etwa 5% der derzeit existenten Länge unter gebracht (hätte man mich gefragt ;)). Wie ich finde, wird diesem folgend gleichzeitg der Quelltext unnötig aufgebläht.

Die Fehlersuche fand ich schon sehr aufwendig und nervig. Ein paar Skalierungs- sagen wir Unschönheiten habe ich auch gefunden.

Aber wie gesagt, alle Welt schwärmt von YAML. Deshalb würde ich hier gern einmal Eure Meinungen zum Thema hören. Ich möchte nämlich wissen, ob ich da irgdwas übersehen habe und alles ganz falsch sehe.

Ist YAML wirklich so toll? Worin liegen die Vorteile? Naja, die Nachteile und meine Meinung habe ich ja genannt.

Also, vielen Dank und Gruß

YAML geht gar nicht, aus den von Dir genannten Gründen - CSS & Markup vollgestopft bis zum geht-nicht-mehr.

Jep - ist auch meine Meinung.

Habe mir mal Blueprint angesehen, auch ganz schön mächtig, wobei dieser Vergleich ein bischen hinkt, da Blueprint ein Grid-Framework ist.
In beiden Fällen ist das CSS für jeden möglichen Case aufgebaut, somit aufgeblasen...

Hab es bei einer Seite noch im Einsatz - Werde ich aber sobald ich die Zeit dazu habe auf meine selbst geschrieben Styles umstellen.

Wie meine 2 Vorredner schon sagten: Zu aufgeblasen das ganze. Für Anwender, die sich mit CSS und Co nicht bis ins kleinste Detail auseinander setzen wollen, hat es sicher seine Daseinsberechtigung.

Moin,

jau, Yaml ist auch nix für mich.

Hatte mal kurz damit angefangen aber wegen haarsträubender Unübersichtlichkeit (modifications/basemod_2col_left_vlines.css :shock:)
gleich wieder drangegeben.

Gruß
Klaus

Du sagst damit, dass ein maßgeschneidertes System effzienter zu fassen ist als ein allgemeingültiges. Wenn du den Kunden überzeugen kannst, dass du es auch billiger hinkriegst als 08/15 über ein Framework, wird er dich gerne für das nächste Projekt ins Auge fassen.

Die Kunden haben ein vorgefertigtes Shopsystem zusammen mit einem YAML installiert, und sie haben dafür Gründe, die wenig mit unseren CSS-Angelegenheiten zu tun haben. Allerdings werden die langfristigen Kosten eines solchen ZKZE-Frameworks* von denjenigen, die es aufsetzen, nicht immer im vollen Umfang berücksichtigt. Verglichen mit der Zeit, die eine effektiver produzierte Seite beim späteren Erweitern und Debuggen verlangt, schneiden Frameworks schlecht ab.

Beim Analysieren fremden Codes empfiehlt es sich, erst einmal davon auszugehen, der Autor hätte sich dabei schon etwas gedacht. Es braucht einige Zeit, sich in das System hineinzudenken und den Fehler zu isolieren, und es braucht eine ungleich längere Zeit, den Workaround dann so zu implantieren, sodass es nicht zu Konflikten kommt. Die Kosten dafür müssen dem Kunden transparent gemacht werden.

*ZKZE: Zu kompliziert zum Erklären.

Die im Thread zitierte Aufgeblähtheit des Quelltextes ist sicherlich ein Kriterium, ebenso wie die anfangs seltsam anmutenden Namensgebungen, aber YAML (oder andere Frameworks) einfach nur damit abzufertigen finde ich ein bisschen zu kurz gegriffen ;)

YAML ist ein Framework, und insofern erstmal vorab ein paar Worte dazu, was das überhaupt ist. Das gilt nicht nur für CSS, sondern auch für JS, PHP und andere Sprachen:
YAML ist ein allgemeines Framework, also kein Maßanzug sondern einer von der Stange. So etwas hat Vor- und Nachteile:

Nachteile:

• Frameworks erzeugen mehr Code als notwendig, weil sie für viele Situationen optimiert wurden und nicht für eine. Je komplexer das Layout und je mehr Inhalte auf einer Site stehen, desto weniger fällt dieser Overhead allerdings ins Gewicht.
• Sie übernehmen die Konventionen des Framework-Entwicklers und damit ungefragt dessen persönliche Vorlieben, zum Beispiel bei Namensgebung und Syntax.
• Die Einarbeitung in das Framework kostet Zeit. Sie müssen sich vor dem Gebrauch mit der Struktur des Frameworks vertraut machen und lernen, wie man damit zum Ziel kommt.

Genau diese Nachteile sind ja im Thread auch schon genannt worden.

Vorteile:

• Ein solides und vielfach bewährtes Fundament spart Zeit bei der Umsetzung neuer Projekte.
• Die Pflege des Quelltextes wird durch konsistente Konventionen bei der Namensgebung für IDs und Klassen erleichtert. Gerade bei der Arbeit im Team (z. B. in Agenturen) ist das ein wichtiger Faktor.
• Patchwork und Browserfehler kosten weniger Nerven, denn die Bug-Prophylaxe ist Teil des Frameworks.

Besonders beliebt ist YAML übrigens in Zusammenarbeit mit CM-Systemen wie Typo3, Joomla, Drupal und Co. Anzüge von der Stange sitzen vielleicht nicht so perfekt wie maßgeschneiderte, sind aber schlicht und einfach billiger ...

Der aufgeblähte (und auf den ersten Blick unübersichtliche) Code wird oft als Hauptargument gegen YAML angeführt und wer in seinem Quelltext gegen jedes überflüssige DIV kämpft, für den ist YAML auf den ersten Blick ein Albtraum.

Witzigerweise stört das bei anderen Frameworks kaum jemanden. Wer jQuery oder andere JS-Bibliotheken für zwei drei Effekte einsetzt, schleppt dafür etliche Kb Code mit sich rum. Bei serverseitigen Frameworks wie CakePHP sieht das ähnlich aus. Meine Theorie ist, dass das bei YAML eher stört, weil man es direkt im Browser-Quelltext sieht: Viele DIVs und viele CSS-Dateien, während jQuery im Verborgenen bleibt. YAML-Entwickler Dirk Jesse hat das Thema übrigens in seinem Blog-Eintrag CSS-Frameworks in der Diskussion auch aufgegriffen und in einem Kommentar-Thread vom Dezember 2005 wurde das ausführlich durchdiskutiert.

Fazit:
Wer bereits sein eigenes Framework hat, als Dateisammlung und als Know-How im Kopf, reagiert gegenüber einem fremden Framework, in das er sich erst mühsam einarbeiten müsste, automatisch abwehrend. Das ist verständlich und natürlich, bedeutet aber nicht, dass das Framework nichts taugt.

Grüße aus Groningen
Peter

Ich denke, man kann es so sagen:

Anders gesagt: Ich persönlich würde es nie einsetzen, aber wer sich nicht so sehr in die Materie vertiefen will/kann, kann in YAML durchaus eine sinnvolle Lösung finden. Dennoch: Aus meiner persönlichen Sicht geht es gar nicht ;)

Das mag für Anwender gelten, die Yaml in Rahmen eines CMS verwenden. Außerhalb eines CMS halte ich Yaml für die zitierte Benutzergruppe für ungeeignet, da es aufgrund seiner Komplexität sehr schwer zu pflegen ist.

Und dass selbst professionellere CSS-Coder ihre Schwierigkeiten mit diesem Framework haben können, erkennt man vielleicht auch daran, dass hier in den verschiedenen Unterforen Probleme mit Yaml-basierten Sites gar nicht so selten sind.

Oh, interessantes Feedback. Ich danke Euch für Eure Meinungen, die, wie ich vermutete, teilweise doch sehr unterschiedlich sind.

Die Argumente von Peter habe ich mir im ähnlichen Stil ja bereits mehrfach anhören müssen, allerdings lange nicht so höflich ;)
Eher unter dem Motto, wer ein bißchen übt, wird dann schon irgendwann durchsehen.

Anundfürsich sehe ich beim "Zurechtfinden" eher weniger das Problem. Mich stört eben auch, wie die meisten schon geschrieben haben, diese Masse an Anweisungen und den damit verbundenen Wartungsaufwand. Es dauert einfach, falls sich irgendwo ein Fehler eingeschlichen haben sollte.

Damit will ich YAML aber nicht verurteilen und wie ich bereits erwähnte, steckt da schon ein durchdachtes System hinter. Genau wie Windows; das hat auch ein System - sorry :mrgreen:

Schönes Wochenende wünsche ich