8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
|
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
|
-
+
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
+
|
# Friction in publishing
If you’re going to start publishing a blog, a podcast, whatever, there will be friction in three
places:
1. Setting everything up
2. Every time you actually publish something
3. Maintenance, upkeep, etc.
3. Maintenance, upkeep, and preservation
Imagine the end product: every detail of how you want your thing to look and work. If you want to be
able to handle super-heavy traffic, or make site-wide changes quickly, or to migrate to a new
service provider, include those things in the scope. Now, for you specifically to implement *that*
end product, a certain total amount of friction is involved, and it is conserved across these
stages.
If you actually want to lose some of the total friction, you can use tools made by others to do
some, or all, of the work, if they exist. The tools you make and/or use determine how much of the
total friction is fungible across the three areas.
If you actually want to lose some of the total friction, you must reduce your project’s scope. If
you use tools made by others, they take on a lot of the friction, but they control the scope.
## Friction profiles
•aside{This section was [added](https://joeldueck.com/code/jdcom/vinfo/d6b528c3c31bdba2?diff=1) on
Jan 6, 2025.}
**Starting a blog on Medium, or newsletter on Substack:** Almost no friction when setting things
up (phase 1) or when publishing things (phase 2). The service decides how things look and
work, not you. Upkeep (phase 3) is free as long as the service remains viable and as long as their
terms of use remain acceptable to you. If any of that changes, and you still want to keep your
thing, suddenly _all_ the friction you avoided is dumped on you at once, as you try to migrate your
content somewhere else.
**Starting a blog with a web-based CMS on your own server:** A high amount of friction setting up
the server, the database, the CMS. When it comes to publishing, you’re just typing into boxes in
your web browser and clicking buttons: as easy as it gets. Maintenance is somewhat higher in
friction than if someone else was responsible for the server, but can go on essentially forever. As
long as they have power and a network connection, servers will carry on for years even with extreme
neglect. Just make sure your backups are working (the hardest part). In general: a lot more friction
in exchange for a lot more control.
**Starting a blog with a static site generator on your own server:** High friction in phase one, but
you can skip the database and CMS setup. Publishing things is more work: you need access to your
site’s source code, you need to remember a handful of special commands, and hopefully you enjoy
using a plain text editor. Maintenance — same friction as the scenario above.
**Starting a simple website with hand-edited HTML files hosted literally anywhere**: An underrated
option. Sure, a little more manual work if you want a blog with consistent formatting and an RSS
feed. But having “just press CTRL+S” as your deployment pipeline is kinda sick. You can schlep your
files nomadically to any dumb, cheap/free service as often as you need to. You are invincible, as a
stream of water is invincible. Watch out for scope creep the first time you want to change your site
design…
**Starting a blog with a static site generator on someone else’s server:** Sure, you still have high
setup friction, and pretty high publishing friction. But in addition you also get the high
maintenance friction that comes with adding a dozen extra layers to your software stack, many of
which are controlled by others and in constant flux.
**Joining the IndieWeb:** If you want [webmentions][wm] on your site, you might just quintuple your
phase-one friction. Plumbing is one of the challenges, coherent presentation is another. Hopefully
you get it all done in a way that doesn’t leave you completely open to spam. Good luck!
•aside{People probably get tired of me saying so, but [I did
this](https://thelocalyarn.com/excursus/secretary/posts/web-books.html).}
**Starting a blog with a static site generator that can also be published to print:** as frictiony
as web publishing can be, print publishing is vastly more so. Combining the two adds so much more
work to setup and to posting. Everything you publish now has to have both mediums in mind. Your
software stack just added several layers. But hey, when you’re no longer alive, you can turn
everything off and you’ll have _all those printed books_ laying around, just existing, with no
friction at all. (You did actually get around to writing and publishing something with this system,
right?)
[wm]: https://indieweb.org/Webmention
## A frictional history of the web
•aside{“We” here means those of us who took up web publishing in the 1990s or early 2000s.}
When the web first started, we were creating each individual HTML file by hand every time we
When the web first started, we were creating each individual HTML files by hand every time we
published something, and this was very tedious. But it was easy to get started. The scope of what we
were trying to do was small, so there wasn’t much friction to spread around, but all of it went into
the publishing step. Low setup, low maintenance.
Then we wanted to do more: we wanted to separate content from presentation; we wanted to have tag
clouds, we wanted RSS feeds. No way were we going to keep loading all that new friction into the
publishing step, because it was also obvious that we should be typing less. So we invested time
|