Anselm, Peter und Stefan stellten mal wieder fest: Webentwicklung ist, als wollte man über 9000 Korken gleichzeitig unter Wasser halten. Und hin und wieder klappt das gar nicht mal so gut.
Schaunotizen
- [00:00:17] CSS außer Rand und Band
- Einem Artikel über CSS-Unit-Tests stehen wir skeptisch gegenüber, erkennen aber an, dass die Menschheit Mittel und Wege sucht, ihr CSS unter Kontrolle zu bekommen. Dieses ist nämlich oft außer Rand und Band. Wir empfehlen als Gegenmittel Systeme wie BEM, klassische Codequalitätssicherungsmaßnahmen wie Reviewprozesse auf CSS anzuwenden, die Finger von Reset-Stylesheets oder Stylesheets wie Normalize.css zu lassen und ausgiebig zu linten. Stefan empfiehlt außerdem CSS-Workshops mit Harry Roberts, der sich durch weit überdurchschnittliche Checkung in diesem Bereich auszeichnet.
- [00:29:44] Our best practices are killing mobile web performance
- Schaden Desktop-Performance-Best-Practices auf Mobile? Zumindest bei Lazy Loading und asynchronem JavaScript sieht es so aus. Generell ist das Aufstellen allgemeingültiger Regeln in einer Welt, in der HTTP2 neben Oldschool-HTTP existiert, nicht ganz einfach. Projekte wie PageSpeed und der SpeedIndex von webpagetest.org (hier von Stefan detailliert erklärt) probieren es trotzdem. Wie wir dann von HighTechWebTech zum Fazit „Make Flash great again“ kommen, verraten wir an dieser Stelle nicht.
[00:53:35] Keine Schaunotizen
- [00:00:00] Learn Redux Video Tutorial Course
- Der umtriebige Wes Bos erklärbärt in einer kleinen Videoserie Redux.
- [00:00:00] Web and Chrome at Google I/O 2016
- Das für Web-Nerds interessanteste von der I/O 2016.
Kommentare
dom #
Geschrieben am 13.06.2016 um 02:40
Diese überspezifischen Monster-CSS sind doch sicher weil jemand Teile der Seite in Sass abgebildet hat, schön 20 Ebenen tief verschachtelt ;-)
Konstantin Peterson #
Geschrieben am 15.06.2016 um 21:05
Ich glaube bei der Diskussion über die CSS Größe und über den Einsatz von Plugins wurde ein wichtiger Faktor/Grund nicht beachtet…das Timing. In einigen Projekten haben Frontend Dev Teams oftmals keine andere Wahl als auf bestehende Plugins zurückzugreifen, denn das Timing für den Livegang einer Website steht oft schon vor Beginn eines Projektes fest und direkt ab Beginn hängt die Zeit einem im Nacken.
Wenn mitten im Projekt festgestellt wird, dass das Timing nicht gehalten werden kann, dann werden meistens die Ressourcen aufgestockt. Also mehr Entwickler … Die neuen Team Mitglieder haben auch nicht wirklich die Zeit die zuvor mühevoll entwickelten Rules/Guidelines durch zu gehen, denn alles muss ganz schnell fertig werden und an Pull-Requests ist dabei auch nicht zu denken. Ein Refactoring ist demnach natürlich auch so gut wie unmöglich. Natürlich können solche kritischen Phasen auch mit Mehrarbeit (Überstunden) überbrückt werden, doch das funktioniert nur für eine gewisse Zeit.
So ein Projektverlauf ist wahrscheinlich nur in einer Agentur vorzufinden, denn dem Kunden ehrlich zu sagen, dass das Timing nicht zu halten ist, wäre natürlich fatal… -.-
Viele Entscheidungen im Verlauf eines solchen Projektes sind stark politisch getrieben und haben indirekt auch eine Auswirkung auf die Code Qualität. Vor allem wenn mehrere Dienstleister an einem Kunden-Projekt arbeiten, herrscht immer ein gewisser Konkurrenzkampf …
Das Szenario, dass Anselm beschrieben hat ist meiner Erfahrung nach nicht der Regelfall und nicht ohne Grund wurde dieses Projekt nicht (wieder) von einer Agentur umgesetzt ;-)
Aus diesem Hintergrund heraus glaube Ich schon, dass es vielen Entwicklern bewusst ist wie es besser geht und was im Projekt falsch gemacht wurde.
Schepp #
Geschrieben am 16.06.2016 um 10:05
Super Kommentar, mit dem ich komplett konform gehe (und es so auch zuhauf erlebt habe). Man muss wirklich immer den Context eines Projekts kennen, bevor man sein Urteil darüber fällen kann.
RSS-Feed zu diesem Beitrag
Kommentare sind für diesen Beitrag geschlossen.