Finch Front-End Day 1 Write-Up: Layout, Optimisation, and Organisation
Tags: frontend, webdev, finchconf, css
Published: 2019-09-27 08:19:56

---
title: Finch Front-End Day 1 Write-Up: Layout, Optimisation, and Organisation
published: true
description: Notes and thoughts from Finch Front-End conference's first day dedicated to Layout, Optimisation, and Organisation. Featuring talks by @adactio, @rachelandrew, @csswizardry, and others.
tags: frontend, webdev, finchconf, css
---

Last month, I was fortunate enough to receive a free diversity ticket to one of the days of #FinchConf, a front-end conference held in Edinburgh. I've chosen to attend day one, focused on _Layout, Optimisation, and Organisation_. Here are my notes.


## Jeremy Keith <small>(probably more famous as @adactio)</small> on Going Offline

The web has come a long way. Websites used to be static pages, which changed with the rise of JavaScript and then AJAX (which actually stands for _Ask Jeremy About XML_, true story). After we started doing stuff in JS, over time some of the things like `:hover` actually came down to declarative HTML/CSS languages, leaving JS for something more fun. 

(And look where it led us. If twenty-aughts were all about “lets use more JS”, 2019 is more like “can we _please_ tone it down with JS already”.)

We had a couple of paradigm shifts along the way, too. One came with jQuery, which ultimately changed the way we manipulate the DOM. The other might be coming now, with the rise of service workers. 

Jeremy described **service worker** (SW) as a **“man-in-the-middle attack on your own website”**, which I think is quite brilliant. Indeed, after SW is installed on a device, it acts as an interceptor for network calls, which allows us to do all kinds of things like re-routing a request from going all the way to the server to look in cache at hand instead.

Considering we now have two possible sources - remote server and local cache, - there can be different strategies for implementing service workers:
- _Cache first_, which basically means “if you have a resource saved in cache, use it, and skip the network call”;
- _Network first_, or “try fetching the resource from server first, and if something goes wrong, get it from cache, or if you don't have it in cache, _show a specifically designed offline page_”.

Which one to use is up to you. Think about what content are you working with: most likely, styles can be cached, but a list of available products has to be fresh. We also don't have to decide everything for ourselves, and can offer choice to _save the content for offline use_ to the user, as Sara Soueidan does on [articles](https://www.sarasoueidan.com/blog/) on her website.

Jeremy showed how easy it is to start using service workers. If you understand the **general logic**, you can implement them. There is no need for fancy frameworks or libraries, a couple of lines of JavaScript will do the trick. Throw in a manifest, which is a simple JSON file — and you have a PWA. You don't need to have a “web app” for this to work: having a _website_ is perfectly fine.
 


## Rachel Andrew <small>(no, seriously, _the_ Rachel Andrew)</small> on CSS Layouts

If there's a motto for CSS Working Group, it's this: We can't break the web. No, really, we can't. We have to make sure every website, no matter how old, still works as expected after spec changes.

That's one of the reasons why spec writing is hard.

And yet, we still have a lot of new things in CSS, the biggest ones being, of course, flexbox and Grid. 

If you think Rachel gave a once and for all answer to “should I use flex or should I use grid” question, you're wrong. Instead, she asked: “Well, does it work?”, and proceeded with an in-depth explanation of block formatting contexts (every time you set `display` property, you create a new [block formatting context](https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Block_formatting_context)), two-value `display` properties (when you say `display: grid`, what you are _really_ saying is `display: block grid`, first value for container, the second value for its children), and logical dimensions (`width` and `height` don't make much sense if document flow goes from right to left, do they?).

Rachel’s talk was _packed_ with information. If you want to learn more about this, here are some articles by Rachel herself to dig into: 
- [Understanding Logical Properties and Values](https://www.smashingmagazine.com/2018/03/understanding-logical-properties-values/)
- [Digging Into The Display Property](https://www.smashingmagazine.com/2019/04/display-two-value/) series



## David Khourshid on Stateful Styles

{% twitter 1168297572383019009 %}

Personally, I almost never get _all_ the designs from UI department. A button or a link will most probably only have two states: regular and `:hover`; it's rare when `:focus` and `:active` are also provided. Every single link or button on the web have these states, and yet they are still forgotten. But your website or app can have a lot of custom states as well, eg “Fetching information from back-end” state, or “Loading” state, or “Success” state, or “Error” state. 

That's a lot of states.

David talked about how using _finite state machines and statecharts_ can make life easier for everyone involved. Business will have a clear overview of application flows, designers will know what screens are missing, developers will know what to implement.

David suggests to start development in old-fashioned way: with pencil and a piece of paper, in order to draw _statechart_ for the app. It will define _which states the app can be in_, and _what events can lead to transition between different states_. 

In code, the diagram can be represented as a simple object.

```js
const machine = {
  initial: 'idle',
  states: {
    idle: {
      on: {
        CLICK: 'loading'
      }
    },
    loading: {
      on: {
        RESOLVE: 'success',
        REJECT: 'error',
      }
    },
    success: {
      on: {
        CLICK: 'loading'
      }
    },
    error: {
      on: {
        CLICK: 'loading'
      }
    }
  }
};
```

Getting the next state then is as easy as getting the value from this object: 

```js
const transition = (state, event) => {
  return machine
    .states[state]
    .on[event]
    || state;
}
```

To tie JavaScript and CSS, David suggests using `data-*` attributes instead of classes. Not only they are _designed_ to hold custom application data, but they are also easy to manipulate via JS and fully accessible in CSS.

If this topic if something you find interesting and want to dig deeper into, here are some links: 
- David's [XState library](https://xstate.js.org/);
- [Statecharts: A Visual Formalism For Complex Systems](http://www.inf.ed.ac.uk/teaching/courses/seoc/2005_2006/resources/statecharts.pdf) by David Harel;
- [Pure UI](https://rauchg.com/2015/pure-ui), by Guillermo Rauch.


## Chen Hui Jing on Devtools and Using Them to Understand and Learn Modern CSS

Modern CSS can be hard to bend your mind around when reading about it. We have a whole new layout system built-in now, and with it a whole bunch of new units, and the only way to really grasp it all is to play around with it - and here's where browser's devtools can help, showing the layout and the computed values for any selected element.

Hui Jing's slides for Finch are not up yet, but you can poke around their [slides for ConnectFest](https://www.chenhuijing.com/slides/65-connectfest-2019/) or [examples for _Examining “squishiness” in Intrinsic Web Design_ article](https://blog.logrocket.com/examining-squishiness-in-intrinsic-web-design-1005d30dda0c/) - and when I say “poke”, I mean “inspect different elements while resizing browser window like a hundred times to see how different values of different properties behave in different screen sizes, eg observe the difference between `auto-fill` and `auto-fit` (spoiler: the first one preserves space for empty “imaginary” columns while the second doesn't), and click on everything you haven't ever clicked on in devtools in browser of your choice”.



## Harry Roberts on Those Small Properties You Can Add to Resource Links in `<head>` to Make Page Faster

Not much to add there. [Resource hints](https://www.w3.org/TR/resource-hints/) are a simple thing to implement, and they make page faster, - use them.



## Léonie Watson on Talking Technology

Screen reader users rely on machines to read out content, and the result is... boring. Yet there isn't much we can do about it, not on the web, at least - sadly, CSS Speech module has been retired due to lack of interest in implementation from browser vendors. 

Shame!

We could have had amazing things, like control over voice, volume, and speaking rate, to make our websites more expressive not only visually, but also verbally. 

The [spec for CSS Speech](https://www.w3.org/TR/css3-speech/) is still there, so maybe one day it will be implemented. In the meanwhile, semantic HTML is free, and it makes real lives easier. Please, ditch endless `<div>`s and `<span>`s in favour of semantic elements 💛

_____

All in all, I loved Finch. Every talk was great in its own way, and it's incredible how many famous speakers there were in one place. I overheard that it was a tough conf to organise, and there weren't many attendees - but I'm very grateful it still happened. 

Happy coding, and gods bless.