Impressions from Fronteers Conference 2018

One attendee and eleven summaries

The beginning of October marked “conference time” at sum.cumo. Three of our employees were to attend Fronteers Conference 2018 in Amsterdam – that was the plan. Thanks to an unreliable airline only Jens ended up in Amsterdam. He brought us a few of his notes and a summary of the overall impression of the two days he spent at the conference.

This post is subjective when it comes to Jens’s filters and also sober given that it originates in a set of brief notes; that is opposed to the conference itself, then and therefore three photos shall complement all the note-y text. Those who feel the need for more visual impulse, please check out the official photo set.

Let’s start with the conclusion: Fronteers 2018 was perfectly organized and there was much to take away. Personally, I (Jens) would have appreciated if the facilitator had taken more opportunities to honor the audience and let the speakers shine; I wondered whether for a crowd of great people, a conference really has to suggest people were not “decent human beings”; and I was concerned about the occasional suggestion that the Web (or the World?) was a mere matter of cheap psychology and easy manipulation (yes to skepticism but no to paranoia, please). Yet overall, for us at sum.cumo, Fronteers will be worth another visit – hopefully with more luck again so to be present with a bigger part of our team.

Here, now, notes on the different talks, ordered by speakers.

John Wilander: Have a look at the Storage Access API. Mark cookies as Secure in Set-Cookie header. Note that loading scripts from third parties is worst from a privacy and security perspective – use subresource integrity through @integrity (with fallback of respective files on own server). Sandbox iframes with @sandbox. On the server again, set Referrer-Policy, add HttpOnly and SameSite to Set-Cookie (just like Secure as mentioned).

Laura Carvajal: Remember that just as the cursor is important for mouse navigation, outline is important for keyboard navigation. Have a look at :focus-visible and respective polyfills. Make sure to always test your site without a mouse (implement remedies with tabindex=0 if necessary). Note that “screen reader users will generally navigate by headings first.” Use only one h1 [exceptions prove the rule]. With components, consider passing heading levels into respective components, thereby making the heading level responsibility of the context. Note that for videos, “captions aren’t optional.” Remember that “browser defaults go a long way.” Add accessibility checks (like pa11y) to tests and builds – and have builds break if necessary, to do more for accessibility.

Heydon Pickering: Remember that inclusive design does not mean giving everyone the same experience, but giving everyone a “not shit” experience. Note that “measurable !== matters”. Check out inclusive-components.design.

Stefan Judis (Slides): Note Abstract Syntax Tree (AST) Explorer. Have a look at the Vue Template Explorer, too. Check out the snabbdom virtual DOM library. “There is no magic in code.”

Eva Ferreira (Slides): Know that there are a lot of myths around accessibility, whether that it would just be about blind people or that it impaired performance. Don’t delete outlines unless you replace them. Consider using @hidden and @aria-hidden. Pay attention to tab order (especially with flex). Always check (DOM) semantics (example: display: contents). Note CSS draft for prefers-reduced-motion media query. Keep in mind that inverting colors doesn’t fix bad contrast.

Mathias Bynens (Slides): Remember that “the fastest code is the one you don’t need to ship.” Understand elements kinds: packed smi, double, regular, then holey smi, double, regular. Understand that array holes are a problem (“packed > holey”, “avoid where you can”). Note that it’s expensive for the engine to walk up the prototype chain and determine that something is “undefined”. Note that V8 knows 20 different elements kinds, all with different optimizations and that V8 can deal much better with packed arrays (“use the most specific elements kind”). Note that once an array is marked “holey,” it stays holey – it’s much better to start with the elements you know and push to the array (though new Array(n) can still be useful, e.g. for optimized array creation… after all, it’s a tradeoff). Know that the performance in for loops (classical for, for/of, forEach) is not important anymore. Elements kinds are testable in V8 with %DebugPrint(). “Write modern, idiomatic JavaScript and let the JavaScript engine [handle the optimizations] for you.”

Estelle Weyl (Slides): Differentiate between coding and engineering – coding is using other people’s technology (frameworks &c.), engineering is understanding and using core technologies (plus some empathy and good communication). Use native HTML, minimize the DOM. Control your tools (not the other way around). Note that tooling is part of the developer experience. For videos, leave them out, otherwise compress, optimize source order, remove muted audio. Remember that there’s no such thing as load time (what time and on what device?). Look at long tail and outliers in performance audits. Remember that the perception of performance is subjective. Scripts blocking is a major problem (not so much with style sheets). Note that internet connections got faster but payload grew as much – uncompressed. “RDD = Resume-Driven Development.” JavaScript bytes != other bytes, because JavaScript is blocking and more difficult than, say, image decoding. Tips: Reduce JavaScript, minimize JavaScript, question libraries. Aim for 100 ms response time. Take the time to develop right the first time (instead of refactoring).

Kenneth R. Christiansen (Slides): Check out Web Bluetooth (navigator.bluetooth.requestDevice()) and Web USB. Also Motion Sensors and the Shape Detection API.

Ruth John: Check out the Web Midi API.

Paul Verbeek-Mast (Slides): “Think about how much harm you can do [with your app or service].” As developers, be reasonable, i.e. ethical and don’t do unethical work (report it instead). “Think about ethical implications.” Check out ethical frameworks, like that of the ICAEW.

Chris Lilley: Know character (“number“ [code point]) and glyph. (Observe the “fi” ligature as two numbers and one glyph.) Know font descriptors vs. properties (font capabilities vs. what’s wanted from a font). “There’s no such thing like a web-safe font.” Understand that the first font with glyphs for a given character is used. Remember unicode-range. Know that variable fonts work with registered variation axes (ital, opsz, slnt, wdth, wght). CSS Fonts changes font-weight to take values up to 999 (and allow calc()). (Variable fonts work with glyph substitution, that is at certain sizes the glyphs may be swapped.) Color fonts work. Check out font-palette, @font-palette-values, font-variant-numeric, font-synthesis, font-kerning. Also check out – wakamaifondue.com.