Jens Oliver Meiert
01.11.2018 Jens Oliver Meiert, Frontend

Eindrücke von der Fronteers-Konferenz 2018

Ein Teilnehmer und elf Zusammenfassungen

Anfang Oktober war wieder Konferenzzeit bei sum.cumo. Diesmal wollten drei unserer Mitarbeiter auf der Fronteers-Konferenz 2018 in Amsterdam aufschlagen – so der Plan. Einer unzuverlässigen Airline sei Dank landete am Ende jedoch nur Jens in Amsterdam. Mitgebracht hat er uns ein paar seiner Notizen und ein Fazit zum Gesamteindruck über die zwei Tage in Amsterdam.

Dieser Beitrag spiegelt entsprechend Jens’ eigene Filter wieder, und er ist dank der einfachen Notizen etwas nüchtern. Das steht im Kontrast zur Konferenz, für die wenigstens drei Fotos beiliegen – die offiziellen Fotos liefern weitere Impressionen.

Gleich zu Beginn ein Fazit: Fronteers 2018 war perfekt organisiert und es gab für jeden etwas zum Mitnehmen. Persönlich hätte ich (Jens) mir vom Moderator gewünscht, Publikum und speziell Sprecher mehr in den Vordergrund zu stellen; ich habe mich gefragt, ob man einer Menge guter Leute wirklich suggerieren muss, sie wären keine „anständigen Menschen“; und ich war skeptisch, ob das Web (oder die Welt?) wirklich, wie hin und wieder im Laufe der Veranstaltung angedeutet, lediglich eine Angelegenheit billiger Psychologie und leichter Manipulation sei (ja zu Skepsis, nein zu Paranoia bitte). Insgesamt aber wird für uns bei sum.cumo die Fronteers sicher wieder eine Reise wert sein – hoffentlich mit etwas mehr Glück, um mit einem größeren Teil unseres Teams vertreten zu sein.

Aber nun Notizen zu den einzelnen Vorträgen, sortiert nach Rednern.

John Wilander: Die Storage Access API ist einen Blick wert. Cookies mögen im Set-Cookie-Header gerne als Secure markiert werden. Skripte von Dritten sind aus Datenschutz- und Sicherheitssicht am schlimmsten – es ist empfehlenswert, auf Subresource Integrity durch @integrity zu setzen (mit entsprechendem Fallback auf dem eigenen Server). Iframes sollten mittels @sandbox „gesandboxed“ werden. Wieder auf dem Server, Referrer-Policy sollte gesetzt werden und Set-Cookie um HttpOnly und SameSite ergänzt werden (analog zum bereits erwähnten Secure).

John Wilander @ Fronteers 2018
John Wilander über intelligente Tracking-Umgehung.

Laura Carvajal: Bitte nicht vergessen, dass genauso wie der Cursor wichtig für Navigation mit der Maus ist, die Outline wichtig für Navigation mit der Tastatur ist. :focus-visible sollte nebst Polyfills Beachtung finden. Websites sollten immer auch ohne Maus getestet werden (Maladien können über tabindex=0 gelindert werden). Daran denken, dass Screenreader-Nutzer oftmals über Überschriften navigieren. Nur eine <h1> verwenden [Ausnahmen bestätigen die Regel]. Bei Komponenten können Überschriften-Ebenen auch an die entsprechende Komponente weitergereicht werden, wodurch die Überschriftenebene zur Sache des Kontexts gemacht werden kann. Bei Videos sind Untertitel „nicht optional“. Browser-Defaults sind hilfreich. Es ist nützlich, Barrierefreiheitstests (wie pa11y) zu Tests und Builds hinzufügen – und Builds notfalls auch scheitern zu lassen, wenn es darum geht, zugängliche Entwicklung anzuschieben.

Heydon Pickering: „Inclusive Design“ heißt nicht, jedem dieselbe Nutzererfahrung zu bieten, sondern jedem eine „not shit“-Erfahrung zu ermöglichen. „Messbar“ ist nicht gleichzusetzen mit „relevant“. Vielleicht mal einen Blick auf inclusive-components.design werfen.

Stefan Judis (Folien): Den „Abstract Syntax Tree (AST) Explorer“ beachten. Den „Vue Template Explorer“ ebenfalls. Dazu die snabbdom-Bibliothek für das virtuelle DOM. „In Code gibt es keine Magie.“

Eva Ferreira (Folien): Es gibt viele Mythen um Barrierefreiheit, von „das betrifft nur blinde Menschen“ bis hin zu „ist schädlich für Performance“. Outlines sollten nicht ersatzlos entfernt werden. @hidden und @aria-hidden im Kopf behalten. Es ist wichtig, auf die Tab-Reihenfolge zu achten (besonders mit Flex). Auf (DOM-)Semantik sollte ebenfalls geachtet werden (Beispiel: display: contents). Es gibt einen CSS-Entwurf für eine prefers-reduced-motion-Media-Query. Farben invertieren behebt keine Probleme mit schlechtem Kontrast.

Mathias Bynens (Folien): „Der schnellste Code ist der, den man nicht ausliefern muss.“ Gutes Verständnis von „Elements Kinds“ ist nützlich: packed („gepackte“) smi-, double-, regular-, dann holey („löchrige“) smi-, double-, regular-Arrays. Es ist wichtig, zu verstehen, dass Array-Löcher ein Problem sind („packed > holey“, „wenn’s geht, vermeiden“). Für die Engine ist es teuer, die ganze Prototypkette hochzulaufen und zu bestimmen, ob etwas „undefined“ ist. V8 kennt 20 verschiedene Elements-Arten, alle mit unterschiedlichen Optimierungen. V8 kann mit gepackten Arrays am besten umgehen („verwenden Sie die möglichst spezifische Elements-Kinds“). Sobald ein Array als „holey“ markiert wird, bleibt es holey – es ist entsprechend empfehlenswert, mit den Elementen zu starten, die man kennt, und diese in das Array zu schreiben (dennoch kommt es darauf an, denn new Array(n) kann für schnelle Array-Kreiierung immer noch zu bevorzugen sein). Die Performance von for-Lops (klassisches for, for/of, forEach) ist nicht mehr wichtig. Elements-Arten können in V8 mit %DebugPrint() getestet werden. „Schreiben Sie modernes, idiomatisches JavaScript, und lassen Sie die JavaScript-Engine sich [um alle Optimierungen kümmern].“

Mathias Bynens @ Fronteers 2018
Mathias Bynens zu V8-Innereien.

Estelle Weyl (Folien): Es gibt einen Unterschied zwischen Coding und Engineering – Coding bedeutet, anderer Leute Technologien einzusetzen (Frameworks &c.), Engineering heißt, Kerntechnologien zu verstehen und einzusetzen (mitsamt etwas Empathie und guter Kommunikation). Natives HTML verwenden, DOM minimieren. Man sollte seine Werkzeuge beherrschen (anstatt andersrum). Es ist wichtig, zu verstehen, dass Tooling etwas zur Developer Experience beiträgt. Videos sollten ausgelassen werden, andernfalls komprimiert, ihre Source-Reihenfolge optimiert und stummgeschaltetes Audio entfernt werden. Es gibt keine „Ladezeit“ (welche Zeit auf was für einem Gerät?). Bei Performance-Audits sollte auf den „Long Tail“ und Ausreißer geachtet werden. Die Wahrnehmung von Performance ist immer noch subjektiv. Ladeblockierung durch Skripte ist ein großes Problem (bei Stylesheets nicht im selben Maße). Internet-Verbindungen sind immer schneller geworden aber Payloads sind genauso gewachsen – und zwar unkomprimiert. „RDD = Resume-Driven Development“, lebenslaufgetriebene Entwicklung. JavaScript-Bytes != andere Bytes, weil JavaScript blockieren kann und schwieriger handzuhaben ist als bspw. Bilddekodierung. Tipps: JavaScript reduzieren und minimieren, Bibliotheken hinterfragen. 100 ms Antwortzeit anstreben. Es ist wichtig, sich die Zeit zu nehmen, gleich hochwertig zu entwickeln (anstatt auf spätere Refactorings zu setzen).

Estelle Weyl @ Fronteers 2018
Estelle Weyl zu CSS.

Kenneth R. Christiansen (Folien): Mal einen Blick auf Web Bluetooth (navigator.bluetooth.requestDevice()) und Web USB werfen. Genauso auf Motion Sensors und die Shape Detection API.

Ruth John: Es gibt eine Web Midi API.

Paul Verbeek-Mast (Folien): „Fragen Sie sich, wieviel Schaden Sie [mit Ihrer App oder Ihrem Dienst] anrichten können.“ Entwickler sollten verantwortungsbewusst und ethisch handeln, und unethische Arbeit ablehnen (und diese ggf. melden). „Denken Sie über ethische Implikationen nach.“ Es gibt einige ethische Frameworks, wie z.B. das der ICAEW.

Chris Lilley: Es ist wichtig, den Unterschied zwischen Zeichen („Zahl“ [Code Point]) und Glyphe zu kennen. (Die „fi“-Ligatur als zwei Zahlen und eine Glyphe.) Ebenso relevant ist der Unterschied zwischen Font-Deskriptoren und -Eigenschaften (Schriftfähigkeiten vs. was von einer Schrift verlangt wird). „Es gibt keine ‚web-safe‘ Schriften.“ Für jedes Zeichen wird die erste Schrift verwendet, die dafür eine Glyphe besitzt. unicode-range sollte nicht vergessen werden. Variable Schriften arbeiten mit Variationsachsen (ital, opsz, slnt, wdth, wght). CSS Fonts passt die font-weight-Eigenschaft so an, dass diese Werte bis 999 akzeptiert (und calc() zulässt). (Variable Schriften arbeiten mit Glyphensubstitution, was bedeutet, dass bei bestimmten Schriftgrößen Glyphen ausgetauscht werden können.) Farbige Schriften funktionieren. font-palette, @font-palette-values, font-variant-numeric, font-synthesis, font-kerning beachten. Ebenso – wakamaifondue.com.