Forem: Andrey Sitnik

Better web video with AV1 codec

Andrey Sitnik — Tue, 20 Aug 2019 16:46:59 +0000

Learn how to instantly improve online viewing experience for your users by embracing the new AV1 video format that is already supported by Chrome and Firefox. This short guide will also show how to replace your GIF's with videos, using AV1 or H.264, to make your files twenty to forty times smaller.

The bets are placed. Both YouTube and Netflix have named AV1 a video codec for the future: Google's video service is already using it on TestTube (new, experimental features for YouTube). Netflix has been calling AV1 "our primary next-gen codec" for a while now. At Evil Martians, we have already tried AV1 at our landing page and at the landing page of Amplifr. In this article, we will share our experience with a new video format and give step-by-step instructions for optimal encoding strategies.

Codecs and Containers

With static images, you don't have to think twice: opt for JPEG or PNG supported by all browsers, or experiment with a more compact Google-developed WebP for newer browsers. You can almost always (barring some dirty hacking tricks that tools like imgproxy can protect you against) be sure that an image file with .png extension is, indeed, a PNG.

With video files, it is a bit more tricky than that. File extensions (.mp4, .wmv, .webm or .mov) barely represent containers, up to three different formats are used to make a video file happen:

Video codec: determines the compression strategy for your video, this is where the trade-offs are made between quality and quantity. On the web, some popular video codecs are H.264, HEVC, VP9, and now AV1.
Audio codec: does the same for audio. If your video does not have sound, you can do without it. Otherwise, the popular choices are MP3, Opus, and AAC.
Containers store both video (compressed by some video codec) and audio streams (compressed by some audio codec), and can also add extra details like subtitles and meta information. Popular containers are MP4, MOV, WebM.

So, when you see .mp4 extension, the only thing you can be sure about is that the MP4 container had been used to package a file. The choice of codecs depends entirely on a creator: it can be H.264/AAC, or AV1/Opus, or something else.

Meet AV1

AV1 is a video codec that was first released almost a year ago: in March 2018. It is designed to compete with previous codec generations such as HEVC/VP9 and H.264/VP8.

Video codecs generations diagram by Tsahi Levent-Levi (source)

To get familiar with technologies used in a new generation video code, feel free to read "Introducing AV1" and "AV1: next generation video".

With all the low-level trickery involved, AV1 is capable of generating files that are up to 30-50% smaller than H.264/VP8 and up to 30% smaller than HEVC, even though, due to being still mostly experimental, it has some problems (at the time of this writing):

The encoder is not optimized yet. As a result, encoding is extremely slow (an upcoming encoder written in Rust attempts to solve this issue). The format is not yet ready for live streaming. However, it is perfectly suitable for web, as your average landing page will usually have a short embedded video that rarely changes.
While supported by Chrome and Firefox, AV1 lacks implementations for Safari and Edge (although Microsoft already has AV1 support in early beta). So you need to have at least two versions of all your videos: AV1 for Chrome/Firefox and H.264 for everything else. Ideally, you should have a third, HEVC version for your Safari users on desktop and mobile and we will show how to prepare all three of those files.

The central promise for of AV1 is maintaining high image quality even at low bitrates, thus allowing for smaller files without apparent compression artifacts.

A chart by Jan Ozer plots data rate against the VMAF quality metric. AV1 is a clear winner.

How to use AV1 right now

Now we are going to show a sequence of steps required to produce the quality video content for the web with AV1. First, you need to choose a container: in theory, it does not matter, but MP4 is recommended and seems to be the most popular at the moment. For the audio codec, we will use Opus with AV1 as an efficient and free alternative.

To ensure the best cross-browser compatibility, we will produce not one, but three files:

For desktop Chrome and Firefox (31% of users as of August 2019): MP4 container with AV1 video codec and Opus audio codec.
For Safari and Edge (16% of users): MP4 with HEVC and AAC.
For other browsers: a larger file in MP4 container with H.264 for video and AAC for audio.

You can also go with just options 1 and 3, you will still ensure that all your users can see the video.

For conversion, I recommend using FFmpeg in a terminal. There are plenty of GUI tools for video compression, but CLI allows for steps that are easily reproducible and can be automated with a script. Make sure that you are using the most recent version of FFmpeg, as versions below 4.1 do not support AV1 in an MP4 container. Here are the steps to install it.

For Mac:

Make sure you have Homebrew.
brew install ffmpeg

For Linux, we recommend using the latest build of FFmpeg from the official website, as at the time of this writing not all package managers contain most recent, AV1-enabled versions:

wget https://johnvansickle.com/ffmpeg/releases/ffmpeg-release-amd64-static.tar.xz
tar -xf ffmpeg-release-amd64-static.tar.xz
sudo cp ffmpeg-4.1-64bit-static/ff* /usr/local/bin/

For Windows, you can use this guide.

Once ffmpeg executable is available in your command line, let's generate the H.264 file (to ensure compatibility with older browsers). Since all our files will use MP4 as a container, I will use .av1.mp4, .hevc.mp4, and .h264.mp4 file extensions. Here is the command you will need to use (don't worry, we will walk you through all the options in a moment).

# Replace SOURCE.mov with a path to your source video file

ffmpeg -i SOURCE.mov -map_metadata -1 -c:a libfdk_aac -c:v libx264 -crf 24 -preset veryslow -profile:v main -pix_fmt yuv420p -movflags +faststart -vf "scale=trunc(iw/2)*2:trunc(ih/2)*2" video.h264.mp4

Now open the resulting video.h264.mp4 file and check your quality. If you are satisfied with the result, but the size still seems too big, try adjusting the -crf option (try -crf 26 or -crf 28): it will reduce the file size, but also the quality, so try to find an acceptable trade-off. That process, frankly, is more art than science.

You can convert H.264 to AV1 if you don't have a single uncompressed source.

Now it is time to generate the AV1 file. The command below will take longer than the one for H.264, but that is to be expected: at the moment, AV1 codec does not use the full power of CPU. That is a curse, but also a blessing: if you are about to encode several files at the same time, it is safe to do so, as multi-threading is currently not supported by default.

ffmpeg -i SOURCE.mov -map_metadata -1 -c:a libopus -c:v libaom-av1 -crf 34 -b:v 0 -pix_fmt yuv420p -movflags +faststart -vf "scale=trunc(iw/2)*2:trunc(ih/2)*2" -strict experimental video.av1.mp4

Play around with the -crf setting for an optimal size/quality balance.

Now the same for HEVC:

ffmpeg -i SOURCE.mov -map_metadata -1 -c:a libfdk_aac -c:v libx265 -crf 24 -preset veryslow -pix_fmt yuv420p -movflags +faststart -tag:v hvc1 -vf "scale=trunc(iw/2)*2:trunc(ih/2)*2" video.hevc.mp4

Then copy all three resulting files (video.h264.mp4, video.hevc.mp4, and video.av1.mp4) to the root of your web project.

Understand compression options

For now, the commands above look like black magic spells, but all those keys are used for a purpose. Here is what they do:

-i SOURCE.mov sets the source video file for input. FFmpeg will take video and audio streams from this file, convert them, and pack into a new container.
-map_metadata -1 will remove video metadata (like the name of a tool that was used initially to create a video). Sometimes metadata is useful, but for web development it is rarely the case.
-c:a libopus or -c:a libfdk_aac selects an audio codec.
-c:v libaom-av1 selects a video codec, a library to compress images into a video stream.
-crf 34 stands for Constant Rate Factor and sets your size/quality balance. Think of it as the quality slider for JPEG, but it goes in the opposite direction (0 stands for best quality and bigger size). CRF scale is different for H.264 and AV1: H.264 goes from 0 to 51, AV1 from 0 to 61. As a result, you will have different CRF ratios for AV1 and H.264. According to this guide by Facebook, here are the optimal mappings between H.264 and AV1 CRF values: 19 → 27, 23 → 33, 27 → 39, 31 → 45, 35 → 51, 39 → 57.
-preset veryslow forces H.264 and HEVC codecs to generate smaller video file even if it will be much longer.
-profile:v main that we use in our H.264 command selects the video codec profile. We can only use "Main", as our video will not be played in Safari otherwise.
-b:v 0 a sets minimum bitrate to force the constant quality mode in AV1.
-pix_fmt yuv420p (pixel format) is a trick to reduce the size of a video. Basically, it uses full resolution for brightness and a smaller resolution for color. It is a way to fool a human eye, and you can safely remove this argument if it does not work in your case.
-movflags +faststart moves the important information to the beginning of the file. It allows browser to start playing video during downloading.
-tag:v hvc1 enables native HEVC video support on Apple operating systems.
-vf "scale=trunc(iw/2)*2:trunc(ih/2)*2" is a way to ensure the produced video will always have an even size (some codecs will only work with sizes like 300x200 and 302x200, but not with 301x200). This option tells FFmpeg to scale the source for the closes even resolution. If your video dimensions were even in the first place, it would not do anything.
-strict experimental option needs to be used for AV1 as AV1 encoder is still experimental.
video.av1.mp4 sets the name for the output file.

Play nice with browsers

Now you need to make sure that browsers will display the right file depending on whether it is supported or not. Luckily, we can set a type attribute on a source element, and only the supported file will be played. For more <video> tag options, look here.

<video controls width="600" height="400">
  <source
    src="video.hevc.mp4"
    type="video/mp4; codecs=hevc,mp4a.40.2"
  />
  <source
    src="video.av1.mp4"
    type="video/mp4; codecs=av01.0.05M.08,opus"
  />
  <source
    src="video.h264.mp4"
    type="video/mp4; codecs=avc1.4D401E,mp4a.40.2"
  />
</video>

Source tags work similarly to if...else statements: the browser will read the list of <source> tags top to bottom and play the first one with supported video type.

Type attribute describes a file format: which container (video/mp4 for MP4), video codec (av01.0.05M.08 for AV1, hevc for HEVC and avc1.4D401E for H.264), and audio codec (opus for Opus and mp4a.40.2 for AAC) should be used.

Bonus: how to convert GIFs to AV1 and H.264

In modern times, using GIF for video fragments is a poor practice. GIFs take 20 to 40 times more space than H.264 or AV1. They also require more CPU and power and drain more battery than modern video formats. If you need short animation sequences on your website in 2019, always opt for video codecs. Luckily, FFmpeg supports GIF files as an input source.

Here's how to convert your GIF to H.264:

ffmpeg -i IMAGE.gif -map_metadata -1 -an -c:v libx264 -crf 24 -preset veryslow -profile:v main -pix_fmt yuv420p -movflags +faststart -vf "scale=trunc(iw/2)*2:trunc(ih/2)*2" animation.h264.mp4

And here's how to go even further and convert it to AV1:

ffmpeg -i IMAGE.gif -map_metadata -1 -an opus -c:v libaom-av1 -crf 50 -b:v 0 -pix_fmt yuv420p -movflags +faststart -vf "scale=trunc(iw/2)*2:trunc(ih/2)*2" -strict experimental animation.av1.mp4

Now we can use animation.h264.mp4 and animation.av1.mp4 in our HTML. Just replace VIDEO_WIDTH, VIDEO_HEIGHT, and PATH_TO_VIDEO:

<video
  autoplay
  loop
  muted
  playsinline
  width="VIDEO_WIDTH"
  height="VIDEO_HEIGHT"
>
  <source
    src="PATH_TO_VIDEO/animation.av1.mp4"
    type="video/mp4; codecs=av01.0.05M.08"
  />
  <source
    src="PATH_TO_VIDEO/animation.h264.mp4"
    type="video/mp4"
  />
</video>

autoplay and loop attributes will emulate the expected behavior of a GIF: looping an animation after the website was loaded. playsinline will forbid Safari from opening the video in full-screen mode.

And that concludes our practical guide!

Even though AV1 codec is still considered experimental, you can already leverage its high-quality, low-bitrate features for a sizable chunk for your web audience (users with current versions of Chrome and Firefox). Of course, you would not want to leave users for other browsers hanging, but the attributes for <video> and <source> tags make implementing this logic easy, and in pure HTML, you don't need to go at length to detect user agents with JavaScript. Mastering a few FFmpeg commands also seems like an easy way to improve the video viewing experience for your visitors. We already use AV1 in production on a couple of our projects and have not encountered any significant problems (except for video compression times, but, again, we are dealing mostly with short static sequences).

Faster WebGL/Three.js 3D graphics with OffscreenCanvas and Web Workers

Andrey Sitnik — Tue, 02 Apr 2019 15:03:59 +0000

Translations: Russian

Learn how to improve WebGL performance when creating complex scenes with Three.js library, by moving the render away from the main thread into a Web worker with OffscreenCanvas. Your 3D will render better on low-end devises and the average performance will go up.

After I added a 3D WebGL model of an earth on my personal website, I found that I immediately lost 5% on Google Lighthouse.

In this article, I will show you how to win back the performance without sacrificing cross-browser compatibility with a tiny library that I wrote for this purpose.

The Problem

With Three.js it is easy to create complex WebGL scenes. Unfortunately, it has a price. Three.js will add around 563 KB to your JS bundle size (and due to its architecture it is not really tree-shakeable).

You may say that the average background image could have the same 500 KB. But every kilobyte of JavaScript costs more to your website’s overall performance than a kilobyte of image data. Latency and bandwidth are not the only things to consider if you aim for a fast website: it is also important to consider how much time will the CPU spend on processing your content. And on lower-end devices, processing resources can take more time than downloading them.

3.5 seconds to process 170 KB of JS and 0.1 second for 170 KB of JPEG. Addy Osmani

Your webpage will be effectively frozen while the browser processes 500KB of Three.js code, as executing JavaScript takes up the main thread. Your user will bot be able to interact with a page until a scene is fully rendered.

Web Workers and Offscreen Canvas

Web Workers is a solution to avoid page freeze during JS execution. It is a way to move some JavaScript code to a separated thread.

Unfortunately, multi-thread programming is very hard. To make it simpler, Web Workers do not have access to DOM. Only the main JavaScript thread has this access. However, Three.js requires and access to the <canvas> node located in the DOM.

OffscreenCanvas is a solution to this problem. It allows you to transfer canvas access the to Web Worker. It is still thread safe as the main thread cannot access <canvas> once you opt for this workaround.

Sounds like we got our bases covered, but here’s the problem: Offscreen Canvas API is supported by Google Chrome only.

Browsers with Offscreen Canvas support in April of 2019 according to Can I Use

However, even in the face of our main enemy, cross-browser issues, we shall not be afraid. Let’s use progressive enhancement: we will improve performance for Chrome and future browsers. Other browsers will run Three.js the old way in the main JavaScript thread.

We need to come up with a way to write a single file for two different environments, keeping in mind that many DOM APIs will not work inside the Web Worker.

The Solution

To hide all the hacks and keep the code readable I created a tiny offscreen-canvas JS library (just 400 bytes). The following examples will rely on it, but I will also explain how it works under the hood.

First, add offscreen-canvas npm package to your project:

npm install offscreen-canvas

We will need to provide a separated JS file for Web Worker. Let’s create a separate JS bundle in webpack’s or Parcel’s config.

  entry: {
    'app': './src/app.js',
+   'webgl-worker': './src/webgl-worker.js'
  }

Bundlers will add a cache buster to bundle’s file names in production. To use the name in our main JS file, let’s add a preload tag. The exact code will depend on the way you generate HTML.

    <link type="preload" as="script" href="./webgl-worker.js">
  </head>

Now we should get the canvas node and a worker URL in the main JS file.

import createWorker from 'offscreen-canvas/create-worker'

const workerUrl = document.querySelector('[rel=preload][as=script]').href
const canvas = document.querySelector('canvas')

const worker = createWorker(canvas, workerUrl)

createWorker looks for canvas.transferControlToOffscreen to detect OffscreenCanvas support. If the browser supports it, the library will load JS files as a Web Worker. Otherwise, it will load the JS file as a regular script.

Now, let’s open webgl-worker.js

import insideWorker from 'offscreen-canvas/inside-worker'

const worker = insideWorker(e => {
  if (e.data.canvas) {
    // Here we will initialize Three.js
  }
})

insideWorker checks if it was it loaded in Web Worker. Depending on the environment, it will use different ways to communicate with the main thread.

The library will execute the callback on any message from the main thread. The first message from createWorker for our worker will always be the object with { canvas, width, height } to initialize canvas.

+ import {
+   WebGLRenderer, Scene, PerspectiveCamera, AmbientLight,
+   Mesh, SphereGeometry, MeshPhongMaterial
+ } from 'three'
  import insideWorker from 'offscreen-canvas/inside-worker'

+ const scene = new Scene()
+ const camera = new PerspectiveCamera(45, 1, 0.01, 1000)
+ scene.add(new AmbientLight(0x909090))
+
+ let sphere = new Mesh(
+   new SphereGeometry(0.5, 64, 64),
+   new MeshPhongMaterial()
+ )
+ scene.add(sphere)
+
+ let renderer
+ function render () {
+   renderer.render(scene, camera)
+ }

  const worker = insideWorker(e => {
    if (e.data.canvas) {
+     // canvas in Web Worker will not have size, we will set it manually to avoid errors from Three.js
+     if (!canvas.style) canvas.style = { width, height }
+     renderer = new WebGLRenderer({ canvas, antialias: true })
+     renderer.setPixelRatio(pixelRatio)
+     renderer.setSize(width, height)
+
+     render()
    }
  })

While creating an initial state of the scene, we can find some error messages from Three.js. Not all the DOM APIs are available in a Web Worker. For instance, there is no document.createElement to load SVG texture. We will need a different loader for Web Worker and regular script environments. We can detect the environment by worker.isWorker property:

      renderer.setPixelRatio(pixelRatio)
      renderer.setSize(width, height)

+     const loader = worker.isWorker ? new ImageBitmapLoader() : new ImageLoader()
+     loader.load('/texture.png', mapImage => {
+       sphere.material.map = new CanvasTexture(mapImage)
+       render()
+     })

      render()

We rendered the initial state of the scene. But most of WebGL scenes need to react to user actions. It could be rotating a camera with a mouse. Or updating canvas on window resize. Unfortunately, Web Worker doesn’t have access to any of the DOM’s events. We need to listen to events in the main thread and send messages to the worker:

  import createWorker from 'offscreen-canvas/create-worker'

  const workerUrl = document.querySelector('[rel=preload][as=script]').href
  const canvas = document.querySelector('canvas')

  const worker = createWorker(canvas, workerUrl)

+ window.addEventListener('resize', () => {
+   worker.post({
+     type: 'resize', width: canvas.clientWidth, height: canvas.clientHeight
+   })
+ })

  const worker = insideWorker(e => {
    if (e.data.canvas) {
      if (!canvas.style) canvas.style = { width, height }
      renderer = new WebGLRenderer({ canvas, antialias: true })
      renderer.setPixelRatio(pixelRatio)
      renderer.setSize(width, height)

      const loader = worker.isWorker ? new ImageBitmapLoader() : new ImageLoader()
      loader.load('/texture.png', mapImage => {
        sphere.material.map = new CanvasTexture(mapImage)
        render()
      })

      render()
-   }
+   } else if (e.data.type === 'resize') {
+     renderer.setSize(width, height)
+     render()
+   }
  })

The Result

Using OffscreenCanvas, I fixed UI freezes on my personal site in Chrome and got a full 100 score on Google Lighthouse. And my WebGL scene still works in all other browsers.

You can check the result: demo and source code for main thread and worker.

With OffscreenCanvas Google Lighthouse Performance rate increased from 95 to 100

CSS and JS Are at War, Here’s How to Stop It

Andrey Sitnik — Tue, 29 Jan 2019 13:36:31 +0000

TL;DR: There are a lot of people who love both JS and UX/CSS/etc. If we stop labeling people just as “JS developers” or “UX developers”, we can achieve a ceasefire in the current “JS vs. CSS” war and get closer to peace.

The War is Real

Some call it The Great Divide: the frontline is real, with JavaScript diehards on one side, and UX/CSS people who advocate non-JS approaches to interfaces—on another.

Front-end developers are afraid of losing their jobs if they avoid the whole JavaScript hype. And it is perfectly understandable: CSS is out of trends. There are significantly fewer CSS conferences and meetups compared to JS/React and friends. For instance, there are 6+ JS meetups in New York and 0 regular CSS meetups.

On the other hand, we see simple static websites being over-engineered out of a sheer FOMO.

We see prominent figures in the front-end community passing the blame on each other every day and that is unfortunate, to say the least.

Look Beyond

The warring factions are often labeled as:

“JS-JS-JS”: Developers who create SPA with client-side JavaScript frameworks like React, Vue.js, and Angular. They are heavy users of innumerable build tools (Babel, webpack, etc.) and JS libraries.
“UX developers”, “CSS developers”, “HTML-JS-CSS developers”: Developers who create static websites with vanilla JavaScript and plain CSS. Accessibility and performance are most important topics in their community.

But do we have to have this split? Maybe this dualism is based solely on our own bias?

In my opinion, this bias is largely caused by two things.

First of all, there is a trend to separate CSS and JavaScript conferences. I think it got started by a very popular and successful JSConf/CSSConf family of events and by a trend for Put-Your-Own-City-Here.js meetups. Content platforms also support the divide: some of them publishe mostly React/JS articles, others focus on CSS and UX.

Second of all, social networks are good at polarizing society. We put ourselves in a bubble of likeminded individuals by subscribing to their feeds and make things even worse by reposting only the most aggressive opinions coming from the other side.

The modern web is incredibly complex. It is extremely hard to master all the technologies that power it and no one can really call oneself a 100% “full-stack” developer. But due to the fact that the JS and CSS/UX discourses have become so (artificially) separated, people with different, but not necessarily opposing passions are bing shoved into a black-and-white “JS vs. CSS” world view. React developers who are passionate about CSS animations and a11y are labeled simple as “JS folks”. And a CSS developer who loves Babel and zero-runtime CSS-in-JS will still be painted as a “CSS guy/gal”.

People Who Love Them Both

As a creator of PostCSS, I could never really pick a side, even if I wanted to. On one hand, PostCSS is a tool for CSS (hence the name). On another hand, PostCSS is a JavaScript build tool and build tools are not well accepted in a modern CSS community.

And I am not alone, there are so many people like me: the creator of an amazing React toolkit for animations, or the creator of a CSS a11y linter, to name a few.

To say the truth, each of us knows only a small subset of technologies that exist out there. And one’s passions not necessarily come from a single topic either. It is OK to love both React and CSS. Or use complex build systems to be sure about you got your a11y right. Or you can dive into distributed systems because you want to make great UX with a bad Internet connection.

Even technologies themselves cannot be seen in black and white.

BEM is often mentioned by the proponents of “CSS faction” as a way to avoid the possible confusion of CSS-in-JS. But few people know that it was not designed by Yandex as a purely CSS technology! It also contains a JavaScript framework and originally had a set of ideas that were later used in React (like nesting small isolated components).

ESLint configs, popular in React community (like AirBnB config), contain a lot of a11y rules.

The Solution

I think the war is real. I think we can stop this war if we stop dividing developers into black and white categories.

If you like technologies from both “sides”: say it out loud! Make it visible, so people can start a civilized discussion. Do you like modern JS frameworks, but also like creating static websites that don’t involve client-side rendering at all? Tell the world about it. Open source authors will create more frameworks for static websites, if they see the need.
Let’s have a public forum for a conversation between JS and CSS worlds. If you are organizing a JavaScript meetup, set aside a day for CSS/UX talks. Let’s “front-end” conferences instead of “JS conferences” and “CSS conferences”, where people from different camps could explain their daily problems and preferred solutions to their opponents.
Let’s try technologies coming from “the other side”:
- If you are a CSS/UX developer, start with linters. Stylelint is a good CSS linter to start with. It will warn you about mistakes and allow you to share best practices across the team. And you can run it as a plugin for your favorite text editor, so you can start even without any bundlers.
- If you are React developer, try some vanilla JS on your next landing page or a blog. This will allow you to better understand your framework’s internals. And your users will thank you for increased performance due to a lighter JavaScript bundle.

How a Month without Computers Changed Me

Andrey Sitnik — Wed, 31 Oct 2018 16:01:23 +0000

No emails left for me to read. Nor write. I’ve sent a message to my family and delegated my open source projects (Autoprefixer and PostCSS) to my friends. With my last tweet sent, I turn off my laptop, phone, and tablet. My Digital Sabbath begins in 10 minutes: no digital devices for the next month.

From the days of the Butlerian Jihad when “thinking machines” had been wiped from most of the universe, computers had inspired distrust.
— Dune Messiah

On the left are things from my old, digital life—carefully, I turned them off, got together and put into a bag. What I got myself for the new life is on the right.

The Month of Ramadan

It began with a post about the Islamic month of Ramadan, when one is not allowed to drink or eat until ‘the first star appears in the sky’ (imagine how difficult it must be fasting like that in Norway, during the polar day). The Ambassador explained that religious people deny themselves what everyday life has to offer to understand how great God’s grace is. This idea gave birth in my imagination to a technocratic state where people do without soy and genetically modified foods for a year just to see: natural agriculture is costly and might lead to global hunger.

Then I asked myself if ‘technological fasting’ could do one good in modern society. Technology has changed the world in the blink of an eye, leaving us no time to reflect on it. What if a month without modern technology could ‘travel’ you to the past? What if there is a way you could compare your technology-relying self to what you once were?

I had doubts. My love of IT and addiction to digital overload were not going to make it easy. But then I learned about this effort of a computer-weary The Verge journalist. My life, he wrote, had become so much better without the computers. To me, his report seemed not without bias, and I decided to take my own journey into the pre-digital world—this time to be seen through the eyes of a programmer.

The Preparation

Doing without my laptop was not gonna cut it, I thought. Smart chips being now used in every domain of life, I must use no digital device at all. I read about fasting in other religions and decided to make precise rules to guide me through whatever difficulty arises. In its final form my covenant was, ‘you must not operate any device that stores a programme in its memory’—in other words, no von Neumann architecture-based devices were allowed.

This was the criterion I used to prepare for my journey. Just like a James Bond, only the other way round: the small, shiny and functional gadgets gave way to things old, cumbersome and one-purpose. Thanks to the hipsters, this vintage could easily be found in flea markets.

My friends tried to scare me away from taking the journey by telling the tale of the Mozilla programmer whom two month of life without the internet made him delete his twitter account.

To burn all the bridges, I told everyone about my Digital Sabbath plans. Doing any work during that time was out of the question, so I took a leave and explained my colleagues how to contact my girlfriend in case of emergency.

Evil Martians played a trick on me though, by deciding to run an internal competition with prizes for the biggest open-source contributions exactly during my Sabbath month.

But there was no going back. My fasting began on November 6, 2013.

The Photography

For my forced dive into the world of analogue photography, I picked a light-meter equipped Zenit-122. My camera would take care of the process—I only needed to keep turning the dials until it told me everything was alright. While most cameras make the focus right using special split screen and microprism to align the two sides of an image, a light-meter is a small solar cell and three LEDs that are seen in the right side of the viewfinder. The upper one is lit if your photo is going to be too dark, the lower if too light, and the middle one turns green if the options are set in the right way.

It was not that hard taking pictures, but I understood it was the computers that had made photography such an easy-to-do, everyday thing. Of course, even our parents didn’t do it the hard way—they didn’t need to know chemistry or develop the photos. Yet, analogue photography reminded me of driving: you start with theory, then they show you what to do and how, and then you practice in a place without other cars. It is not until you have developed the skill that you go and take actual photos. With digital photography, everyone is a photographer now. It only takes opening your phone app; even a child can do that.

Another discovery I made was the incredible power that modern digital cameras have gained in the last decade. Before the Digital Sabbath, we got stuck at the Ukrainian border, where we witnessed the wonderful tradition of putting a whole lot of candles in graveyards during All Saints’ Day. At night we took many a wonderful picture without using a tripod—all thanks to the immense light sensitivity and optical stabilisers that modern cameras have. It was no use carrying my analogue camera at night: the photo film is 30 times less light-sensitive, and in semi-darkness there is no taking any half-decent photo without a tripod.

If I saw a rapidly developing event, I would not even bother to take out the camera—each photo demanding two parameters (focus and exposure time) set, I would not be fast enough to take one.

But at the same time, I felt film to be a blessing a disguise. Modern cameras are too powerful. You push the button—you get the photo you need, always. As a result, not only do you stop thinking about the how but also about the what. Film is hard to use, film makes you find a way. Analysing all the parameters and options available makes a good warm up exercise for your brain: you start looking for a better angle or composition.

The grain and warm colours that film has are all the rage now. But personally, I didn’t see any real magic in them. That’s just what photos had been back in the days. Our parents were younger, and we were kids—we get nostalgic, of course. Exactly like pixel art is just the style of games childhood from our childhood. It doesn’t make a game better per se. Will our children value the effects produced by a bad phone matrix, a reminder of their warm past, as high as we do the grain and warm colours?

My Digital Sabbath made me realise I would use my phone, not my big-ass digital camera, to take photos in my travels. I understood I had no need for the extra options it offered.

The Watch

For the Digital Sabbath, I bought a Raketa (Rocket) soviet mechanical watch. Pity I didn’t manage to find a special 24-hour face version for polar explorers and divers.

In my opinion, each era has a technology that serves as its symbol. The mechanical watch is the crown of the industrial era. Technology was not developed enough for portable devices to be precise, yet people did everything in their might—used their ingenuity, diligence and skill—to make the most of whatever they had. They did manage to make a watch based on pure mechanics. They used gimmickry such as having small rubies in the mechanism to decrease tension. That was why it was not until the advent of synthetic rubies that watches became cheaper and available to general public at the beginning of the 20th century.

My mechanical watch was like a small living creature—its heartbeat kept reminding me it was fragile and needed proper care. For your watch to work for long and show precise time, you need to wind it up every day at exactly the same time. I expected this necessity to turn into a burden, but it didn’t. On the contrary, this nice little duty gave me the opportunity to better feel the passing of time.

Most importantly, time had become somewhat inaccurate. Contemporary quartz watches have a tiny error of a second per day. Synchronising via the internet, computers and phones don’t accumulate even that much error. It means we really are used to our watches being accurate. When we get to the railway station and there is five minutes left before the departure, we can be absolutely sure we will make it.

A mechanical watch accumulates an error of up to a minute per day. It means your train may have already left the station because during the week the error has grown as big as five minutes. My watch having an unknown error was getting on my nerves throughout my travel, so I was always looking for sources of exact time to adjust my watch to.

Unfortunately, one day my watch simply stopped, never to work again—no surprise, taking into account how old it was. It is indeed nice carrying a small mechanical life on your wrist; nevertheless, I went to a shop and bought myself a quartz watch (by that time I already knew there was no computer inside it, only simple electronics and mechanics). I do love my time exact; can’t do anything about it.

Yet I liked having a watch on my wrist. This childhood feeling had been long forgotten, and I was positively surprised that a watch did help you control the time. It is so much easier to take a look at your hand than to put your phone out of your pocket.

After the Digital Sabbath, I decided to buy a smartwatch like Pebble or Android Wear.

The Map and the Compass

The technology that is the symbol of our era? I would say, GPS and GLONASS. On the one hand, they use the most advanced things one can imagine—rockets to take satellites to the orbit, quantum physics to produce atomic clocks for the satellites, Einstein’s theory of relativity to compensate for the loss of time due to speed and gravity, computers to make complex calculations. On the other hand, unlike other brainy things easy-to-use maps are something that everyone on Earth needs. Satellites provide exact coordinates to every person, in any part of the planet, for free—so long as he or she has a cheap receiver.

But during the Digital Sabbath, when I visited a new town, I would have to find a newspaper stand, buy a map and then closely read the names of the streets.

During my preparation, I bought a compass. Primarily for the sake of the warm analogue style. But it actually proved itself useful—so long as you at least know the direction of the street you walk along, it will make reading the map easier.

I didn’t have much difficulty using a GPS-less, paper map. Moreover, paper maps have their advantages, too: which one can be easily drawn and written upon—a digital or a paper one?

The Notepad

During my trip I found old church with old Cyrillic calligraphy. It impress my so much, that I then created @linguopunk account in Twitter for calligraphies like it.

I wouldn’t have taken any pleasure in my Digital Sabbath if it wasn’t for the small spiral-bound notepad I bought to carry in my shirt pocket. It’s not that I had much choice either: digital life had degraded my memory, and I needed an external device to make notes in.

Honestly, I don’t consider the bad memory the younger generations have to be that big of a problem. True, we have to search for information all over again, but it might be a good thing. Information is so quick to change now. What you learned yesterday might have already become all wrong today, while bad memory has you find the latest, most accurate data every time.

I liked using the notepad. You always have a pen to spin in times of idleness. Unlike the touch displays that most phones have, a notepad provides for quick drawings. Another thing I liked was that everything you did at a certain moment was at the same place. The computer makes you follow a hierarchy that is alien to you: one application to search for video, and another for notes. In the notepad, there is only one timeline.

The Thoughts

Boredom was the thing that scared me the most, so I did a lot of preparation: took a few thick books, drew up a schedule (when I leave one place for another) and made up several evening rituals to follow every day. The internet-less reality turned out to be a boredom-less one, too. Recreation does not require anything special—in the end, you can always go out and hunt for good photos.

On the very first day, I went to bed early and woke up early—my biorhythms adjusted to the Sun in no time.

Your battery is never low if you don’t have one. Nor will rain ever ruin your expensive phone. I always had time to think everything over and always felt the pleasant sensation of doing the right thing at the right time. My heart was filled with bliss and confidence.

But soon I saw the difference between IT and other technologies. For example, a lack of electricity or water supply results in immediate discomfort. The internet does not—take a look at our grandparents, who do perfectly fine without computers. Yet without the internet, you sometimes feel so painfully nostalgic that it seems as if you have left your hometown and old friends and reminisce how good it was there.

Digital technologies are something more than routine tools we use without thought. The digital world has grown into our souls, created whole new worlds for our imagination and creativity, introduced us to so many people we would have never met otherwise—without us noticing it.

The digital world needed no neuro-interfaces or cyberpunk-books to become part of us. The most painful thing about my Digital Sabbath was the feeling of something missing deep down inside.

I came to the conclusion that IT hadn’t changed the world around, but created another, a parallel one. The reason we are always nervous and never have enough time is that we are living two lives now. It’s without a doubt difficult, yet how interesting it is to be living two times as much!

By the middle of the month, I felt low—so big was my desire to code. It seemed I was wasting time instead of doing anything useful. When the pain was too bad, I would tell myself the story of _why, an iconic person in the ruby community. One day he disappeared from the internet, deleting all his vast contribution to the world of open source. His final tweet was “programming is rather thankless. u see your works become replaced by superior ones in a year. unable to run at all in a few more”.

My Digital Sabbath was in November, as it can be seen from the GitHub contribution graph.

A little later, my anguish and longing faded into the background, but I got a feeling of my personality dissolving. The internet allows us to express our I much more clearly and intensely. We listen to music that we ourselves find interesting—it doesn’t matter if there is hardly any people in the world that like the same thing. We can pursue hobbies rare, yet intimate. The ability to communicate with anyone, beyond the boundaries of your city, results in relationships with people as congenial as it ever gets. But this all pales in comparison to the opportunities IT gives us in the domain of creativity, a person’s brightest form expression. Time spent without the internet returned me to my school days: you could only listen to whatever music you happened to get and read books that were available in the local store. My personality seemed to be merging with society, majority opinion, and popular music.

The other side of being calm was a loss of motivation. The internet gets you to do things. You see the successes of other people and try to keep up with them. You value time much more dearly, as you know that any extra 10 minutes you can steal is a chanсe to read an interesting article from your archives that might produce a small change in you.

My Digital Sabbath made me re-evaluate my attitude towards social networks. Everyone knows that likes and statuses are no real communication. But when you are far from the place you live in, real communication is impossible. In a few weeks I started to miss my friends and relatives badly. It is true that in the modern world we rarely manage to find time for a heart-to-heart talk, but the little actions and pieces of information from Twitter and Facebook at least give us a connection to others, no matter how small. I may not know all the details, but I keep track of the lives my school friends from another city live. I do know about the most important things in their lives.

Most importantly, social networks allowed for a new stratum, people who are always on the road, to develop. It’s not that people hadn’t moved to other countries before, but those had been a rare case. Even moving to another city meant having no close friends for a year or so, just because it would take time for your new friends to become close. Changing cities every month would mean having no close communication. Now, you can live far from home and yet feel a certain thread connecting you to your close ones. That’s why there are so many more people travelling non-stop nowadays. Citizens of no particular country. Almost everywhere in Asia or Europe I meet my friends and acquaintances who are living there just at the moment.

What a strange thing—computers are nothing but little devices solving small-scale, mundane problems for us, but without them, I would be a completely different person.

The End

It is December 6, 2013. A month has passed, and my Digital Sabbath is over. My excitement has kept me awake for the last 24 hours. There are hundreds of letters and thousands of RSS news waiting for me. I’m so emotional and busy I will not have more than four hours’ sleep a day, for the next three days, and instantly become a night owl, again. Yet I will be so glad to have returned.

The Conclusion

The ‘analogue’ world didn’t feel that much special and spiritual. The internet is not unlike a new flat—it seems empty and lacking soul. Not because the old one was better, but because the old one simply had many things to bring back good memories. The digital world is soon to get filled with our feelings. Just give it a little time.

Despite the fact I am not going to do another month without the computers, I liked my Digital Sabbath. A month was too much though. Two weeks would have done just fine. I changed my attitude towards technology and the impact it has on society. I overcame my fear of boredom and now can easily take a cruise or visit places where there is no internet. I stopped worrying I never had enough time—it had become a logical thing, as I understood that with the internet I live two lives in parallel. I stopped getting fancy with the quality of photography. Taking pictures with my phone is good enough, I decided. I also bought a watch—smart, not mechanical though.

I would not recommend digital fasting to everyone, but a temporary abstinence of some sort seems a very right thing to do. All religions have compulsory fasting. Abstinence from meat in Christianity, or refraining from work in Judaism (btw, see eruv). The one I like the most is the keeping of silence in Hinduism, for example, Mahatma Gandhi would be silent one day a week: he would be reading, thinking, or writing.

It doesn’t take us much time to get used to a way of living and start doing things on autopilot. Our brain likes to save energy, so it turns our extremely voracious conscience as soon as it understands that everyday life can be done without it. As a result, our perception gets dull and replaced by thoughtless habits. Not letting it happen requires leaving the comfort zone, requires entering a new world, where you don’t know anything and have to start from scratch. You could take up a new hobby each month. Or travel from one city to another. Or do without things you are so used to, like having conversations or using computers—just for a little while.

Translated from Russian by Yaroslav Shtyrbu

Forem: Andrey Sitnik

Better web video with AV1 codec

Codecs and Containers

Meet AV1

How to use AV1 right now

Understand compression options

Play nice with browsers

Bonus: how to convert GIFs to AV1 and H.264

Faster WebGL/Three.js 3D graphics with OffscreenCanvas and Web Workers

The Problem

Web Workers and Offscreen Canvas

The Solution

The Result

CSS and JS Are at War, Here’s How to Stop It

The War is Real

Look Beyond

People Who Love Them Both

The Solution

Further Reading

How a Month without Computers Changed Me

The Month of Ramadan

The Preparation

The Photography

The Watch

The Map and the Compass

The Notepad

The Thoughts

The End

The Conclusion