readme 20151205

Ehrlich. Ich will jetzt wirklich wieder regelmäßiger bloggen. Im Hintergrund habe ich meinen Static Website Generator erfolgreich vom Blog abgekapselt und will nun in den nächsten Wochen die nächste Stufe auf der Website zünden.

U.a. will ich mit „readme“ regelmäßig die Links und sonstiges Material posten, die ich lese.

readme 20151205

  • Rebecca Murphey: „Building for HTTP/2” – Der Blogeintrag verdeutlicht vor allem eines: über die Einbindung von HTTP/2 in den Webentwicklungs-Workflow, wird noch länger diskutiert werden müssen. Ganz so klar scheint die Frage, wie man Module und Assets einbindet (als Bundle in einer Datei vs. getrennt in vielen Modulen) noch nicht zu sein, wenn man z.B. gegen Murpheys Blogeintrag, den Blogeintrag von Craig Silverstein gegen hält. Also warten bis Einigkeit über „Best Practice“ besteht.
  • Eric Elliott: „Must See JavaScript Dev Tools That Put Other Dev Tools to Shame“ – Hinter dem clickbaiting-verdächtigen Titel verbirgt sich ein Blogeintrag, der einige Tools und Bibliotheken auflistet, die Elliott verwendet. Ich lese solches Zeug immer wieder gerne durch, um mich inspirieren zu lassen. In diesem Fall ist es für mich der Trigger, um mir traceGL und ironnode als Debugging-Tools näher anzuschauen.
  • Patrick Ewers: „Six Friction-Free Ways to Help Your Network Help You“ – Wie der Titel schon sagt: sechs Ideen zum besseren Networking. Für eher Introvertierte wie mich, immer wieder ein Ansporn sowas auszutesten, zumal ich in meinem Job massiv davon profitieren könnte.
  • Ben Frain: „Enduring CSS“ – Ben Frain hat als Senior Frontend Developer bei bet365.com eine neue CSS-Methodologie entwickelt und stellt ECSS („Enduring CSS“) mit Slides vor.

Noch'n Wort zu ECSS von Ben Frain. Rahmenbedingungen für Ben Frains ECSS war die Arbeit in Large-Scale-Projekten und die daraus sich ergebenden Probleme rund um eine große Codebasis, die stets verändert und erweitert werden soll, aber dabei an Konsistenz behalten und Redundanzen vermeiden soll. Stichworte sind „Decoupling“ durch Kapselung in Namespaces und flache Hierachien.

Drei Punkte haben mich an der Präsentation bzw. ECSS gestört. Die File Organisation war etwas eigen. Das HTML, CSS und JS waren nicht mehr jeweils in html-, css- und js-Verzeichnissen zusammengefasst, sondern modulweise gebundlest. Also z.B. das HTML, CSS und JS für ein Kalenderwidget in ein Verzeichnis calendar gepackt. Ich verstehe den Gedanken dahinter. Ich bin aber nicht überzeugt, dass diese Struktur in jedem Projekt ideal ist – sowohl hinsichtlich von Änderungen, als auch der Integration in Backend-Umgebungen.

Statt des Ablegens von Status in Elementen per classes wie is-disabled, nutzt ECSS ARIA-Attribute wie aria-disabled="true". Ich bin gebranntes Kind was Accessibility angeht und mein Credo ist in dem Bereich: je weniger du zusätzliche Accessibility-Attribute anfassen musst, desto besser. Die Art und Weise wie ECSS die ARIA-Attribute verwenden will, grenzt für mich an Mißbrauch. IMHO ganz heikles Gebiet.

Der dritte Punkt der mir aufgestossen ist, ist die Kritik an @extend, die ich für zu undifferenziert halte.