People, not users
The problem runs deeper than we think, he says, starting with the words we use. At best, we consider our users a finite set of segments (broken down by device or browser) and at worst, a monolithic mass. The principle of progressive enhancement falls on the better part of that spectrum because an application’s shape is guided by a given user’s subset. Kyle argues, however, that users are not nameless groups, clearly divided into groups we choose, but individual people, each with different needs and preferences. To begin with, it helps if we start thinking of them that way and stop using the impersonal word users.
But where to go next? When designing a web application, we rely primarily on our judgement and think we know what the user needs or wants. It’s easier that way. At the same time, however, it is obvious that our ideas often do not correspond to reality and, on the contrary, can spoil the experience for individual people. Just because a particular browser supports a technology (such as WebGL) doesn’t mean the person using that browser wants it. We, as developers and designers, might not understand this but people don’t necessarily want the latest technology or full experience. Sometimes, when it’s dark and raining, the network hardly works, and just a few percent of battery is left, they just need to quickly find a connection home. In those moments, less is more. That’s why, in rare cases, we do not rely solely on our opinion and take other information into account. We ask the browser for battery status, lighting conditions, or type of network. But that’s where the effort ends, at least for most of us.
Kyle claims that this isn’t enough. Decisions like these should be left to the people themselves and not just to their browsers. Yes, that means giving them a way of altering the experience of our app and defer to their preferences. A good example are the newer CSS media queries, such as
prefers-color-scheme: dark, which indicates whether a person is using dark mode in MacOS so we can adjust colors accordingly, or
prefers-reduced-motion, which suggests we should reduce (or eliminate) the amount or intensity of animations. Kyle even showed an example of a theoretical HTTP header (called
request-fidelity) with a unitless value from zero to one. You would set it using a simple slider, either for each site or the whole browser. We as developers could respond to this number in our app and send back a different set of scripts or styles, for example. Of course, no such header exists at the moment but that doesn’t prevent us from developing similar features in our applications right now. If nothing else, the effort could increase the chance of a widely used, standardized solution to be developed.
The future of typography
Jason Pamental would agree. He introduced the so-called variable fonts, a new format that embeds different weights and styles in a single file. This type of font is not defined in a discrete way, i.e. as a set of files each representing one particular weight or variant such as italics, but continuously, allowing for an almost infinite number of possible combinations.
This is great news for two reasons. The first is the amount of downloaded data and the number of HTTP requests. Variable fonts are naturally smaller than a comparable set of normal fonts and there is only one request. The second reason is connected to the central theme of Kyle’s presentation; giving people a way of altering their experience on the web. Thanks to variable fonts, we no longer have to limit ourselves in terms of typography. We can, therefore, offer people a partial control over this aspect of design. Within boundaries we set, a person should be able to change the font size, weight (to increase contrast), or the vertical line spacing. It really makes a difference for people with reading disorders such as dyslexia.
As more and more variable fonts appear every day, there are plenty to choose from. Most of these are variable versions of popular fonts, but some are highly experimental. Fonts like these couldn’t exist without the new specification because they are variable not only in weight, but also in a number of weird dimensions. Good examples are Graduate, Whoa, or Cheee Variable.
Less code, more fun
Rich Harris, one of the creators of the tool Rollup, delivered a clear message: write less code. Why? Each line of code inevitably contains errors and their number naturally increases along with the length of the code. This relationship, however, is not linear but rather quadratic. From experience, we can tell it’s true; larger pull requests are disproportionately harder to understand, bugs slipping through easily. Rich offers help in the form of a simple heuristic: the code of any module should fit on a single screen. The same attention we give to test coverage or the size of downloaded scripts should be paid to avoiding unnecessary code.
To understand the ideas behind Svelte, it’s best to look at a simple component1 and compare it with its equivalent from the world of React2. The first and easily overlooked difference is that a React component can have only one parent element (in this case
And because of the way React works with state, we are often forced to write code that is unnecessarily complex. The variables
b represent the internal state of the component. To link them to
input elements, you must use the
onChange attribute and point it to a function that sets the new state. In React, such a relationship makes sense. Yet, it feels like an overly complicated process, given that we’re talking about a simple assignment of value. And if you forget to cast the
input value from string to number (using the
+) when calling the
setA(+event.target.value), the component would render
1 + 2 = 12 instead of
1 + 2 = 3. Compare that with Svelte, where we express the same relationship by using the simple