Notes from Web Directions Code 2018
About a month ago now, I attended Web Directions Code at Arts Centre Melbourne, which is described as a conference for JavaScript Developers and Front End Engineers, but I think anyone working across web technology stacks would get a lot out of it. John Allsopp curates a wide ranging conference with each block addressing a different part of the web, from new CSS features and developments in browser technology, to back-to-basics (or fundamentals) of HTML and accessibility, to emerging JavaScript techniques. It’s a jam-packed couple of days of talks, and the speakers were exceptional — overall a very inspiring conference, and I filled up half a notebook with notes of things to read and investigate over the next 12 months before the next conference!
Here are some of my highlights:
Opening the conference, Sara Soueidan spoke about CSS, SVG and accessibility. She described inclusive design as a subset of responsive design, quoting Eric Bailey, “Responsive Design is adapting design to an unknown browser. Inclusive design is adapting design to an unknown user.” Her talk was an excellent mix of showcasing new technologies within the context of providing better accessibility — a big contrast to the familiar theme of new technologies at the expense of accessibility. Highlights included a low barrier to entry approach for providing high contrast or alternate themes by using CSS variables. The approach is to define colour variables in the root pseudo class :root and then inherit this variable anywhere that colour is used. To create a different theme, you can set a class or attribute on the HTML element, and use this to switch out the variable for colour, instead of relying on separate stylesheets for different themes. The ability to use live CSS variables for colours and font sizing is particularly powerful when paired with the calc() function. You could set a base font size at the root, and then have all other sizings and scaling ratios calculated from that base size. You could then create a simple way of allowing users to change text size by setting text-size buttons to change that parent font-size variable. She also pointed out that animation can assist with accessibility and usability, referencing Val Head’s book Designing Interface Animation — but that if you’re pursuing lots of animation you should look into using User queries like prefers-reduced-motion, which allows you to switch off animations if a user has set their device accordingly. This feature is only on iOS currently, but a theme throughout the conference was to really look at how you can improve the experience for all users, which does mean providing enhancements, even if support is fairly specific to a platform or browser. And speaking of specific platforms, Sara walked through how to work with Microsoft’s high contrast mode, using system color keywords. But my favourite part of the talk was how she demonstrated using HSL-based colours to provide tones that are generated from a particular hue. The final piece of the puzzle is to use inline SVG for icons, so that icon colours can be swapped out based on the colour calculations, too.
Next up, Erin Zimmer went into great depth explaining the JavaScript event loop, and how a single-threaded language manages asynchronous tasks. This was an illuminating and energetic talk, and the highlights for me were:
- If you’re animating something, use requestAnimationFrame so that your logic only fires once per rendered frame (instead of trying to guess it with setTimeout)
- Try to compose your logic in very small tasks. If you go over your budget of approximately 10ms (if browser overhead is usually around 6ms) then each cycle of the event loop will take longer than 16ms, making the browser dip below 60fps, resulting in jank.
- For tasks that might take longer to process, use web workers to run a script in the background. This will result in the worker running its code in a separate event loop on a different thread, without blocking the main thread and affecting frame rate.
Simon Knox from Gitlab talked about optimistic offline experiences, giving heaps of examples of real world situations where websites need to deal with going offline, from the moment you walk from a WiFi hotspot (like your house) to cellular data, to going through a tunnel on a train, to patchy Australian internet connections. He contextualised the offline web as being “real life” as opposed to just when you’re on a plane. A good example of offline-first websites is Ethan Marcotte’s blog, where key posts are stored in the browser using the Cache API, and if you go offline, you can still read a decent amount of the website, with images falling back to placeholders. The service worker JS file for that site is well worth a look.
A more advanced example was Trivago, where the offline mode disables form submit fields, to prevent a user from attempting to complete a hotel booking when their internet connection isn’t available.
The key to good offline experiences, then, is to cache the most relevant content for users by using the service worker API, disable submit fields on transactional paths when internet isn’t available (but still attempt to reconnect so the user can complete the transaction when they’re back online), and provide a good, usable initial load of the page from cache, that gets refreshed after the initial page load (think Twitter’s timeline, where the shell of the site is flushed with new content once the site has loaded).
This talk really gave me the impression that strong offline support is now a core component of what we expect of web apps (often without realising it), and as soon as it’s pointed out, you notice it everywhere from Slack to Google Docs, where the interface is so usable in offline mode, there isn’t even a big alert:
Phil Nash of Twilio talked about Aggressive Web Apps, and the importance of providing context when requesting a user’s permission to use features like Geolocation or Notification APIs. His main point is that requests for push notifications, location, or e-mail signups are irritating or aggressive when asked without context. However, in the right context, such as on the confirmation page of booking a flight, asking the user if they would like to receive push notifications can be appropriate and even desirable. His suggestion is to always put the request behind a user interaction, and always within the context of something that the user wants to do, not what you want the user to do. Asking for the user’s location makes sense when the web app is a map, but might seem aggressive if the site is a magazine-style set of articles. My main take away is that if you’re going to pursue push notifications, they should be timely, actionable and personal, and we should make it easy for users to opt out.
Chen Hui Jing did a wonderful presentation called New Frontiers of Web Design, and also posted her presentation online, covering CSS Grid, vertical text orientation, recreating magazine layouts in CSS, and using CSS shapes to wrap text around non-rectangular areas (common to magazine layouts). In her talk, she encouraged embracing the creativity the web allows, and being bold in trying out new CSS features. In this regard, she said that progressive enhancement is more important than ever. While features like CSS shapes have good (but not great) browser support, it’s entirely possible to design your sites using commonly supported features, and add in things like CSS shapes as an enhancement behind @supports queries. And for side-projects or greenfield projects where limited browser support is more acceptable, we can be freer to experiment. It was also great to see so many presentations throughout the conference running in HTML (in Hui Jing’s case, reveal.js), with demos using Codepen. Hui Jing posts a lot of her experiments publicly from a responsive vertical slider that maintains aspect-ratio using viewport min/max to explaining how clip-path works using photos of Beyonce. Her emphasis on playfully experimenting with web technologies was so refreshing, and my favourite quote of hers was from a demo of clip-path: “Interactive Beyonce spotlights on your website, that’s what’s possible.”
Continuing on with the theme of creativity, Xavier Ho did an inspiring talk on generative art. In contrast to software development processes of gathering functional requirements, acceptance tests and developing engineering standards, in generative art, it’s a process of trial and error, of experimenting until something ‘looks good’. His experiments were mesmerising:
Xavier also posted his slides online, with live demos of his experiments:
I really can’t do the presentation justice in a post, but suffice to say that heaps of us felt inspired to go off and make our own experiments. The starting place is to use the Canvas API to iteratively draw things based on a random number, using simple algorithms and arithmetic to create complex patterns. Like Xavier said in his talk, the objective isn’t to make something that’s correct, but to play with values until you create something pleasing. I don’t really know what Hilbert curve, L-system or Penrose tiling are, but Xavier was encouraging: for making generative art, it doesn’t really matter at first, what matters is having a play with all the tools and algorithms other people have already come up with and shared in their work and papers.
Patima Tantiprasut spoke about becoming a better developer (and a better person). She described better devs as:
- Are slow
- Don’t work long hours – leave on time
- Avoid hard work
- Write bad code
- Enjoy friction
Broadly, she deconstructed the idea of always being busy to get ahead and improve, and instead said to focus on being open, collaborative, setting a good example for work/life balance, and contributing actively to a team in a sustainable way. Positive friction comes from having conversations that go into the “whys”, and writing bad code enables discussion into how to write better code as a team, instead of trying to attain perfectionism as an individual.
And in modelling good behaviour for avoiding burnout, she encouraged leaving on time, thinking of overtime as an organisational anti-pattern, working sensible hours even if you’re a remote worker, and spending time on non-coding hobbies. The important quote for me was, “You can’t pay back sleep debt with naps.”
The talk generated a lot of discussion, and someone on Twitter said it reminded them of this tweet from Sarah Drasner:
Other highlights from the conference included Mandy Michael talking about the importance of semantic HTML for screen readers, but also that focusing on semantics and structured data is good for all users and getting your content recognised properly by Instapaper and other aggregators. There was a talk on Atlassian’s enormous JS code bases and the importance of ESLint and Prettier for making the code feel like it was written by a single person.
Isabel Brison spoke of the complexities of dealing with design systems at Fairfax (style guides + pattern libraries), and that in small teams the pragmatic approach is to document as you go and build the pattern library as you make components, rather than trying to do it all at upfront. But it does mean that the reality of working with atoms, molecules and organisms of layout and templates is a lot messier than you would expect and tech debt accrues rapidly. She suggested to keep React components simple to avoid “questioning your life choices” and to “document the shit out of everything, all the decisions, especially what you think is obvious.” They’ve shared their style guide for AFR publicly on Github Pages. In this case they used Jekyll to build static pages for the style guide, but there was a fair bit of talk about Storybook at the conference, particularly for React projects. One of the important points of the talk though was that a design system should survive past the life of frameworks, so static site generators like Jekyll and Gatsby are a good choice.
There was a good talk on GraphQL from the folks at Meteor, looking at the Apollo client and server. GraphQL is now popular with frontend projects so that you can query the data you need for a view once, without having to do all the multiple calls involved in complex REST APIs. Their solution for existing backend projects is to treat GraphQL as a gateway for a REST API or SQL queries, and have your GraphQL server sit between a traditional monolithic API and your front end code. This allows gradual adoption instead of having to go all-in at once.
Rounding out the conference, Jason O’Neil demoed the current state of browser support for speech recognition and synthesis, opening up the future promise of open web standards alternatives to the gated communities of Google Home and Amazon Alexa – the idea that you can speak and interact with a website aurally, allowing for better (or sometimes amusingly inaccurate) interfaces for all users.
Marcos Cáceres of Mozilla gave an update on the state of web authentication, and the Credentials API with the long-term goal of websites being able to use federated logins, allowing for “silent logins”, avoiding the typical expired session / login page flow of websites, with better support for things like fingerprint scanners and Yubikeys. While this is an emerging technology and can’t yet be used in production, in the meantime we should all be using autocomplete attributes for username and password fields to help browsers and password managers pre-fill forms quickly for users.
Maximiliano Firtman, author of High Performance Mobile Web, closed the conference with a deep dive on the complexities of browser support for Progressive Web Apps and the dangers of quickly adopting new technologies without proper testing and consideration of user flows. For example, iOS Safari’s implementation of PWAs doesn’t persist state when you open or close the app. This means that if you save Twitter to your home screen, open it in its app-mode, and have 2FA enabled, when you go to log in, you can’t leave the app and get the code from a text message and go back in to complete the sign up. When you re-open the app, it reloads to the root page, and forgets the login attempt. Trying to log in again triggers a new code. The solution for developers is to get your web app to always store the last accessed page, and redirect the user whenever they access the app. Aside from these sorts of issues on individual browsers, support for PWAs is strong across all browsers now, and desktop on Chromebooks and Windows 10. The sheer range of environments for us to test our sites on is ever growing, but this talk was a great reminder that we should be embracing this new technology, and at the same time take care that we’re doing so while actually making better experiences for our users.
There was still a lot more that I haven’t covered here, but the range of talks really captured what felt like the breadth of the front end web today, with a lot of promise of exciting things to come. The next step for me I think will be to pick up a copy of Jeremy Keith’s book Going Offline, and after that, take a look at Val Head’s Designing Interface Animation.
