davideisinger.com

benhoyt-com-vfdv1s.txt (37074B)

---

 [1]Ben Hoyt
 
   • [2]Home
   • [3]Resume/CV
   • [4]Projects
   • [5]Tech Writing
   • [6]Non-Tech
   • [7]Email
 
   • [8]benhoyt.com
   • [9][email protected]
 
 The small web is beautiful
 
 March 2021
 
     Summary: I believe that small websites are compelling aesthetically, but
     are also important to help us resist selling our souls to large tech
     companies. In this essay I present a vision for the “small web” as well as
     the small software and architectures that power it. Also, a bonus rant
     about microservices.
 
     Go to: [10]Software | [11]Web | [12]Server-side | [13]Static sites | [14]
     Dependencies | [15]Analytics | [16]Microservices
 
 About fifteen years ago, I read E. F. Schumacher’s Small is Beautiful and,
 despite not being interested in economics, I was moved by its message. Perhaps
 even more, I loved the terse poetry of the book’s title – it resonated with my
 frugal upbringing and my own aesthetic.
 
 I think it’s time for a version of that book about technology, with a chapter
 on web development: The Small Web is Beautiful: A Study of Web Development as
 if People Mattered. Until someone writes that, this essay will have to do.
 
 There are two aspects of this: first, small teams and companies. I’m not going
 to talk much about that here, but [17]Basecamp and many others have. What I’m
 going to focus on in this essay is small websites and architectures.
 
 I’m not the first to talk about the “small web”, but, somewhat surprisingly,
 only a few people have discussed it using that term. Here are the main web
 pages I can find that do:
 
   • [18]Rediscovering the Small Web by Parimal Satyal: a fabulous article about
     the joy of small, independent (and sometimes retro) websites in contrast to
     the “commercial web”.
   • [19]What is the Small Web?, by Aral Balkan of the Small Technology
     Foundation: more of a manifesto against the surveillance of Big Tech than
     something concrete, but still interesting.
 
 Why aim small in this era of fast computers with plenty of RAM? A number of
 reasons, but the ones that are most important to me are:
 
   • Fewer moving parts. It’s easier to create more robust systems and to fix
     things when they do go wrong.
   • Small software is faster. Fewer bits to download and clog your computer’s
     memory.
   • Reduced power consumption. This is important on a “save the planet” scale,
     but also on the very local scale of increasing the battery life of your
     phone and laptop.
   • The light, frugal aesthetic. That’s personal, I know, but as you’ll see,
     I’m not alone.
 
 So let’s dive in. I want to cover a bunch of different angles, each with its
 own subheading.
 
 Small software
 
 If we’re going to talk about a small web, we need to start with small software.
 
 As a teen, I learned to program using x86 assembly and [20]Forth – perhaps odd
 choices, but my dad was heavily into Forth, and I loved how the language was so
 simple I could write [21]my own bootstrapped compiler.
 
 In terms of career, I started as an embedded programmer – not as in “embedded
 Linux” but as in microcontrollers where 16KB of RAM was generous. My current
 laptop has 16GB of RAM, and that’s not a lot by today’s standards. We were
 building IP-networked products with one millionth the amount of RAM. Those
 kinds of micros are as cheap as chips (ahem), and still widely used for small
 electronic devices, sensors, internet-of-things products, and so on.
 
 You have to think about every byte, compile with size optimizations enabled,
 and reuse buffers. It’s a very different thing from modern web development,
 where a JavaScript app compiles “down” to a 1MB bundle, or a single Python
 object header is 16 bytes before you’ve even got any data, or a Go hello-world
 binary is 2MB even before you’ve added any real code.
 
 How do you create small programs? I think the main thing is that you have to
 care about size, and most of us don’t think we have time for that. Apart from
 embedded development, there’s an entire programming subculture called the [22]
 demoscene that cares about this. They have competitions for the smallest 4KB
 demos: who can pack the most graphical punch into 4096 bytes of executable.
 That’s smaller than many favicons! ([23]Elevated and [24]cdak are two of the
 highest-rated 4K demos.) Many demosceners go on to become game developers.
 
 It’s not just about executable size … when you’re developing your next command
 line tool, if you use Go or Rust or even C, your program will be much faster,
 smaller, and use less memory than a Python or Java equivalent. And easier to
 install. If you don’t understand why, please do learn. (It’s out of scope for
 this essay, but to summarize: Go, Rust, and C compile to ready-to-execute
 machine code, don’t carry around a virtual machine, and don’t have memory
 overhead for objects like integers.)
 
 But why not apply some of the same principles to web development? In the web
 world, I think the main trick is to be careful what dependencies you include,
 and also what dependencies they pull in. In short, know node_modules – or maybe
 better, no node_modules. More about this [25]below.
 
 Niklaus Wirth of Pascal fame wrote a famous paper in 1995 called [26]A Plea for
 Lean Software [PDF]. His take is that “a primary cause for the complexity is
 that software vendors uncritically adopt almost any feature that users want”,
 and “when a system’s power is measured by the number of its features, quantity
 becomes more important than quality”. He goes on to describe Oberon, a computer
 language (which reminds me of Go in several ways) and an operating system that
 he believes helps solve the complexity problem. Definitely wirth a read!
 
 I’ve been mulling over this for a number of years – back in 2008 I wrote a
 sarcastic dig at how bloated Adobe Reader had become: [27]Thank you, Adobe
 Reader 9! It was a 33MB download and required 220MB of hard drive space even in
 2008 (it’s now a 150MB download, and I don’t know how much hard drive space it
 requires, because I don’t install it these days).
 
 But instead of just complaining, how do we actually solve this problem?
 Concretely, I think we need to start doing the following:
 
   • Care about size: this sounds obvious, but things only change when people
     think they’re important.
   • Measure: both your executable’s size, and your program’s memory usage. You
     may want to measure over time, and make it a blocking issue if the
     measurements grow more than x% in a release. Or you could hold a
     memory-reduction sprint every so often.
   • Language: choose a backend language that has a chance, for example Rust, C
     or C++, or for servers, Go. These languages aren’t right for everything
     (like data transformation scripts), but they produce small executables, and
     they’re good for CLIs and desktop apps.
   • Remove: cut down your feature set. Aim for a small number of high-quality
     features. My car can’t fly or float, and that’s okay – it drives well.
   • Say no to new features: unless they really fit your philosophy, or add more
     than they cost over the lifetime of your project.
   • Dependencies: understand the size and complexity of each dependency you
     pull in. Use only built-in libraries if you can.
 
 Small websites
 
 I’m glad there’s a growing number of people interested in small websites.
 
 A few months ago there was a sequence of posts to Hacker News about various
 “clubs” you could post your small website on: the [28]1MB Club ([29]comments), 
 [30]512KB Club ([31]comments), [32]250KB Club ([33]comments), and even the [34]
 10KB Club ([35]comments). I think those are a fun indicator of renewed
 interested in minimalism, but I will say that raw size isn’t enough – a 2KB
 site with no real content isn’t much good, and a page with 512KB of very slow
 JavaScript is worse than a snappy site with 4MB of well-chosen images.
 
 Some of my favourite small websites are:
 
 [36]Hacker News: I personally like the minimalist, almost brutalist design, but
 I love its lightness even more. I just downloaded the home page, and loading
 all resources transfers only 21KB (61KB uncompressed). Even pages with huge
 comment threads only transfer about 100KB of compressed data, and load quickly.
 Reddit has become such a bloated mess in comparison. Hacker News, never change!
 
 [37]Lobsters: a similar news-and-voting site, with slightly more “modern”
 styling. It uses some JavaScript and profile icons, but it’s still clean and
 fast, and the total transfer size for the homepage is only 102KB. You just
 don’t need megabytes to make a good website.
 
 [38]Sourcehut: I like the concept behind Drew DeVault’s business, but I love
 how small and anti-fluff the website is. He has set up a mini-site called the 
 [39]Software Forge Performance Index that tracks size and browser performance
 of the prominent source code websites – Sourcehut is far and away the lightest
 and fastest. Even his homepage is only 81KB, including several screenshot
 thumbnails.
 
 [40]SQLite: not only is SQLite a small, powerful SQL database engine, the
 website is fantastically small and content-rich. Even their 7000-word [41]page
 about testing is only 70KB. How do they do this? It’s not magic: focus on
 high-quality textual content, minimal CSS, no JavaScript, and very few images
 (a small logo and some SVGs).
 
 [42]LWN: I’m a little biased, because I’ve written [43]articles for them, but
 they’re an excellent website for Linux and programming news. Extremely
 high-quality technical content (and a high bar for authors). They’re definitely
 niche, and have a “we focus on quality content, not updating our CSS every
 year” kind of look – they’ve been putting out great content for 23 years! Their
 homepage only downloads 44KB (90KB uncompressed).
 
 [44]Dan Luu’s blog: this is one of the more hardcore examples. His inline CSS
 is only about 200 bytes (the pages are basically unstyled), and his HTML source
 code doesn’t use any linefeed characters. Kind of a fun point, although then he
 goes on to load 20KB of Google Analytics JavaScript…
 
 As a friend pointed out, those websites have something of an “anti-aesthetic
 aesthetic”. I confess to not minding that at all, but on the other hand, small
 doesn’t have to mean ugly. More and more personal blogs and websites have
 adopted a small web approach but are more typographically appealing:
 
   • [45]Armin Ronacher’s Thoughts and Writings
   • [46]Chris Wellons’ “Null program” blog
   • [47]Eric Radman’s BSD and SQL blog
   • [48]Hugo Tunius’ programming blog
   • [49]James Hague’s “Programming in the Twenty-First Century”
   • [50]Julia Evans’ programming blog
 
 There are many, many more. Programmer Sijmen Mulder created a nice list of [51]
 text-only websites – not quite the same thing as small, but it definitely
 overlaps!
 
 However, it’s not just about raw size, but about an “ethos of small”. It’s
 caring about the users of your site: that your pages download fast, are easy to
 read, have interesting content, and don’t load scads of JavaScript for Google
 or Facebook’s trackers. Building a website from scratch is not everyone’s cup
 of tea, but for those of us who do it, maybe we can promote templates and tools
 that produce small sites that encourage quality over quantity.
 
 For this website, I lovingly crafted each byte of HTML and CSS by hand, like a
 hipster creating a craft beer. Seriously though, if your focus is good content,
 it’s not hard to create a simple template from scratch with just a few lines of
 HTML and CSS. It will be small and fast, and it’ll be yours.
 
 Loading this essay transfers about 23KB (56KB uncompressed), including the
 favicon and analytics script. It’s small, fast, and readable on desktop or
 mobile. I don’t think it’s too bad looking, but I’m primarily aiming for a
 minimalist design focussed on the content.
 
 In addition to making sure your HTML and CSS are small, be sure to compress
 your images properly. Two basic things here: don’t upload ultra-high resolution
 images straight from your camera, and use a reasonable amount of JPEG
 compression for photos (and PNG for screenshots or vector art). Even for large
 images, you can usually use 75% or 80% compression and still have an image
 without JPEG noise. For example, the large 1920x775 image on the top of my [52]
 side business’s homepage is only 300KB.
 
 Speaking of hero images, you don’t need big irrelevant images at the top of
 your blog posts. They just add hundreds of kilobytes (even megabytes) to your
 page weight, and don’t provide value. And please don’t scatter your article
 with animated GIFs: if there’s something animated on the screen, I can hardly
 concentrate enough to read the text – and I’m [53]not the [54]only one. Include
 relevant, non-stock images that provide value equal to their weight in bytes.
 Bare text is okay, too, like a magazine article.
 
 [55]IndieWeb.org is a great resource here, though they use the term “indie”
 rather than “small”. This movement looks more organic than the [56]Small
 Technology Foundation (which has even been [57]critiqued as “digital
 green-washing”), and their wiki has a lot more real content. IndieWeb also
 promotes local [58]Homebrew Website Clubs and [59]IndieWebCamp meetups.
 
 Emphasize server-side, not JavaScript
 
 JavaScript is a mixed blessing for the web, and more often than not a bane for
 small websites: it adds to the download size and time, it can be a performance
 killer, it’s bad for accessibility, and if you don’t hold it right, it’s [60]
 bad for search engines. Plus, if your website is content-heavy, it probably
 isn’t adding much.
 
 Don’t get me wrong: JavaScript is sometimes unavoidable, and is great where
 it’s great. If you’re developing a browser-based application like Gmail or
 Google Maps, you should almost certainly be using JavaScript. But for your next
 blog, brochure website, or project documentation site, please consider plain
 HTML and CSS.
 
 If your site – like a lot of sites – is somewhere in between and contains some
 light interaction, consider using JavaScript only for the parts of the page
 that need it. There’s no need to overhaul your whole site using React and Redux
 just to add a form. Letting your server generate HTML is still an effective way
 to create fast websites.
 
 [61]Stack Overflow is a case in point. From day one, they’ve made [62]
 performance a feature by rendering their pages on the server, and by measuring
 and reducing render time. I’m sure the Stack Overflow code has changed quite a
 lot since the Jeff Atwood days – it now makes a ton of extra requests for
 advertising purposes – but the content still loads fast.
 
 [63]Hacker News (there’s that site again) is a server-side classic. With only 
 [64]one tiny JavaScript file for voting, the HTML generated on the server does
 the rest. And [65]apparently it still runs on a single machine.
 
 Around fifteen years ago there was this great idea called [66]progressive
 enhancement. The idea was to serve usable HTML content to everyone, but users
 with JavaScript enabled or fast internet connections would get an enhanced
 version with a more streamlined user interface. In fact, Hacker News itself
 uses progressive enhancement: even in 2021, you can still turn off JavaScript
 and use the voting buttons. It’s a bit clunkier because voting now requires a
 page reload, but it works fine.
 
 Is progressive enhancement still relevant in 2021? Arguably not, though some
 die-hards still turn JavaScript off, or at least enable it only for sites they
 trust. However, I think it’s the mentality that’s most important: it shows the
 developer cares about performance, size, and alternative users. If Hacker News
 voting didn’t work without JavaScript, I don’t think that would be a big
 problem – but it shows a certain kind of nerdish care that it does work. Plus,
 the JavaScript they do have is only 2KB (5KB uncompressed).
 
 Compare that to the 8MB (14MB uncompressed) that the [67]Reddit homepage loads.
 And this across 201 requests – I kid you not! – most of which is JavaScript to
 power all the ads and tracking. Lovely…
 
 You don’t need a “framework” to develop this way, of course, but there are some
 tools that make this style of server-side development easier. [68]Turbolinks
 from the Basecamp folks was an early one, and it’s now been superseded by [69]
 Turbo, which is apparently used to power their email service [70]Hey. I haven’t
 used these personally, but the ideas are clever (and surprisingly old-skool):
 use standard links and form submissions, [71]serve plain HTML, but speed it up
 with WebSockets and JavaScript if available. Just today, in fact, someone
 posted a new article on Hacker News which claims [72]“The Future of Web
 Software Is HTML-over-WebSockets”. If Hey is anything to go by, this technique
 is fast!
 
 On the other hand, sometimes you can reduce overall complexity by using
 JavaScript for the whole page if you’re going to need it anyway. For example,
 the registry pages on my wedding registry website are rendered on the client
 (they actually [73]use Elm, which compiles to JavaScript). I do need the
 interactivity of JavaScript (it’s more “single page application” than mere
 content), but I don’t need server-side rendering or good SEO for these pages.
 The homepage is a simple server-rendered template, but the registry pages are
 fully client-rendered.
 
 Static sites and site generators
 
 Another thing there’s been renewed interest in recently is static websites
 (these used to be called just “websites”). You upload some static HTML (and CSS
 and JavaScript) to a static file server, and that’s it.
 
 Improving on that, there are many “static site generators” available. These are
 tools that generate a static site from simple templates, so that you don’t have
 to copy your site’s header and footer into every HTML file by hand. When you
 add an article or make a change, run the script to re-generate. If you’re
 hosting a simple site or blog or even a news site, this is a great way to go.
 It’s content, after all, not an interactive application.
 
 I use [74]GitHub Pages on this site just because it’s a free host that supports
 SSL, and automatically builds your site using the [75]Jekyll static site
 generator whenever you push a change. I have a standard header and include the
 same CSS across all pages easily, though you can have multiple templates or
 “layouts” if you want. Because most people only view one or two articles on my
 site, I include my CSS inline. With HTTP/2, this doesn’t make much difference,
 but Lighthouse showed around 200ms with inline CSS, 300ms with external CSS.
 
 Here’s an example of what a simple Jekyll page looks like (the start of this
 essay, in fact):
 
     ---
     layout: default
     title: "The small web is beautiful"
     permalink: /writings/the-small-web-is-beautiful/
     description: A vision for the "small web", small software, and ...
     ---
     Markdown text here.
 
 I’ve also used [76]Hugo, which is a really fast static site generator written
 in Go – it generates even large sites with thousands of pages in a few seconds.
 And there are [77]many other options available.
 
 Fewer dependencies
 
 There’s nothing that blows up the size of your software (or JavaScript bundle)
 like third party dependencies. I always find a web project’s node_modules
 directory hard to look at – just the sheer volume of stuff in there makes me
 sad.
 
 Different languages seem to have different “dependency cultures”. JavaScript,
 of course, is notorious for an “if it can be a library, it should be” attitude,
 resulting in the [78]left-pad disaster as well as other minuscule libraries
 like the 3-line [79]isarray. There are also big, heavy packages like [80]
 Moment.js, which takes [81]160KB even when minified. There are ways to shrink
 it down if you don’t need all locales, but it’s not the default, so most people
 don’t (you’re probably better off choosing a more modular approach like [82]
 date-fns).
 
 Go now has good dependency management with the recent [83]modules tooling, but
 it also has a culture of “use the standard library if you can”. Russ Cox wrote
 an excellent essay about the downsides of not being careful with your
 dependencies: [84]Our Software Dependency Problem. Go co-creator Rob Pike even
 made this one of his [85]Go proverbs: “A little copying is better than a little
 dependency.” You can probably guess by now, but I like this minimalist
 approach: apart from reducing the number of points of failure, it makes
 programs smaller.
 
 Python, Ruby, Java, and C# seem to be somewhere in between: people use a fair
 number of dependencies, but from what I’ve seen there’s more care taken and it
 doesn’t get as out of hand as node_modules. Admittedly it is a little unfair,
 as Python (and those other languages) have standard libraries that have more in
 them than JavaScript’s.
 
 The website [86]YouMightNotNeedjQuery.com shows how many of the tasks you think
 you might need a library for are actually quite simple to do with plain
 JavaScript. For example, in one of my projects I use a function like the
 following to make an API request with plain old XMLHttpRequest:
 
 function postJson(url, data, callback) {
     var xhr = new XMLHttpRequest();
     xhr.onreadystatechange = function () {
         if (xhr.readyState === xhr.DONE) {
             callback(xhr.status, JSON.parse(xhr.responseText));
         }
     };
     xhr.open("POST", url, true);
     xhr.setRequestHeader("Content-Type", "application/json");
     xhr.send(JSON.stringify(data));
 }
 
 The moral of the story: think twice before adding dependencies. You’ll keep
 your websites and programs smaller and more reliable, and you’ll thank Russ Cox
 later.
 
 Small analytics
 
 Most website owners want some form of analytics to see how many visitors are
 coming to their site, and from where. The go-to tool is Google Analytics: it’s
 easy to set up and the UI is pretty comprehensive. But there’s a cost: it adds
 a significant amount of weight to your page (19KB of JavaScript, 46KB
 uncompressed), and it sends a lot of user data for Google to collect.
 
 Once again, there’s been renewed interest in smaller, more privacy-friendly
 analytics systems in recent times. Just this morning I read a provocative
 article that was highly-voted on Hacker News called [87]“Google Analytics: Stop
 feeding the beast”.
 
 Last year I wrote two articles for LWN on the subject, so I won’t say too much
 more here:
 
   • [88]Lightweight alternatives to Google Analytics: replacing it with
     lightweight open source and privacy-conscious alternatives, specifically 
     [89]GoatCounter and [90]Plausible.
   • [91]More alternatives to Google Analytics: some heavier alternatives, and a
     brief look at log-based analytics tools.
 
 For this website I use GoatCounter, which is available as a low-cost hosted
 service (free for non-commercial use) or as a self-hosted tool. I really like
 what Martin is doing here, and how small and simple the tool is: no bells and
 whistles, just the basic traffic numbers that most people want.
 
 Small architectures (not microservices)
 
 Small websites are great for users, but small architectures are great for
 developers. A small, simple codebase is easy to maintain, and will have fewer
 bugs than a large, sprawling system with lots of interaction points.
 
 I contend that the “microservices everywhere” buzz is a big problem.
 Microservices may be used successfully at Google and Amazon, but most companies
 don’t need to build that way. They introduce complexity in the code, API
 definitions, networking, deployment, server infrastructure, monitoring,
 database transactions – just about every aspect of a system is made more
 complex. Why is that?
 
   • Code: you have lots of little repositories, possibly in different
     languages, and each has to have some way to talk to the other services
     (JSON over HTTP, gRPC, etc). With a monolithic system, it’s all in one
     language (much better for a small team), calling other modules is just a
     function call, and system-wide refactoring is comparatively easy
     (especially in a statically typed language like Go or Java).
   • API definitions: with many services talking to each other, suddenly you
     need standardized interfaces for how they communicate. You spend a lot of
     time setting up gRPC or JSON schema definitions. In a single codebase, a
     function signature is the API definition.
   • Networking: with microservices, a function call is a network call, and you
     spend time setting up your network infrastructure, thinking about timeouts
     and retries, and maybe even designing inter-service authentication. In
     monolithic systems, you only worry about networking when talking to your
     database, cloud provider, and users.
   • Deployment: at a previous company I worked at, once we started building
     with microservices, suddenly we needed fancy deployment tooling and a
     dedicated infrastructure team to manage it all. You can get by with a lot
     less if you’re only deploying a few services.
   • Server infrastructure: you’ll probably need to set up new infrastructure –
     lots of small virtual machines, or a Kubernetes-based system. Kubernetes in
     itself is a complex distributed application (even [92]Google admits it’s
     too complex), and it takes a lot of work – or a lot of money – to run
     properly.
   • Monitoring: to debug issues, you’ll need costly distributed-monitoring
     software like Datadog to see what’s going on. When an outage occurs, you’ll
     scramble to determine which service is responsible, which team to page, and
     so on. Compare that with a simple stack trace or single-service issue.
   • Database transactions: these are difficult to impossible in a microservices
     architecture. You may be able to design your way out of them, but that’s
     not easy either. With a monolith, just type BEGIN ... COMMIT, or however
     your database library spells it.
 
 It’s been said before, but microservices solve a people problem, not a
 technical one. But beware of [93]Conway’s Law: your architecture will mimic
 your company structure. Or the reverse – you’ll have to hire and reorg so that
 your company structure matches the architecture that microservices require:
 lots of engineers on lots of small teams, with each team managing a couple of
 microservices.
 
 That doesn’t mean microservices are always the wrong choice: they may be
 necessary in huge engineering organizations. However, if you’re working at such
 a company, you’ve probably already been using microservices for years. If
 you’re not “Google size”, you should think twice before copying their
 development practices.
 
 What’s the alternative? The term “monolith” has a bad rap, but I agree with
 David at Basecamp that [94]monoliths can be majestic. Basecamp is a large,
 monolithic application, and they run it with just a dozen programmers. David is
 quick to point out that “the Majestic Monolith doesn’t pretend to provide a
 failsafe architectural road to glory”. You still have to think, design, and
 write good code.
 
 Thankfully, people are bouncing back from the cargo culting. Just do a search
 for [95]“why not microservices” and you’ll find lots of good articles on the
 subject. One of the recent ones I’ve read is from Tailscale: [96]Modules,
 monoliths, and microservices.
 
 So what’s my advice?
 
   • Unless your company name is Google or Amazon, start with a monolith.
   • Once it starts having problems, optimize or refactor the pain points.
   • If it’s still having issues, buy a bigger server.
   • If you have a specific technical reason to split it up, fix that problem.
   • If there are still problems, split off only the component that needs
     splitting off. You’ll have two services to deploy and monitor, but that’s
     far simpler than going all-in on microservices.
 
 Okay, so this became more of an anti-microservices rant than I was planning,
 but so be it.
 
 In terms of counter-examples, Stack Overflow once again comes to mind. They’re
 one of the web’s busiest sites, but they have a relatively simple, two-tier 
 [97]architecture that they’ve scaled vertically – in other words, big servers
 with lots of RAM, rather than hundreds of small servers. They have 9 web
 servers and 4 very chunky SQL servers, with a few additional servers for their
 tag engine, Redis, Elasticsearch, and HAProxy. This architecture helps them get
 great performance and the ability to develop with a small team.
 
 My own side business, [98]GiftyWeddings.com, only gets a small amount of
 traffic, so it’s nothing like Stack Overflow, but it uses a Go HTTP server with
 SQLite on one of the smallest EC2 instances available, [99]t2.micro. It costs
 about $8 per month, and I only have one tiny piece of infrastructure to
 maintain. I deploy using [100]Ansible – a tool that is another good example of
 simple architecture and boils down to “just use ssh”.
 
 Speaking of SQLite, there’s a growing number of developers who advocate using
 SQLite to run their websites. SQLite’s [101]“when to use SQLite” page says “any
 site that gets fewer than 100K hits/day should work fine with SQLite. The 100K
 hits/day figure is a conservative estimate, not a hard upper bound. SQLite has
 been demonstrated to work with 10 times that amount of traffic.” Here are some
 other SQLite success stories:
 
   • [102]Litestream is an open source tool that provides streaming replication
     for SQLite. Read author Ben Johnson’s article, [103]Why I Built Litestream.
   • Go developer David Crawshaw has an article about what he calls [104]“one
     process programming” (with Go and SQLite), that can be summed up with his
     phrase “don’t use N computers when 1 will do”. He also created a [105]Go
     SQLite library that supports more SQLite-specific features than the other
     drivers.
   • Peewee ORM author Charles Leifer wrote an article [106]“Five reasons you
     should use SQLite in 2016” that’s still very relevant in 2021. It ends with
     “I hope you’ll give SQLite a try. Don’t believe the FUD about it not being
     production-worthy, or not being suitable for use in web-applications.”
   • Sam Eaton of [107]Crave Cookie runs a $200,000 per month side business
     (wow!) using a single server and SQLite. Read his [108]Indie Hackers
     interview.
 
 Summing up
 
 Companies will do what companies do, and continue to make flashy-looking,
 bloated websites that “convert” well. Maybe you can have an influence at work,
 and come home to your better half and say “honey, I shrunk the web”. Or maybe
 you’ll just focus on the small web for your personal projects. (Disclaimer: I
 mostly do the latter – as part of my day job, I work on [109]Juju, which is not
 a small system by most measures.)
 
 Either way, I believe the “small web” is a compelling term and a compelling
 aesthetic. Not necessarily in the visual sense, but in the sense that you built
 it yourself, you understand all of it, and you run it on a single server or
 static file host.
 
 There are thousands of excellent examples of small websites, and hundreds of
 ways to create simple architectures – this essay touches on only a few of the
 ones I’m passionate about. I’d love to hear your own ideas and stories! Comment
 over at [110]Lobsters or [111]Hacker News or [112]programming Reddit.
 
 I’d love it if you [113]sponsored me on GitHub – it will motivate me to work on
 my open source projects and write more good content. Thanks!
 
 
 References:
 
 [1] https://benhoyt.com/
 [2] https://benhoyt.com/
 [3] https://benhoyt.com/cv/
 [4] https://benhoyt.com/projects/
 [5] https://benhoyt.com/writings/
 [6] https://benhoyt.com/writings/non-tech/
 [7] mailto:[email protected]
 [8] https://benhoyt.com/
 [9] mailto:[email protected]
 [10] https://benhoyt.com/writings/the-small-web-is-beautiful/#small-software
 [11] https://benhoyt.com/writings/the-small-web-is-beautiful/#small-websites
 [12] https://benhoyt.com/writings/the-small-web-is-beautiful/#emphasize-server-side-not-javascript
 [13] https://benhoyt.com/writings/the-small-web-is-beautiful/#static-sites-and-site-generators
 [14] https://benhoyt.com/writings/the-small-web-is-beautiful/#fewer-dependencies
 [15] https://benhoyt.com/writings/the-small-web-is-beautiful/#small-analytics
 [16] https://benhoyt.com/writings/the-small-web-is-beautiful/#small-architectures-not-microservices
 [17] https://basecamp.com/books
 [18] https://neustadt.fr/essays/the-small-web/
 [19] https://ar.al/2020/08/07/what-is-the-small-web/
 [20] https://en.wikipedia.org/wiki/Forth_(programming_language)
 [21] https://github.com/benhoyt/third
 [22] https://en.wikipedia.org/wiki/Demoscene
 [23] https://www.youtube.com/watch?v=jB0vBmiTr6o
 [24] https://www.youtube.com/watch?v=RCh3Q08HMfs
 [25] https://benhoyt.com/writings/the-small-web-is-beautiful/#fewer-dependencies
 [26] https://cr.yp.to/bib/1995/wirth.pdf
 [27] https://blog.brush.co.nz/2008/07/adobe-reader-9/
 [28] https://1mb.club/
 [29] https://news.ycombinator.com/item?id=25151773
 [30] https://512kb.club/
 [31] https://news.ycombinator.com/item?id=25450451
 [32] https://250kb.club/
 [33] https://news.ycombinator.com/item?id=25176663
 [34] https://10kbclub.com/
 [35] https://news.ycombinator.com/item?id=25556860
 [36] https://news.ycombinator.com/news
 [37] https://lobste.rs/
 [38] https://sourcehut.org/
 [39] https://forgeperf.org/
 [40] https://sqlite.org/
 [41] https://sqlite.org/testing.html
 [42] https://lwn.net/
 [43] https://lwn.net/Archives/GuestIndex/#Hoyt_Ben
 [44] https://danluu.com/
 [45] https://lucumr.pocoo.org/
 [46] https://nullprogram.com/
 [47] http://eradman.com/
 [48] https://hugotunius.se/
 [49] https://prog21.dadgum.com/
 [50] https://jvns.ca/
 [51] https://sjmulder.nl/en/textonly.html
 [52] https://giftyweddings.com/
 [53] https://news.ycombinator.com/item?id=26057078
 [54] https://news.ycombinator.com/item?id=11210860
 [55] https://indieweb.org/
 [56] https://small-tech.org/
 [57] https://news.ycombinator.com/item?id=24269071
 [58] https://indieweb.org/Homebrew_Website_Club
 [59] https://indieweb.org/IndieWebCamps
 [60] https://benhoyt.com/writings/seo-for-software-engineers/
 [61] https://stackoverflow.com/
 [62] https://blog.codinghorror.com/performance-is-a-feature/
 [63] https://news.ycombinator.com/
 [64] https://news.ycombinator.com/hn.js
 [65] https://news.ycombinator.com/item?id=23876281
 [66] https://alistapart.com/article/understandingprogressiveenhancement/
 [67] https://www.reddit.com/
 [68] https://github.com/turbolinks/turbolinks
 [69] https://turbo.hotwire.dev/
 [70] https://hey.com/
 [71] https://m.signalvnoise.com/html-over-the-wire/
 [72] https://alistapart.com/article/the-future-of-web-software-is-html-over-websockets/
 [73] https://benhoyt.com/writings/learning-elm/
 [74] https://pages.github.com/
 [75] https://jekyllrb.com/
 [76] https://gohugo.io/
 [77] https://staticsitegenerators.net/
 [78] https://www.davidhaney.io/npm-left-pad-have-we-forgotten-how-to-program/
 [79] https://github.com/juliangruber/isarray/blob/c9b0c5b4f44d366c9f51c7e85e70339bdeaa97b0/index.js#L3-L5
 [80] https://momentjs.com/
 [81] https://momentjs.com/docs/#/use-it/webpack/
 [82] https://date-fns.org/
 [83] https://golang.org/doc/modules/managing-dependencies
 [84] https://research.swtch.com/deps
 [85] https://go-proverbs.github.io/
 [86] http://youmightnotneedjquery.com/
 [87] https://casparwre.de/blog/stop-using-google-analytics/
 [88] https://lwn.net/Articles/822568/
 [89] https://www.goatcounter.com/
 [90] https://plausible.io/
 [91] https://lwn.net/Articles/824294/
 [92] https://www.theregister.com/2021/02/25/google_kubernetes_autopilot/
 [93] https://en.wikipedia.org/wiki/Conway%27s_law
 [94] https://m.signalvnoise.com/the-majestic-monolith/
 [95] https://duckduckgo.com/?t=canonical&q=why+not+microservices&ia=web
 [96] https://tailscale.com/blog/modules-monoliths-and-microservices/
 [97] https://stackexchange.com/performance
 [98] https://giftyweddings.com/
 [99] https://aws.amazon.com/ec2/instance-types/t2/
 [100] https://www.ansible.com/
 [101] https://sqlite.org/whentouse.html
 [102] https://litestream.io/
 [103] https://litestream.io/blog/why-i-built-litestream/
 [104] https://crawshaw.io/blog/one-process-programming-notes
 [105] https://github.com/crawshaw/sqlite
 [106] https://charlesleifer.com/blog/five-reasons-you-should-use-sqlite-in-2016/
 [107] https://cravecookie.com/
 [108] https://www.indiehackers.com/podcast/166-sam-eaton-of-crave-cookie
 [109] https://jaas.ai/
 [110] https://lobste.rs/s/d6qwff/small_web_is_beautiful
 [111] https://news.ycombinator.com/item?id=26305585
 [112] https://www.reddit.com/r/programming/comments/lvfdq9/the_small_web_is_beautiful/
 [113] https://github.com/sponsors/benhoyt/