Ich entschuldige mich im Voraus für etwaige Schreib- und Grammatikfehler, jedoch bin ich Niederländer und somit werde ich nie das Thema “der, die, dem den oder des” en perfection beherrschen :-)

Ich finde es schon ein wenig impertinent dass Jemand der gerade anfängt behauptet dass Profis Angst hätten für Hobbybastler.

Es ist ja doch wohl so dass eine Webseite nicht nur auf validen Code, Browserkompatibilität und Barrierefreiheit mittels CSS und (X)HTML beruht.

Da kämen dann doch auch noch die Facetten des Designs dazu, oder?

Schliesslich hat der durchschnitts User keine Ahnung was sich “hinter” der Seite, die er gerade besucht, abspielt.

Primär hängt der Erfolg eines Internetauftritts von dem Design ab, weil das der erste Eindruck bildet (innerhalb vonb 10 Sekunden) und anhand dessen der Besucher entscheidet ob er ein gutes “Bauchgefühl” hat und bleibt oder die Seite wegklickt.

Photoshop, In-Design, Freehand, Illustrator sind richtige professionelle Tools, die man wirklich studieren muss damit man mit diese Software arbeiten kann. Und danach muss man sich ständig auf dem laufenden halten.

Ich bin mir sicher dass irgendwelche Nicht-Profis dies absolut nicht beherrschen.

Ebenso sollte man, um eine gut funtionierende Webseite zu erstellen doch auch basierte Kenntnisse in PhP und JavaScript besitzen.

Was das Design angeht, gibt es dort richtiggehende Studienrichtungen. Die goldene Mitte zum Beispiel wie ein Layout eingeteilt wird und wie ein Betrachter eines Magazins, einer Zeitung oder eben eine Webseite anschaut (von Oben Links angefangen (Eintrittsbereich) bis unten rechts (Austrittsbereich). Alles über die Psychologie eines Betrachters wurde in Studien festgelegt.

Um dann nicht die andere Themen wie Farblehre etc. zu nennen. Da Farben Emotionen auslösen ist diese sehr wichtig. Um nicht zu vergessen unsere Sehbehinderte Mitmenschen. Es gibt z.B. verschiedene Arten von Farbblindheit (Rot-, Grün- und Blaublindheit) um nicht zu vergessen das es bei diese Sehstörung totale Farbenblinheit (nur shcwarz/weiß und bunte Farben grau) und Zweifarbensehen gibt. Also sollte man testen (dazu gint es Seiten im Web wo man das mit seinem Design machen kann) ob es auch für diese Zielgruppe (Besucher sind nun mal potenzielle Kunden) ein comfortables Surferlebnis ist, wenn sie die Seite besuchen.

Also sehr wichtig für barrierefreie Webseiten.

Ungeachtet ob ich CSS-Frameworks all dann nicht gut finde (ich arbeite mit Joomla! ein CMS. Auch so etwas aber um komplette Webseiten mit Funktionen zu erstellen damit der Kunde selbst seine Inhalte bearbeiten und/oder austauschen/aktualisieren kann und in der ein Framework für JavaScript “mitgeliefert wird. ) aber es gehört doch eine Menge mehr dazu eine Internetpräsenz zu erstellen.

UND… man kann so ein Framework nur DANN benutzen, wenn man über fundierte Kenntnisse über CSS, (X)HTML, PhP und JavaScript verfügt!

Ist das gleiche wie bei WYSIWYG Editoren die dann, indem Du ein Bildchen ins Fester knallst oder einen Text eingibst, automatisch den Code generiert.

Wenn man keinen Schimmer der Sprache hast, wie kannst man denn in den Quellcode gehen und die Anpassungen, die man gerne hätte, vornehmen?

Ich habe in meiner Ausbildung gelernt, dass man ERST die ganze Materie aus dem FF beherrschen sollte und erst DANN mit solche “Spielzeuge” wie Dreamweaver & Co. rangehen soll.

Aber ehrlich gesagt habe ich Dreamweaver einmal benutzt und dann habe ich auf meine eigene Bibliotheken zurückgegriffen. Aber das erfordert Kenntnisse.

Es ist natürlich deine Wahl wie Du Seiten generierst, aber vielleicht solltest Du erstmal lernen welche Gebiete man beherrschen sollte, bevor man behauptt das Leute wie Du uns Angst machen.

Alles Gute,

Rob

Wenn von Seiten der Profis so massive Kritik an CSS-Frameworks geübt wird, wie es im Fazit heißt, vermute ich darin weniger eine Angst vor der Fremdheit des Konzepts als vielmehr eine Angst davor, daß es nun auch Nicht-Profis möglich wird, Webseiten in einer Qualität zu erstellen, die bisher nur sie garantieren konnten. Das wäre eine vermutlich über weite Strecken unbegründete Angst vor einer Entwertung des eigenen und gut gehüteten Wissens. Wenn man es an der Kompetenz mißt, sind nun aber die Grenzen zwischen Laien und Profis im Bereich der Web-Gestaltung wie in vielen anderen
Bereichen fließend. Liegt nicht wenigstens ein Teil des Erfolgs von YAML gerade darin begründet, daß es eben beide Gruppen anzusprechen vermag? Mich wundert es ein bißchen, daß YAML in dem Beitrag dann doch recht entschieden als vorrangig für Profis bestimmt präsentiert wird. Ich verstehe schon, daß Dirk bei den Profis eine Lanze für YAML brechen möchte, aber sowohl die Dokumentation als auch das YAML-Buch lassen erkennen, daß es ihm sehr wohl auch um eine Popularisierung geht, die ihm übrigens auf sympathische Weise gelingt.  Ich möchte damit ansprechen, daß es nicht nur professionelle Entwickler auf der einen Seite und Hobbybastler auf der anderen gibt, wie es im Artikel z.T.  anklingt. Es gibt auch Leute dazwischen, die sich für die Codierung mit YAML nicht primär aus Spaß an der Freude entscheiden, sondern weil sie eine ordentliche Webseite brauchen und selbst erstellen möchten, also wohlüberlegt und mit Blick auf einen akzeptablen Einarbeitungs- und Zeitaufwand, auf Flexibilität, Standardgerechtheit und umfassende Browserunterstützung.

Ich wollte diese sehr subjektive Perspektive hier kurz einbringen, wie gesagt, um Dirk zu danken und ihn zu ermutigen, den breiten Ansatz von YAML weiter zu pflegen.

Falk

danke erst einmal für diese überaus informative Essay. Für jemanden der bis jetzt noch nicht mit css frameworks gearbeitet hat, aber immer mal wieder Kommentare zu YAML oder auch YUI Grids gelesen hat, schließt das hier, meiner Meinung nach, essentielle Verständnislücken. Speziell auch die Kritik von Jonathan Christopher oder Jens Meiert wird sachlich zerlegt und es wird aufgezeigt aus welchem Hintergrund heraus die Kritik der beiden entstanden ist.

Zum Thema Performance. Verständlicherweise ist diese während der Entwicklungsphase des Projektes noch nicht optimal und eventuell auch hinterher nicht. Was dann aber nicht am Framework liegt, sondern an der nicht konsequenten Performance Optimierung der Dateien.

Jedenfalls, auch wenn nicht beabsichtigt, macht diese Essay Lust auf YAML, beziehungsweise endlich den Knick zu kriegen sich einzuarbeiten, wovor ich bis jetzt immer etwas Abstand gehalten habe. Was aber auch an der vielen Negativ Kritik gelegen hat.

Oliver

Was mir persönlich jedoch überhaupt nicht gefällt ist die durchmischung mit englischen Passagen. Nicht jeder beherrscht englisch fliessend und muss sich daher diese Passagen erst mühsam übersetzen, was den Lesefluss erheblich stört. Zudem mag es durchaus auch Leute geben, die gar kein englisch können, sich aber trotzdem für Webstandardkonformes Webdesign und CSS-Frameworks wie YAML brennend interessieren. Ohne die hervorragenden Artikel von Leuten wie Euch sind diese Menschen aufgeschmissen und werden aus dieser schönen Welt ausgeschlossen, was sehr schade ist und nicht gerade der Nachwuchsförderung dient… Somit ist ein solcher Artikel also nicht “Barrierefrei” ;-)

Ich bitte daher mal freundlich darum: macht Euch bitte die Mühe und übersetzt oder schreibt solche Artikel komplett auf deutsch, dann hat jedermann die Chance, von Eurem Wissen zu profitieren.

Also sei bitte nicht beleidigt, dass ich eben nicht die Klappe zu Deiner Meinung halte.

akteptiert .-p

cx

Es ist doch leider so, dass gerade die Diskussionskultur vieler deutschsprachiger Blogs immer nur Mainstream ist, der entweder Bravo- oder Buh-Kommentare generiert. Von Klappe halten ist da eher keine Rede. Der Mainstream zum Thema Frameworks ist eben “Buh”. 

Du hast geschrieben “Die Verwendung eines Frameworks ist und bleibt aus meiner Sicht Geschmackssache; das betrifft “echte” Programmier-Frameworks wie Layout-Frameworks gleichermaßen”. OK, das ist doch mal eine Aussage. Aber der anschließende Text mit “blumigen” Thesen erinnert an Adornos undurchdringlich-überkomplizierter Dialektik und kann ebenso wenig zum eigentlichen Thema beitragen wie die Aussage “Ich find’ Frameworks blöd, weil ich außerdem eh nicht damit arbeite”.

Also sei bitte nicht beleidigt, dass ich eben nicht die Klappe zu Deiner Meinung halte.

Da muss man schon sorgfältig unterscheiden und aufpassen, was man schreibt.

und

egal, ob Du uns das unterstellst oder nur falsch verstanden hast [...]

Nils, es sind Äusserungen wie diese, durch die Diskussion aus der Bahn geraten; ich hatte das in meinem ersten Kommentar angedeutet.

1. Ich achte schon darauf, was ich schreibe. Eine Ermahnung ist so unangebracht wie überflüssig.

2. Ich habe aus meiner Perspektive weder etwas unterstellt, noch falsch verstanden. Dass Du mir lediglich diese zwei Möglichkeiten zugestehst, ist imho symptomatisch für die Diskussionskultur in einigen deutschsprachigen Blogs.

Sorry für meine kritischen Äusserungen - Klappe halten oder Bravo rufen kam halt schon immer besser an.

In diesem Sinne,

cx

Dass flexible und robuste Frameworks einen Weg in die Zukunft der Webentwicklung weisen können, ist eine aus der Praxis begründete Annahme, siehe Essay.

Jene Annahme ist nun aber nicht automatisch mit dem Anspruch einer Vormachtstellung des eigenen Frameworks zu verwechseln, selbst wenn der Verfasser - wie hier - gleichzeitig Entwickler ist. Da muss man schon sorgfältig unterscheiden und aufpassen, was man schreibt.

Und egal, ob Du uns das unterstellst oder nur falsch verstanden hast: eine nüchtern-wissenschaftliche Abhandlung mit der Notwendigkeit größtmöglicher Objektivität war auch nie Anspruch dieses Essays.

Zum zweiten schreibe ich lediglich meine Vorstellungen nieder, wo es mit YAML in Zukunft hingeht.

Meine Lesart des betreffenden Satzes ist anders - Du stellst einen Zusammenhang zwischen Deinem Framework und der prospektiven Entwicklung des “webcodings” her. Eine bescheidenere Interpretation als Vormachtstellung bleibt mir an dieser Stelle verwehrt. Diese Darstellungsweise ist - wie bereits angedeutet - kein Alleinstellungsmerkmal Deines Artikels.
Stosse Dich bitte nicht an möglicherweise “blumigen” oder polarisierenden Formulierungen… Dein Artikel als Diskussionsgrundlage kann dem Ideal einer nüchtern-wissenschaftlichen Darstellung (ebenfalls) nicht entsprechen .-

Aber der Sinn und Zweck eines Essay ist eben, dass man sich darin die notwendige Zeit nehmen kann, Dinge zu diskutieren. Das magst Du persönlich langatmig finden, Pauschalität erwächst daraus jedoch nicht.

Diese Kausalität habe ich auch nicht hergestellt; der Bezug findet sich im vorherigen Absatz.

Darum: Yet Another Multicolumn Layout.

Das ist keine befriedigende Antwort, insofern man meine Anspielung nicht ignoriert.

cx

Dass die Diskussionen um Pro und Contra des Öfteren aus der Bahn geraten / entarten, liegt sicher auch an dem Vormachtanspruch der jeweiligen Entwickler. Stets dreht es sich um professionelle Entwicklung für absolute Profis

Ein Projekt braucht eine Zielgruppe, für CSS Frameworks im Allgemeinen und YAML im Speziellen sehe ich diese im Bereich der professionellen Webentwickler. Zwar können auch Hobbybastler und Laien von der Verwendung von Frameworks profitieren (weil sie zum Ziel kommen), aber erst mit einem Grundmaß an CSS-Kenntnissen lässt sich YAML richtig effektiv einsetzen. Ein Hobbybastler baut seine eigene Homepage, ein professioneller Entwickler mehrere Layouts pro Woche oder Monat. Es ist zudem nachvollziehbar, dass die positiven Effekte vor allem bei der mehrfachen Anwendung nachhaltig zum Tragen kommen. Ein solche Abgrenzung beschreibt daher keine “Vormachtstellung” sondern lediglich den Focus der Entwicklung. Es gibt genug Frameworkprojekte, die deutlich einfacher zu verstehen sind als YAML und demzufolge einsteigerfreundlicher sein mögen.

... ich zitiere aus Deinem Beitrag: “... wohin die Reise für Webentwickler in den nächsten Jahren gehen wird.”
Seltsam, dass es so viele Entwickler / Projektanten / Strategen gibt, die uns das seit Jahrzehnten immer wieder gebetsmühlenartig versprechen…

Fürs erste wäre es schön, wenn es wahr wäre und wirklich so viele Entwickler regelmäßig über den Tellerrand schauen würden. Zum zweiten schreibe ich lediglich meine Vorstellungen nieder, wo es mit YAML in Zukunft hingeht. Damit musst Du nicht übereinstimmen. Daher frage ich mich, was Du eigentlich sagen willst bzw. was Dich stört?

Aus dieser Perspektive erscheinen die langatmigen Argumentationen in Deinem Artikel genauso pauschal wie die ablehnende Haltung der entsprechenden Gegner.

Für wahr, in Zeiten von Link- und Top-10-Listen Postings mag das Lesen längerer Beiträge ungewohnt anstrengend sein. Aber der Sinn und Zweck eines Essays ist eben, dass man sich darin die notwendige Zeit nehmen kann, Dinge zu diskutieren. Das magst Du persönlich langatmig finden, Pauschalität erwächst daraus jedoch nicht. Hier müsstest Du schon ins Detail gehen.

Apropos Trittbrettfahrer: wieso benutzt Du für Deine Schöpfung dasselbe Akronym wie Yet Another Markup Language?

Darum: Yet Another Multicolumn Layout.

Apropos Trittbrettfahrer: wieso benutzt Du für Deine Schöpfung dasselbe Akronym wie Yet Another Markup Language?

cx

vielen Dank für das sehr interessante Feedback . Die Komplexität ist sicherlich eine Hürde, wenn man Blueprint CSS oder YUI Grids als Gegenbeispiel heranzieht. Der Hauptunterschied zwischen YAML und diesen Systemen ist, dass man für deren Anwendung, keine CSS-Kenntnisse benötigt, denn das Layout wird ausschließlich über den Markup und die Klassenzuweisung erstellt. Bei YAML gehts ohne CSS nicht und Effektivität erreicht man erst mit einem gewissen CSS-Grundwissen. Ich zweifle allerdings daran, dass man auf dieses Grundmaß an Verständnis des Systems verzichten kann oder es vor dem Nutzer auf Dauer verstecken kann.

Der YAML Builder ist definitiv nicht nur ein Weg zur einfacheren Anwendung von YAML. Ich bin überzeugt davon, dass derartige Tools in Zukunft stark an Bedeutung gewinnen, denn auf Grundlage von Frameworks wie YAML lassen sich Layoutkonzepte problemlos automatisieren. Die derzeitigen Grenzen des YAML-Builders spiegeln lediglich meine zeitlichen Grenzen für die JS-Programmierung wieder, nicht die des Frameworks. Hier ist in Zukunft viel mehr möglich. Ebenfalls vorstellbar ist eine Metasprache, wie Du sie erwähnst. Die Idee ist alles andere als abwägig und ich denke, dass im Bereich der JS- und PHP-Frameworks dieser Weg zur Erstellung von Benutzeroberflächen bereits gegangen wird (oder man kurz davor ist). Somit ist etwas ähnliches auch für Webseitenlayouts vorstellbar.

Ich habe viel Verständnis dafür, wenn Autoren Ihr Können und Wissen demonstrieren wollen. Leider wirkt sich dieses sehr menschliche Streben auf die Qualität und Transparenz des Buchs aus bzw. wirft es ein schiefes Licht auf das Tool selbst.

In diesem Detail mag ich Dir nicht folgen, denn obgleich natürlich jeder seine eigene Sichtweise bezüglich guter Dokumentationen und Bücher hat, bin ich doch vom Ansatz und der Umsetzung meines Buches aufgrund der allgemeinen öffentlichen Wahrnehmung überzeugt. Ein praxisorientiertes YAML-Kochbuch fehlt in der Tat, jedoch war das nicht die Intention für mein eigenes Buch.

Bei der Online-Dokumentation besteht definitiv Verbesserungsbedarf. Vorschläge sind immer willkommen, Hilfe ebenso. Allerdings bedarf es dafür eines detailreicheren Feedbacks und weniger einer solch pauschalen Kritik, wenn ich diese ernst nehmen soll. Du bist gern eingeladen zu einer gemütlichen Plauderei am Telefon.

Nochmals, vielen Dank für dein Feedback und zum Schluss noch der kleine Hinweis: Nicht “Jens”, sondern “Dirk”. :-)

@Thomas
Die Argumente bezüglich CCs mögen Dich nicht überzeugen, jedoch sind Deine Argumente keine anderen als die von Jens Meiert, nur Du begründest sie schlechter. Performanceverlust groß oder klein - er ist da. Und deine Position wird nicht glaubwürdiger, wenn Du den Performanceverlust auf CSS-Seite einfach hinnimmst, beim HTML jedoch YAML pauschal als überladene DIV-Suppe bezeichnest.

Den Vorwurf, auf Blähcode zu basieren, haben sich nahezu alle CSS-Frameworks selbst eingehandelt. [...] Vielleicht wäre ein Beispiel ohne DIV überzeugender als zwanzig Artikel?

YAML existiert bereits seit 3 1/2 Jahren und ist seit Version 1.0 auf flexible Layouts ausgelegt. Dass YAML bei einem fixen Einspalter etwas unterfordert ist, unterschreibe ich Dir gern. Bis auf ein Einziges, sind jedoch ALLE Layoutbeispiele bei YAML durchweg flexibel angelegt. Wenn Du flexible Layouts deutlich effektiver umsetzen kannst, dann wäre es an Dir, den Beweis dafür anzutreten, dass ich falsch liege. Ich bemühe mich seit YAML 1.0 um schlanken Code und bin von dem gewählten Ansatz überzeugt. Zudem bin ich durchaus in der Lage, die Effektivität von YAML an an zahlreichen Übungs- und Praxisbeispielen zu belegen.

Ich habe bisher noch kein CSS-Framework angefaßt, [...] weil mir bis heute dunkel bleibt, wie denn eine Aktualisierung vor sich geht.

Nunja, ich komme ehrlich gesagt auch nur leidlich mit TYPO3 klar, weil ich mich bisher mit der Dokumentation von TYPO3 nicht weiter befasst habe. Allerdings halte ich mich aufgrund dessen in der Argumentation bei TYPO3-Diskussionen etwas zurück. In der YAML-Doku steht dann doch etwas mehr zu dem Thema (Stichwort: Regel 4 und der Text daneben). Dazu existieren gerade einmal 32 Layoutbeispiele + ein vollständiges Beispielprojekt, welche die Umsetzung der von YAML propagierten Trennung von Framework- und Nutzer-CSS ganz praktisch verdeutlichen.

Den Vorwurf, auf Blähcode zu basieren, haben sich nahezu alle CSS-Frameworks selbst eingehandelt. Auch in YAML sind die Beispieldokumente klassische DIV-Suppen, die natürlich den ersten Eindruck entscheidend prägen, weil ich als Entwickler erstmal vermute, daß ich das alles selbst wieder herausoperieren muß.
Vielleicht wäre ein Beispiel ohne DIV überzeugender als zwanzig Artikel?

Ich habe bisher noch kein CSS-Framework angefaßt, weil ich dafür einfach keinen Bedarf hatte und weil mir bis heute dunkel bleibt, wie denn eine Aktualisierung vor sich geht. Werden dann meine Anpassungen überschrieben, das Gelöschte wieder eingefügt? Die Dokumentation berührt diesen Punkt nur in einem Absatz, der eigentlich nichts erklärt.

Dennoch: Ein schöner Artikel, der mich zwar (noch) nicht überzeugt aber zum Reflektieren meiner eigenen Arbeitsweise angeregt hat.

Ich denke allerdings, dass YAML eine weit grössere Akzeptanz hätte, wäre der Einstieg darin nicht so beschwerlich. Die Popularität mancher anderen Frameworks lässt sich m.E. damit erklären, dass sie eben leicht durchschau- und lernbar sind.

Für mich stellt sich also die Frage, wie YAML als Konzept so erweitert/modifiziert werden könnte, dass er Komplexität versteckt, anstatt Komplexität sichtbar macht. Der YAML-Builder ist möglicherweise ein Schritt in die richtige Richtung, ich bin mir diesbezüglich aber nicht sicher. Denkbar wäre auch eine Art allgemeine Layout-Grammatik (eine Layout Beschreibungssprache, so etwas wie ein eigenständiges YAML Markup), welche wie eine Skriptsprache den entsprechenden HTML/CSS code erzeugt. Ich hatte neulich einen Entwickler entdeckt, der an so was arbeitet, er hat aber erst damit angefangen.

Der zweite Punkt hat mit der Dokumentation bzw. mit dem YAML-Buch zu tun. Ich habe viel Verständnis dafür, wenn Autoren Ihr Können und Wissen demonstrieren wollen. Leider wirkt sich dieses sehr menschliche Streben auf die Qualität und Transparenz des Buchs aus bzw. wirft es ein schiefes Licht auf das Tool selbst. Ich denke hier wäre wirklich sinnvoll und angebracht, ... über die Bücher zu gehen und sich gründlich zu überlegen, wie man YAML einem breiteren Publikum zugänglich machen könnte. Damit meine ich nicht meine Grossmutter, sondern eben die unzähligen Web-Developers, die von diesem Tool wirklich profitieren könnten, würde man Ihnen den Einstieg erleichtern. Persönlich bin ich überzeugt, dass in diesem Bereich einiges getan werden könnte.

Gruss,
FF

Und mal ehrlich ob Profi oder Anfänger, wichtig ist was hinten rauskommt.

Absolut richtig. Ich habe schon Seiten von “Profis” gesehen, da sollte man sich den Code lieber nicht genauer anschauen.
Ebenso gibt es “Amateure”, die absolut professionelle Arbeit abliefern. Es gibt extreme in beide Richtungen.

Ich habe beim WordCamp Jena schon der Session beigewohnt und da ist dieser Artikel eine gute Erweiterung und Erinnerung. Gerade das Argument der zu großen Dateien kann ich absolut nachvollziehen, da es immer heißt “Wir haben soviel CSS, soviel JS ...” dabei merkt niemand dass man von den größten 100 Portalen noch am wenigsten hat.

Seit ich mich mit YAML beschäftige ist der IE wesentlich erträglicher geworden :-)

Grüße aus der Eifel,
Dominik

man merkt dass du einen hintergund als bauingenieur hast, dementspechend praxisnah ist dein professioneller anspruch.  für viele “fertighauslösungen” ist yaml auch genau das richtige - hohe qualität und sehr pragmatisch.  die codebasis ist soweit ich das beurteilen kann exzellent, und man kann extrem schnell sehr webstandardkonforme seiten erstellen. eben genau richtig für menschen die webdesign als ihr tagesgeschäft verstehen und mit möglichst geringem aufwand erstklassige arbeit machen wollen. aber das geht oft auch mit vorgefertigten und erprobten templates die man nur geringfügig an etwaige layouts anpasst. das ist auch eher die spielwiese von yaml finde ich.

ich glaube auch, dass viele webdesigner inklusive mir fame-whores sind, die sich niemals auf dem code anderer ausruhen würden, und das web auch als künstlerisch-experimentelles medium sehen, das es zu erforschen gilt - und zwar nicht nur präsentationsseitig. ich nutze jedes projekt um neue dinge für die zukunft dazu zu lernen, yaml hört sich für mich stark deutsch, gegenwarts- und praxisorientiert an. eine frage die ich mir z.b. stelle ist: warum muss jede seite in jedem browser möglichst gleich gerendert werden?  - ist das nicht auch eine denkweise die aus analogzeiten kommt?

schwierig.

korbinian

ein sehr schöner Artikel, gut geschrieben!
Ich kann nur sagen, dass ich inzwischen YAML sehr gerne nutze. Obwohl ich mich schon seit fast 10 Jahren mit HTML, CSS & Co. beschäftige und deshalb auch ohne YAML in der Lage war, Browser-Bugs abzufangen und browserübergreifende Layouts zu erstellen, bringt YAML für mich trotzdem eine enorme Arbeitserleichterung. Gleichzeitig bedeutet es aber keine Einschränkung. Bis jetzt konnte ich jedes gewünschte Layout mit YAML umsetzen.

Deshalb: mein Lob und meine Hochachtung vor Dirk Jesses Arbeit! Ich werde die weitere Entwicklung gespannt verfolgen! :)

Ich stimme euch zu, dass eine Entscheidung eines Webentwicklers gegen YAML und co. nicht gleichbedeutend mit der Aussage ist (bzw. sein sollten), dass CSS-Frameworks im Allgemeinen nicht einsatzfähig sind. Einigen schmeckt Tee besser als Kaffee. Einige mögen ihren Kaffee gern pur, die anderen mit Zucker, die anderen mit Milch und noch andere lieber mit Milch und Zucker.

Ich fördere gern den Einsatz von CSS-Frameworks u.a. auch in Technikwürze, wenn oben YAML drüber steht und ich weiß, was für ein „Meisterwerk“ dahinter steckt. Für viele professionelle Webentwickler ist YAML auch sicher eine Arbeitserleichterung. Doch ich sehe meinen Job in Bezug auf HTML und CSS eher darin zu entwickeln (im Beispiel der YAML-Entwickler Dirk; der Stippenzieher), statt zuzuarbeiten (der YAML-Endnutzer, der eine Basis erweitert). Wer jetzt schneller am Ziel ankommt ist mir echt Schnurz. Wichtig ist mir nur, dass mir mein Job Spaß macht. Und dazu gehört es eben auch, auf „Datei neu“ zu klicken.