5 changed files with 913 additions and 0 deletions
+ 401
- 0
cache/2021/862d065d924906f327f8a95e23659295/index.html
View File
| @@ -0,0 +1,401 @@ | |||
| <!doctype html><!-- This is a valid HTML5 document. --> | |||
| <!-- Screen readers, SEO, extensions and so on. --> | |||
| <html lang="fr"> | |||
| <!-- Has to be within the first 1024 bytes, hence before the <title> | |||
| See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset --> | |||
| <meta charset="utf-8"> | |||
| <!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 --> | |||
| <!-- The viewport meta is quite crowded and we are responsible for that. | |||
| See: https://codepen.io/tigt/post/meta-viewport-for-2015 --> | |||
| <meta name="viewport" content="width=device-width,initial-scale=1"> | |||
| <!-- Required to make a valid HTML5 document. --> | |||
| <title>The small web is beautiful (archive) — David Larlet</title> | |||
| <meta name="description" content="Publication mise en cache pour en conserver une trace."> | |||
| <!-- That good ol' feed, subscribe :). --> | |||
| <link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/"> | |||
| <!-- Generated from https://realfavicongenerator.net/ such a mess. --> | |||
| <link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png"> | |||
| <link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png"> | |||
| <link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png"> | |||
| <link rel="manifest" href="/static/david/icons2/site.webmanifest"> | |||
| <link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c"> | |||
| <link rel="shortcut icon" href="/static/david/icons2/favicon.ico"> | |||
| <meta name="msapplication-TileColor" content="#f0f0ea"> | |||
| <meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml"> | |||
| <meta name="theme-color" content="#f0f0ea"> | |||
| <!-- Documented, feel free to shoot an email. --> | |||
| <link rel="stylesheet" href="/static/david/css/style_2021-01-20.css"> | |||
| <!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. --> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
| <script> | |||
| function toggleTheme(themeName) { | |||
| document.documentElement.classList.toggle( | |||
| 'forced-dark', | |||
| themeName === 'dark' | |||
| ) | |||
| document.documentElement.classList.toggle( | |||
| 'forced-light', | |||
| themeName === 'light' | |||
| ) | |||
| } | |||
| const selectedTheme = localStorage.getItem('theme') | |||
| if (selectedTheme !== 'undefined') { | |||
| toggleTheme(selectedTheme) | |||
| } | |||
| </script> | |||
| <meta name="robots" content="noindex, nofollow"> | |||
| <meta content="origin-when-cross-origin" name="referrer"> | |||
| <!-- Canonical URL for SEO purposes --> | |||
| <link rel="canonical" href="https://benhoyt.com/writings/the-small-web-is-beautiful/"> | |||
| <body class="remarkdown h1-underline h2-underline h3-underline em-underscore hr-center ul-star pre-tick"> | |||
| <article> | |||
| <header> | |||
| <h1>The small web is beautiful</h1> | |||
| </header> | |||
| <nav> | |||
| <p class="center"> | |||
| <a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home"> | |||
| <use xlink:href="/static/david/icons2/symbol-defs.svg#icon-home"></use> | |||
| </svg> Accueil</a> • | |||
| <a href="https://benhoyt.com/writings/the-small-web-is-beautiful/" title="Lien vers le contenu original">Source originale</a> | |||
| </p> | |||
| </nav> | |||
| <hr> | |||
| <blockquote> | |||
| <p>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.</p> | |||
| <p><strong>Go to:</strong> <a href="#small-software">Software</a> | <a href="#small-websites">Web</a> | <a href="#emphasize-server-side-not-javascript">Server-side</a> | <a href="#static-sites-and-site-generators">Static sites</a> | <a href="#fewer-dependencies">Dependencies</a> | <a href="#small-analytics">Analytics</a> | <a href="#small-architectures-not-microservices">Microservices</a></p> | |||
| </blockquote> | |||
| <p>About fifteen years ago, I read E. F. Schumacher’s <em>Small is Beautiful</em> 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.</p> | |||
| <p>I think it’s time for a version of that book about technology, with a chapter on web development: <em>The Small Web is Beautiful: A Study of Web Development as if People Mattered.</em> Until someone writes that, this essay will have to do.</p> | |||
| <p>There are two aspects of this: first, <strong>small teams and companies</strong>. I’m not going to talk much about that here, but <a href="https://basecamp.com/books">Basecamp</a> and many others have. What I’m going to focus on in this essay is <strong>small websites and architectures</strong>.</p> | |||
| <p>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:</p> | |||
| <ul> | |||
| <li><a href="https://neustadt.fr/essays/the-small-web/">Rediscovering the Small Web</a> by Parimal Satyal: a fabulous article about the joy of small, independent (and sometimes retro) websites in contrast to the “commercial web”.</li> | |||
| <li><a href="https://ar.al/2020/08/07/what-is-the-small-web/">What is the Small Web?</a>, by Aral Balkan of the Small Technology Foundation: more of a manifesto against the surveillance of Big Tech than something concrete, but still interesting.</li> | |||
| </ul> | |||
| <p>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:</p> | |||
| <ul> | |||
| <li>Fewer moving parts. It’s easier to create more robust systems and to fix things when they do go wrong.</li> | |||
| <li>Small software is faster. Fewer bits to download and clog your computer’s memory.</li> | |||
| <li>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.</li> | |||
| <li>The light, frugal aesthetic. That’s personal, I know, but as you’ll see, I’m not alone.</li> | |||
| </ul> | |||
| <p>So let’s dive in. I want to cover a bunch of different angles, each with its own subheading.</p> | |||
| <h2 id="small-software">Small software</h2> | |||
| <p>If we’re going to talk about a small web, we need to start with small <em>software</em>.</p> | |||
| <p>As a teen, I learned to program using x86 assembly and <a href="https://en.wikipedia.org/wiki/Forth_(programming_language)">Forth</a> – perhaps odd choices, but my dad was heavily into Forth, and I loved how the language was so simple I could write <a href="https://github.com/benhoyt/third">my own bootstrapped compiler</a>.</p> | |||
| <p>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 <em>one millionth</em> 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.</p> | |||
| <p>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.</p> | |||
| <p>How do you create small programs? I think the main thing is that you have to <em>care about size</em>, and most of us don’t think we have time for that. Apart from embedded development, there’s an entire programming subculture called the <a href="https://en.wikipedia.org/wiki/Demoscene">demoscene</a> 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! (<a href="https://www.youtube.com/watch?v=jB0vBmiTr6o">Elevated</a> and <a href="https://www.youtube.com/watch?v=RCh3Q08HMfs">cdak</a> are two of the highest-rated 4K demos.) Many demosceners go on to become game developers.</p> | |||
| <p>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.)</p> | |||
| <p>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 <em>they</em> pull in. In short, know <code class="language-plaintext highlighter-rouge">node_modules</code> – or maybe better, <em>no</em> <code class="language-plaintext highlighter-rouge">node_modules</code>. More about this <a href="#fewer-dependencies">below</a>.</p> | |||
| <p>Niklaus Wirth of Pascal fame wrote a famous paper in 1995 called <a href="https://cr.yp.to/bib/1995/wirth.pdf">A Plea for Lean Software [PDF]</a>. 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!</p> | |||
| <p>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: <a href="https://blog.brush.co.nz/2008/07/adobe-reader-9/">Thank you, Adobe Reader 9!</a> 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).</p> | |||
| <p>But instead of just complaining, how do we actually solve this problem? Concretely, I think we need to start doing the following:</p> | |||
| <ul> | |||
| <li>Care about size: this sounds obvious, but things only change when people think they’re important.</li> | |||
| <li>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 <em>x</em>% in a release. Or you could hold a memory-reduction sprint every so often.</li> | |||
| <li>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.</li> | |||
| <li>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.</li> | |||
| <li>Say no to new features: unless they really fit your philosophy, or add more than they cost over the lifetime of your project.</li> | |||
| <li>Dependencies: understand the size and complexity of each dependency you pull in. Use only built-in libraries if you can.</li> | |||
| </ul> | |||
| <h2 id="small-websites">Small websites</h2> | |||
| <p>I’m glad there’s a growing number of people interested in small websites.</p> | |||
| <p>A few months ago there was a sequence of posts to Hacker News about various “clubs” you could post your small website on: the <a href="https://1mb.club/">1MB Club</a> (<a href="https://news.ycombinator.com/item?id=25151773">comments</a>), <a href="https://512kb.club/">512KB Club</a> (<a href="https://news.ycombinator.com/item?id=25450451">comments</a>), <a href="https://250kb.club/">250KB Club</a> (<a href="https://news.ycombinator.com/item?id=25176663">comments</a>), and even the <a href="https://10kbclub.com/">10KB Club</a> (<a href="https://news.ycombinator.com/item?id=25556860">comments</a>). 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.</p> | |||
| <p>Some of my favourite small websites are:</p> | |||
| <p><a href="https://news.ycombinator.com/news">Hacker News</a>: 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!</p> | |||
| <p><a href="https://lobste.rs/">Lobsters</a>: 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.</p> | |||
| <p><a href="https://sourcehut.org/">Sourcehut</a>: 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 <a href="https://forgeperf.org/">Software Forge Performance Index</a> 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.</p> | |||
| <p><a href="https://sqlite.org/">SQLite</a>: not only is SQLite a small, powerful SQL database engine, the website is fantastically small and content-rich. Even their 7000-word <a href="https://sqlite.org/testing.html">page about testing</a> 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).</p> | |||
| <p><a href="https://lwn.net/">LWN</a>: I’m a little biased, because I’ve written <a href="https://lwn.net/Archives/GuestIndex/#Hoyt_Ben">articles</a> 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).</p> | |||
| <p><a href="https://danluu.com/">Dan Luu’s blog</a>: 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…</p> | |||
| <p>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:</p> | |||
| <p>There are many, many more. Programmer Sijmen Mulder created a nice list of <a href="https://sjmulder.nl/en/textonly.html">text-only websites</a> – not quite the same thing as <em>small</em>, but it definitely overlaps!</p> | |||
| <p>However, <strong>it’s not just about raw size,</strong> 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.</p> | |||
| <p>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.</p> | |||
| <p>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.</p> | |||
| <p>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 <a href="https://giftyweddings.com/">side business’s homepage</a> is only 300KB.</p> | |||
| <p>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 <a href="https://news.ycombinator.com/item?id=26057078">not the</a> <a href="https://news.ycombinator.com/item?id=11210860">only one</a>. Include relevant, non-stock images that provide value equal to their weight in bytes. Bare text is okay, too, like a magazine article.</p> | |||
| <p><a href="https://indieweb.org/">IndieWeb.org</a> is a great resource here, though they use the term “indie” rather than “small”. This movement looks more organic than the <a href="https://small-tech.org/">Small Technology Foundation</a> (which has even been <a href="https://news.ycombinator.com/item?id=24269071">critiqued</a> as “digital green-washing”), and their wiki has a lot more real content. IndieWeb also promotes local <a href="https://indieweb.org/Homebrew_Website_Club">Homebrew Website Clubs</a> and <a href="https://indieweb.org/IndieWebCamps">IndieWebCamp</a> meetups.</p> | |||
| <h2 id="emphasize-server-side-not-javascript">Emphasize server-side, not JavaScript</h2> | |||
| <p>JavaScript is a mixed blessing for the web, and more often than not a bane for <em>small</em> 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 <a href="https://benhoyt.com/writings/seo-for-software-engineers/">bad for search engines</a>. Plus, if your website is content-heavy, it probably isn’t adding much.</p> | |||
| <p>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.</p> | |||
| <p>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.</p> | |||
| <p><a href="https://stackoverflow.com/">Stack Overflow</a> is a case in point. From day one, they’ve made <a href="https://blog.codinghorror.com/performance-is-a-feature/">performance a feature</a> 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.</p> | |||
| <p><a href="https://news.ycombinator.com/">Hacker News</a> (there’s that site again) is a server-side classic. With only <a href="https://news.ycombinator.com/hn.js">one tiny JavaScript file</a> for voting, the HTML generated on the server does the rest. And <a href="https://news.ycombinator.com/item?id=23876281">apparently</a> it still runs on a single machine.</p> | |||
| <p>Around fifteen years ago there was this great idea called <a href="https://alistapart.com/article/understandingprogressiveenhancement/">progressive enhancement</a>. 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.</p> | |||
| <p>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 <em>mentality</em> 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).</p> | |||
| <p>Compare that to the 8MB (14MB uncompressed) that the <a href="https://www.reddit.com/">Reddit homepage</a> loads. And this across 201 requests – I kid you not! – most of which is JavaScript to power all the ads and tracking. Lovely…</p> | |||
| <p>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. <a href="https://github.com/turbolinks/turbolinks">Turbolinks</a> from the Basecamp folks was an early one, and it’s now been superseded by <a href="https://turbo.hotwire.dev/">Turbo</a>, which is apparently used to power their email service <a href="https://hey.com/">Hey</a>. I haven’t used these personally, but the ideas are clever (and surprisingly old-skool): use standard links and form submissions, <a href="https://m.signalvnoise.com/html-over-the-wire/">serve plain HTML</a>, but speed it up with WebSockets and JavaScript if available. Just today, in fact, someone posted a new article on Hacker News which claims <a href="https://alistapart.com/article/the-future-of-web-software-is-html-over-websockets/">“The Future of Web Software Is HTML-over-WebSockets”</a>. If Hey is anything to go by, this technique is fast!</p> | |||
| <p>On the other hand, sometimes you can <em>reduce</em> 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 <a href="https://benhoyt.com/writings/learning-elm/">use Elm</a>, 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.</p> | |||
| <h2 id="static-sites-and-site-generators">Static sites and site generators</h2> | |||
| <p>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.</p> | |||
| <p>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.</p> | |||
| <p>I use <a href="https://pages.github.com/">GitHub Pages</a> on this site just because it’s a free host that supports SSL, and automatically builds your site using the <a href="https://jekyllrb.com/">Jekyll</a> 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.</p> | |||
| <p>Here’s an example of what a simple Jekyll page looks like (the start of this essay, in fact):</p> | |||
| <div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code> --- | |||
| 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. | |||
| </code></pre></div></div> | |||
| <p>I’ve also used <a href="https://gohugo.io/">Hugo</a>, 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 <a href="https://staticsitegenerators.net/">many other options</a> available.</p> | |||
| <h2 id="fewer-dependencies">Fewer dependencies</h2> | |||
| <p>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 <code class="language-plaintext highlighter-rouge">node_modules</code> directory hard to look at – just the sheer volume of stuff in there makes me sad.</p> | |||
| <p>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 <a href="https://www.davidhaney.io/npm-left-pad-have-we-forgotten-how-to-program/">left-pad disaster</a> as well as other minuscule libraries like the 3-line <a href="https://github.com/juliangruber/isarray/blob/c9b0c5b4f44d366c9f51c7e85e70339bdeaa97b0/index.js#L3-L5"><code class="language-plaintext highlighter-rouge">isarray</code></a>. There are also big, heavy packages like <a href="https://momentjs.com/"><code class="language-plaintext highlighter-rouge">Moment.js</code></a>, which takes <a href="https://momentjs.com/docs/#/use-it/webpack/">160KB even when minified</a>. 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 <a href="https://date-fns.org/"><code class="language-plaintext highlighter-rouge">date-fns</code></a>).</p> | |||
| <p>Go now has good dependency management with the recent <a href="https://golang.org/doc/modules/managing-dependencies">modules tooling</a>, 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: <a href="https://research.swtch.com/deps">Our Software Dependency Problem</a>. Go co-creator Rob Pike even made this one of his <a href="https://go-proverbs.github.io/">Go proverbs</a>: “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.</p> | |||
| <p>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 <code class="language-plaintext highlighter-rouge">node_modules</code>. Admittedly it is a little unfair, as Python (and those other languages) have standard libraries that have more in them than JavaScript’s.</p> | |||
| <p>The website <a href="http://youmightnotneedjquery.com/">YouMightNotNeedjQuery.com</a> 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 <code class="language-plaintext highlighter-rouge">XMLHttpRequest</code>:</p> | |||
| <div class="language-javascript highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="kd">function</span> <span class="nx">postJson</span><span class="p">(</span><span class="nx">url</span><span class="p">,</span> <span class="nx">data</span><span class="p">,</span> <span class="nx">callback</span><span class="p">)</span> <span class="p">{</span> | |||
| <span class="kd">var</span> <span class="nx">xhr</span> <span class="o">=</span> <span class="k">new</span> <span class="nx">XMLHttpRequest</span><span class="p">();</span> | |||
| <span class="nx">xhr</span><span class="p">.</span><span class="nx">onreadystatechange</span> <span class="o">=</span> <span class="kd">function</span> <span class="p">()</span> <span class="p">{</span> | |||
| <span class="k">if</span> <span class="p">(</span><span class="nx">xhr</span><span class="p">.</span><span class="nx">readyState</span> <span class="o">===</span> <span class="nx">xhr</span><span class="p">.</span><span class="nx">DONE</span><span class="p">)</span> <span class="p">{</span> | |||
| <span class="nx">callback</span><span class="p">(</span><span class="nx">xhr</span><span class="p">.</span><span class="nx">status</span><span class="p">,</span> <span class="nx">JSON</span><span class="p">.</span><span class="nx">parse</span><span class="p">(</span><span class="nx">xhr</span><span class="p">.</span><span class="nx">responseText</span><span class="p">));</span> | |||
| <span class="p">}</span> | |||
| <span class="p">};</span> | |||
| <span class="nx">xhr</span><span class="p">.</span><span class="nx">open</span><span class="p">(</span><span class="dl">"</span><span class="s2">POST</span><span class="dl">"</span><span class="p">,</span> <span class="nx">url</span><span class="p">,</span> <span class="kc">true</span><span class="p">);</span> | |||
| <span class="nx">xhr</span><span class="p">.</span><span class="nx">setRequestHeader</span><span class="p">(</span><span class="dl">"</span><span class="s2">Content-Type</span><span class="dl">"</span><span class="p">,</span> <span class="dl">"</span><span class="s2">application/json</span><span class="dl">"</span><span class="p">);</span> | |||
| <span class="nx">xhr</span><span class="p">.</span><span class="nx">send</span><span class="p">(</span><span class="nx">JSON</span><span class="p">.</span><span class="nx">stringify</span><span class="p">(</span><span class="nx">data</span><span class="p">));</span> | |||
| <span class="p">}</span> | |||
| </code></pre></div></div> | |||
| <p>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.</p> | |||
| <h2 id="small-analytics">Small analytics</h2> | |||
| <p>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 <em>lot</em> of user data for Google to collect.</p> | |||
| <p>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 <a href="https://casparwre.de/blog/stop-using-google-analytics/">“Google Analytics: Stop feeding the beast”</a>.</p> | |||
| <p>Last year I wrote two articles for LWN on the subject, so I won’t say too much more here:</p> | |||
| <p>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.</p> | |||
| <h2 id="small-architectures-not-microservices">Small architectures (not microservices)</h2> | |||
| <p>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.</p> | |||
| <p>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?</p> | |||
| <ul> | |||
| <li>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).</li> | |||
| <li>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 <em>is</em> the API definition.</li> | |||
| <li>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.</li> | |||
| <li>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.</li> | |||
| <li>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 <a href="https://www.theregister.com/2021/02/25/google_kubernetes_autopilot/">Google admits</a> it’s too complex), and it takes a lot of work – or a lot of money – to run properly.</li> | |||
| <li>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.</li> | |||
| <li>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 <code class="language-plaintext highlighter-rouge">BEGIN ... COMMIT</code>, or however your database library spells it.</li> | |||
| </ul> | |||
| <p>It’s been said before, but <strong>microservices solve a people problem, not a technical one</strong>. But beware of <a href="https://en.wikipedia.org/wiki/Conway%27s_law">Conway’s Law</a>: 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.</p> | |||
| <p>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.</p> | |||
| <p>What’s the alternative? The term “monolith” has a bad rap, but I agree with David at Basecamp that <a href="https://m.signalvnoise.com/the-majestic-monolith/">monoliths can be majestic</a>. 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.</p> | |||
| <p>Thankfully, people are bouncing back from the cargo culting. Just do a search for <a href="https://duckduckgo.com/?t=canonical&q=why+not+microservices&ia=web">“why not microservices”</a> and you’ll find lots of good articles on the subject. One of the recent ones I’ve read is from Tailscale: <a href="https://tailscale.com/blog/modules-monoliths-and-microservices/">Modules, monoliths, and microservices</a>.</p> | |||
| <p>So what’s my advice?</p> | |||
| <ul> | |||
| <li>Unless your company name is Google or Amazon, start with a monolith.</li> | |||
| <li>Once it starts having problems, optimize or refactor the pain points.</li> | |||
| <li>If it’s still having issues, buy a bigger server.</li> | |||
| <li>If you have a specific technical reason to split it up, fix that problem.</li> | |||
| <li>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.</li> | |||
| </ul> | |||
| <p>Okay, so this became more of an anti-microservices rant than I was planning, but so be it.</p> | |||
| <p>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 <a href="https://stackexchange.com/performance">architecture</a> 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.</p> | |||
| <p>My own side business, <a href="https://giftyweddings.com/">GiftyWeddings.com</a>, 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, <a href="https://aws.amazon.com/ec2/instance-types/t2/">t2.micro</a>. It costs about $8 per month, and I only have one tiny piece of infrastructure to maintain. I deploy using <a href="https://www.ansible.com/">Ansible</a> – a tool that is another good example of simple architecture and boils down to “just use ssh”.</p> | |||
| <p>Speaking of SQLite, there’s a growing number of developers who advocate using SQLite to run their websites. SQLite’s <a href="https://sqlite.org/whentouse.html">“when to use SQLite”</a> 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:</p> | |||
| <ul> | |||
| <li><a href="https://litestream.io/">Litestream</a> is an open source tool that provides streaming replication for SQLite. Read author Ben Johnson’s article, <a href="https://litestream.io/blog/why-i-built-litestream/">Why I Built Litestream</a>.</li> | |||
| <li>Go developer David Crawshaw has an article about what he calls <a href="https://crawshaw.io/blog/one-process-programming-notes">“one process programming”</a> (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 <a href="https://github.com/crawshaw/sqlite">Go SQLite library</a> that supports more SQLite-specific features than the other drivers.</li> | |||
| <li>Peewee ORM author Charles Leifer wrote an article <a href="https://charlesleifer.com/blog/five-reasons-you-should-use-sqlite-in-2016/">“Five reasons you should use SQLite in 2016”</a> that’s still very relevant in 2021. It ends with “I hope you’ll give SQLite a try. Don’t believe the <abbr title="Fear, uncertainty, and doubt">FUD</abbr> about it not being production-worthy, or not being suitable for use in web-applications.”</li> | |||
| <li>Sam Eaton of <a href="https://cravecookie.com/">Crave Cookie</a> runs a $200,000 per month side business (wow!) using a single server and SQLite. Read his <a href="https://www.indiehackers.com/podcast/166-sam-eaton-of-crave-cookie">Indie Hackers interview</a>.</li> | |||
| </ul> | |||
| <h2 id="summing-up">Summing up</h2> | |||
| <p>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 <a href="https://jaas.ai/">Juju</a>, which is not a small system by most measures.)</p> | |||
| <p>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.</p> | |||
| <p>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 <a href="https://lobste.rs/s/d6qwff/small_web_is_beautiful">Lobsters</a> or <a href="https://news.ycombinator.com/item?id=26305585">Hacker News</a> or <a href="https://www.reddit.com/r/programming/comments/lvfdq9/the_small_web_is_beautiful/">programming Reddit</a>.</p> | |||
| </article> | |||
| <hr> | |||
| <footer> | |||
| <p> | |||
| <a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home"> | |||
| <use xlink:href="/static/david/icons2/symbol-defs.svg#icon-home"></use> | |||
| </svg> Accueil</a> • | |||
| <a href="/david/log/" title="Accès au flux RSS"><svg class="icon icon-rss2"> | |||
| <use xlink:href="/static/david/icons2/symbol-defs.svg#icon-rss2"></use> | |||
| </svg> RSS</a> • | |||
| <a href="http://larlet.com" title="Go to my English profile" data-instant><svg class="icon icon-user-tie"> | |||
| <use xlink:href="/static/david/icons2/symbol-defs.svg#icon-user-tie"></use> | |||
| </svg> Pro</a> • | |||
| <a href="mailto:david%40larlet.fr" title="Envoyer un courriel"><svg class="icon icon-mail"> | |||
| <use xlink:href="/static/david/icons2/symbol-defs.svg#icon-mail"></use> | |||
| </svg> Email</a> • | |||
| <abbr class="nowrap" title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340"><svg class="icon icon-hammer2"> | |||
| <use xlink:href="/static/david/icons2/symbol-defs.svg#icon-hammer2"></use> | |||
| </svg> Légal</abbr> | |||
| </p> | |||
| <template id="theme-selector"> | |||
| <form> | |||
| <fieldset> | |||
| <legend><svg class="icon icon-brightness-contrast"> | |||
| <use xlink:href="/static/david/icons2/symbol-defs.svg#icon-brightness-contrast"></use> | |||
| </svg> Thème</legend> | |||
| <label> | |||
| <input type="radio" value="auto" name="chosen-color-scheme" checked> Auto | |||
| </label> | |||
| <label> | |||
| <input type="radio" value="dark" name="chosen-color-scheme"> Foncé | |||
| </label> | |||
| <label> | |||
| <input type="radio" value="light" name="chosen-color-scheme"> Clair | |||
| </label> | |||
| </fieldset> | |||
| </form> | |||
| </template> | |||
| </footer> | |||
| <script> | |||
| function loadThemeForm(templateName) { | |||
| const themeSelectorTemplate = document.querySelector(templateName) | |||
| const form = themeSelectorTemplate.content.firstElementChild | |||
| themeSelectorTemplate.replaceWith(form) | |||
| form.addEventListener('change', (e) => { | |||
| const chosenColorScheme = e.target.value | |||
| localStorage.setItem('theme', chosenColorScheme) | |||
| toggleTheme(chosenColorScheme) | |||
| }) | |||
| const selectedTheme = localStorage.getItem('theme') | |||
| if (selectedTheme && selectedTheme !== 'undefined') { | |||
| form.querySelector(`[value="${selectedTheme}"]`).checked = true | |||
| } | |||
| } | |||
| const prefersColorSchemeDark = '(prefers-color-scheme: dark)' | |||
| window.addEventListener('load', () => { | |||
| let hasDarkRules = false | |||
| for (const styleSheet of Array.from(document.styleSheets)) { | |||
| let mediaRules = [] | |||
| for (const cssRule of styleSheet.cssRules) { | |||
| if (cssRule.type !== CSSRule.MEDIA_RULE) { | |||
| continue | |||
| } | |||
| // WARNING: Safari does not have/supports `conditionText`. | |||
| if (cssRule.conditionText) { | |||
| if (cssRule.conditionText !== prefersColorSchemeDark) { | |||
| continue | |||
| } | |||
| } else { | |||
| if (cssRule.cssText.startsWith(prefersColorSchemeDark)) { | |||
| continue | |||
| } | |||
| } | |||
| mediaRules = mediaRules.concat(Array.from(cssRule.cssRules)) | |||
| } | |||
| // WARNING: do not try to insert a Rule to a styleSheet you are | |||
| // currently iterating on, otherwise the browser will be stuck | |||
| // in a infinite loop… | |||
| for (const mediaRule of mediaRules) { | |||
| styleSheet.insertRule(mediaRule.cssText) | |||
| hasDarkRules = true | |||
| } | |||
| } | |||
| if (hasDarkRules) { | |||
| loadThemeForm('#theme-selector') | |||
| } | |||
| }) | |||
| </script> | |||
| </body> | |||
| </html> | |||
+ 241
- 0
cache/2021/862d065d924906f327f8a95e23659295/index.md
View File
| @@ -0,0 +1,241 @@ | |||
| title: The small web is beautiful | |||
| url: https://benhoyt.com/writings/the-small-web-is-beautiful/ | |||
| hash_url: 862d065d924906f327f8a95e23659295 | |||
| <blockquote> | |||
| <p>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.</p> | |||
| <p><strong>Go to:</strong> <a href="#small-software">Software</a> | <a href="#small-websites">Web</a> | <a href="#emphasize-server-side-not-javascript">Server-side</a> | <a href="#static-sites-and-site-generators">Static sites</a> | <a href="#fewer-dependencies">Dependencies</a> | <a href="#small-analytics">Analytics</a> | <a href="#small-architectures-not-microservices">Microservices</a></p> | |||
| </blockquote> | |||
| <p>About fifteen years ago, I read E. F. Schumacher’s <em>Small is Beautiful</em> 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.</p> | |||
| <p>I think it’s time for a version of that book about technology, with a chapter on web development: <em>The Small Web is Beautiful: A Study of Web Development as if People Mattered.</em> Until someone writes that, this essay will have to do.</p> | |||
| <p>There are two aspects of this: first, <strong>small teams and companies</strong>. I’m not going to talk much about that here, but <a href="https://basecamp.com/books">Basecamp</a> and many others have. What I’m going to focus on in this essay is <strong>small websites and architectures</strong>.</p> | |||
| <p>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:</p> | |||
| <ul> | |||
| <li><a href="https://neustadt.fr/essays/the-small-web/">Rediscovering the Small Web</a> by Parimal Satyal: a fabulous article about the joy of small, independent (and sometimes retro) websites in contrast to the “commercial web”.</li> | |||
| <li><a href="https://ar.al/2020/08/07/what-is-the-small-web/">What is the Small Web?</a>, by Aral Balkan of the Small Technology Foundation: more of a manifesto against the surveillance of Big Tech than something concrete, but still interesting.</li> | |||
| </ul> | |||
| <p>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:</p> | |||
| <ul> | |||
| <li>Fewer moving parts. It’s easier to create more robust systems and to fix things when they do go wrong.</li> | |||
| <li>Small software is faster. Fewer bits to download and clog your computer’s memory.</li> | |||
| <li>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.</li> | |||
| <li>The light, frugal aesthetic. That’s personal, I know, but as you’ll see, I’m not alone.</li> | |||
| </ul> | |||
| <p>So let’s dive in. I want to cover a bunch of different angles, each with its own subheading.</p> | |||
| <h2 id="small-software">Small software</h2> | |||
| <p>If we’re going to talk about a small web, we need to start with small <em>software</em>.</p> | |||
| <p>As a teen, I learned to program using x86 assembly and <a href="https://en.wikipedia.org/wiki/Forth_(programming_language)">Forth</a> – perhaps odd choices, but my dad was heavily into Forth, and I loved how the language was so simple I could write <a href="https://github.com/benhoyt/third">my own bootstrapped compiler</a>.</p> | |||
| <p>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 <em>one millionth</em> 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.</p> | |||
| <p>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.</p> | |||
| <p>How do you create small programs? I think the main thing is that you have to <em>care about size</em>, and most of us don’t think we have time for that. Apart from embedded development, there’s an entire programming subculture called the <a href="https://en.wikipedia.org/wiki/Demoscene">demoscene</a> 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! (<a href="https://www.youtube.com/watch?v=jB0vBmiTr6o">Elevated</a> and <a href="https://www.youtube.com/watch?v=RCh3Q08HMfs">cdak</a> are two of the highest-rated 4K demos.) Many demosceners go on to become game developers.</p> | |||
| <p>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.)</p> | |||
| <p>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 <em>they</em> pull in. In short, know <code class="language-plaintext highlighter-rouge">node_modules</code> – or maybe better, <em>no</em> <code class="language-plaintext highlighter-rouge">node_modules</code>. More about this <a href="#fewer-dependencies">below</a>.</p> | |||
| <p>Niklaus Wirth of Pascal fame wrote a famous paper in 1995 called <a href="https://cr.yp.to/bib/1995/wirth.pdf">A Plea for Lean Software [PDF]</a>. 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!</p> | |||
| <p>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: <a href="https://blog.brush.co.nz/2008/07/adobe-reader-9/">Thank you, Adobe Reader 9!</a> 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).</p> | |||
| <p>But instead of just complaining, how do we actually solve this problem? Concretely, I think we need to start doing the following:</p> | |||
| <ul> | |||
| <li>Care about size: this sounds obvious, but things only change when people think they’re important.</li> | |||
| <li>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 <em>x</em>% in a release. Or you could hold a memory-reduction sprint every so often.</li> | |||
| <li>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.</li> | |||
| <li>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.</li> | |||
| <li>Say no to new features: unless they really fit your philosophy, or add more than they cost over the lifetime of your project.</li> | |||
| <li>Dependencies: understand the size and complexity of each dependency you pull in. Use only built-in libraries if you can.</li> | |||
| </ul> | |||
| <h2 id="small-websites">Small websites</h2> | |||
| <p>I’m glad there’s a growing number of people interested in small websites.</p> | |||
| <p>A few months ago there was a sequence of posts to Hacker News about various “clubs” you could post your small website on: the <a href="https://1mb.club/">1MB Club</a> (<a href="https://news.ycombinator.com/item?id=25151773">comments</a>), <a href="https://512kb.club/">512KB Club</a> (<a href="https://news.ycombinator.com/item?id=25450451">comments</a>), <a href="https://250kb.club/">250KB Club</a> (<a href="https://news.ycombinator.com/item?id=25176663">comments</a>), and even the <a href="https://10kbclub.com/">10KB Club</a> (<a href="https://news.ycombinator.com/item?id=25556860">comments</a>). 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.</p> | |||
| <p>Some of my favourite small websites are:</p> | |||
| <p><a href="https://news.ycombinator.com/news">Hacker News</a>: 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!</p> | |||
| <p><a href="https://lobste.rs/">Lobsters</a>: 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.</p> | |||
| <p><a href="https://sourcehut.org/">Sourcehut</a>: 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 <a href="https://forgeperf.org/">Software Forge Performance Index</a> 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.</p> | |||
| <p><a href="https://sqlite.org/">SQLite</a>: not only is SQLite a small, powerful SQL database engine, the website is fantastically small and content-rich. Even their 7000-word <a href="https://sqlite.org/testing.html">page about testing</a> 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).</p> | |||
| <p><a href="https://lwn.net/">LWN</a>: I’m a little biased, because I’ve written <a href="https://lwn.net/Archives/GuestIndex/#Hoyt_Ben">articles</a> 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).</p> | |||
| <p><a href="https://danluu.com/">Dan Luu’s blog</a>: 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…</p> | |||
| <p>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:</p> | |||
| <p>There are many, many more. Programmer Sijmen Mulder created a nice list of <a href="https://sjmulder.nl/en/textonly.html">text-only websites</a> – not quite the same thing as <em>small</em>, but it definitely overlaps!</p> | |||
| <p>However, <strong>it’s not just about raw size,</strong> 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.</p> | |||
| <p>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.</p> | |||
| <p>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.</p> | |||
| <p>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 <a href="https://giftyweddings.com/">side business’s homepage</a> is only 300KB.</p> | |||
| <p>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 <a href="https://news.ycombinator.com/item?id=26057078">not the</a> <a href="https://news.ycombinator.com/item?id=11210860">only one</a>. Include relevant, non-stock images that provide value equal to their weight in bytes. Bare text is okay, too, like a magazine article.</p> | |||
| <p><a href="https://indieweb.org/">IndieWeb.org</a> is a great resource here, though they use the term “indie” rather than “small”. This movement looks more organic than the <a href="https://small-tech.org/">Small Technology Foundation</a> (which has even been <a href="https://news.ycombinator.com/item?id=24269071">critiqued</a> as “digital green-washing”), and their wiki has a lot more real content. IndieWeb also promotes local <a href="https://indieweb.org/Homebrew_Website_Club">Homebrew Website Clubs</a> and <a href="https://indieweb.org/IndieWebCamps">IndieWebCamp</a> meetups.</p> | |||
| <h2 id="emphasize-server-side-not-javascript">Emphasize server-side, not JavaScript</h2> | |||
| <p>JavaScript is a mixed blessing for the web, and more often than not a bane for <em>small</em> 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 <a href="https://benhoyt.com/writings/seo-for-software-engineers/">bad for search engines</a>. Plus, if your website is content-heavy, it probably isn’t adding much.</p> | |||
| <p>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.</p> | |||
| <p>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.</p> | |||
| <p><a href="https://stackoverflow.com/">Stack Overflow</a> is a case in point. From day one, they’ve made <a href="https://blog.codinghorror.com/performance-is-a-feature/">performance a feature</a> 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.</p> | |||
| <p><a href="https://news.ycombinator.com/">Hacker News</a> (there’s that site again) is a server-side classic. With only <a href="https://news.ycombinator.com/hn.js">one tiny JavaScript file</a> for voting, the HTML generated on the server does the rest. And <a href="https://news.ycombinator.com/item?id=23876281">apparently</a> it still runs on a single machine.</p> | |||
| <p>Around fifteen years ago there was this great idea called <a href="https://alistapart.com/article/understandingprogressiveenhancement/">progressive enhancement</a>. 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.</p> | |||
| <p>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 <em>mentality</em> 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).</p> | |||
| <p>Compare that to the 8MB (14MB uncompressed) that the <a href="https://www.reddit.com/">Reddit homepage</a> loads. And this across 201 requests – I kid you not! – most of which is JavaScript to power all the ads and tracking. Lovely…</p> | |||
| <p>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. <a href="https://github.com/turbolinks/turbolinks">Turbolinks</a> from the Basecamp folks was an early one, and it’s now been superseded by <a href="https://turbo.hotwire.dev/">Turbo</a>, which is apparently used to power their email service <a href="https://hey.com/">Hey</a>. I haven’t used these personally, but the ideas are clever (and surprisingly old-skool): use standard links and form submissions, <a href="https://m.signalvnoise.com/html-over-the-wire/">serve plain HTML</a>, but speed it up with WebSockets and JavaScript if available. Just today, in fact, someone posted a new article on Hacker News which claims <a href="https://alistapart.com/article/the-future-of-web-software-is-html-over-websockets/">“The Future of Web Software Is HTML-over-WebSockets”</a>. If Hey is anything to go by, this technique is fast!</p> | |||
| <p>On the other hand, sometimes you can <em>reduce</em> 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 <a href="https://benhoyt.com/writings/learning-elm/">use Elm</a>, 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.</p> | |||
| <h2 id="static-sites-and-site-generators">Static sites and site generators</h2> | |||
| <p>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.</p> | |||
| <p>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.</p> | |||
| <p>I use <a href="https://pages.github.com/">GitHub Pages</a> on this site just because it’s a free host that supports SSL, and automatically builds your site using the <a href="https://jekyllrb.com/">Jekyll</a> 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.</p> | |||
| <p>Here’s an example of what a simple Jekyll page looks like (the start of this essay, in fact):</p> | |||
| <div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code> --- | |||
| 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. | |||
| </code></pre></div></div> | |||
| <p>I’ve also used <a href="https://gohugo.io/">Hugo</a>, 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 <a href="https://staticsitegenerators.net/">many other options</a> available.</p> | |||
| <h2 id="fewer-dependencies">Fewer dependencies</h2> | |||
| <p>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 <code class="language-plaintext highlighter-rouge">node_modules</code> directory hard to look at – just the sheer volume of stuff in there makes me sad.</p> | |||
| <p>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 <a href="https://www.davidhaney.io/npm-left-pad-have-we-forgotten-how-to-program/">left-pad disaster</a> as well as other minuscule libraries like the 3-line <a href="https://github.com/juliangruber/isarray/blob/c9b0c5b4f44d366c9f51c7e85e70339bdeaa97b0/index.js#L3-L5"><code class="language-plaintext highlighter-rouge">isarray</code></a>. There are also big, heavy packages like <a href="https://momentjs.com/"><code class="language-plaintext highlighter-rouge">Moment.js</code></a>, which takes <a href="https://momentjs.com/docs/#/use-it/webpack/">160KB even when minified</a>. 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 <a href="https://date-fns.org/"><code class="language-plaintext highlighter-rouge">date-fns</code></a>).</p> | |||
| <p>Go now has good dependency management with the recent <a href="https://golang.org/doc/modules/managing-dependencies">modules tooling</a>, 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: <a href="https://research.swtch.com/deps">Our Software Dependency Problem</a>. Go co-creator Rob Pike even made this one of his <a href="https://go-proverbs.github.io/">Go proverbs</a>: “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.</p> | |||
| <p>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 <code class="language-plaintext highlighter-rouge">node_modules</code>. Admittedly it is a little unfair, as Python (and those other languages) have standard libraries that have more in them than JavaScript’s.</p> | |||
| <p>The website <a href="http://youmightnotneedjquery.com/">YouMightNotNeedjQuery.com</a> 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 <code class="language-plaintext highlighter-rouge">XMLHttpRequest</code>:</p> | |||
| <div class="language-javascript highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="kd">function</span> <span class="nx">postJson</span><span class="p">(</span><span class="nx">url</span><span class="p">,</span> <span class="nx">data</span><span class="p">,</span> <span class="nx">callback</span><span class="p">)</span> <span class="p">{</span> | |||
| <span class="kd">var</span> <span class="nx">xhr</span> <span class="o">=</span> <span class="k">new</span> <span class="nx">XMLHttpRequest</span><span class="p">();</span> | |||
| <span class="nx">xhr</span><span class="p">.</span><span class="nx">onreadystatechange</span> <span class="o">=</span> <span class="kd">function</span> <span class="p">()</span> <span class="p">{</span> | |||
| <span class="k">if</span> <span class="p">(</span><span class="nx">xhr</span><span class="p">.</span><span class="nx">readyState</span> <span class="o">===</span> <span class="nx">xhr</span><span class="p">.</span><span class="nx">DONE</span><span class="p">)</span> <span class="p">{</span> | |||
| <span class="nx">callback</span><span class="p">(</span><span class="nx">xhr</span><span class="p">.</span><span class="nx">status</span><span class="p">,</span> <span class="nx">JSON</span><span class="p">.</span><span class="nx">parse</span><span class="p">(</span><span class="nx">xhr</span><span class="p">.</span><span class="nx">responseText</span><span class="p">));</span> | |||
| <span class="p">}</span> | |||
| <span class="p">};</span> | |||
| <span class="nx">xhr</span><span class="p">.</span><span class="nx">open</span><span class="p">(</span><span class="dl">"</span><span class="s2">POST</span><span class="dl">"</span><span class="p">,</span> <span class="nx">url</span><span class="p">,</span> <span class="kc">true</span><span class="p">);</span> | |||
| <span class="nx">xhr</span><span class="p">.</span><span class="nx">setRequestHeader</span><span class="p">(</span><span class="dl">"</span><span class="s2">Content-Type</span><span class="dl">"</span><span class="p">,</span> <span class="dl">"</span><span class="s2">application/json</span><span class="dl">"</span><span class="p">);</span> | |||
| <span class="nx">xhr</span><span class="p">.</span><span class="nx">send</span><span class="p">(</span><span class="nx">JSON</span><span class="p">.</span><span class="nx">stringify</span><span class="p">(</span><span class="nx">data</span><span class="p">));</span> | |||
| <span class="p">}</span> | |||
| </code></pre></div></div> | |||
| <p>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.</p> | |||
| <h2 id="small-analytics">Small analytics</h2> | |||
| <p>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 <em>lot</em> of user data for Google to collect.</p> | |||
| <p>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 <a href="https://casparwre.de/blog/stop-using-google-analytics/">“Google Analytics: Stop feeding the beast”</a>.</p> | |||
| <p>Last year I wrote two articles for LWN on the subject, so I won’t say too much more here:</p> | |||
| <p>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.</p> | |||
| <h2 id="small-architectures-not-microservices">Small architectures (not microservices)</h2> | |||
| <p>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.</p> | |||
| <p>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?</p> | |||
| <ul> | |||
| <li>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).</li> | |||
| <li>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 <em>is</em> the API definition.</li> | |||
| <li>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.</li> | |||
| <li>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.</li> | |||
| <li>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 <a href="https://www.theregister.com/2021/02/25/google_kubernetes_autopilot/">Google admits</a> it’s too complex), and it takes a lot of work – or a lot of money – to run properly.</li> | |||
| <li>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.</li> | |||
| <li>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 <code class="language-plaintext highlighter-rouge">BEGIN ... COMMIT</code>, or however your database library spells it.</li> | |||
| </ul> | |||
| <p>It’s been said before, but <strong>microservices solve a people problem, not a technical one</strong>. But beware of <a href="https://en.wikipedia.org/wiki/Conway%27s_law">Conway’s Law</a>: 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.</p> | |||
| <p>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.</p> | |||
| <p>What’s the alternative? The term “monolith” has a bad rap, but I agree with David at Basecamp that <a href="https://m.signalvnoise.com/the-majestic-monolith/">monoliths can be majestic</a>. 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.</p> | |||
| <p>Thankfully, people are bouncing back from the cargo culting. Just do a search for <a href="https://duckduckgo.com/?t=canonical&q=why+not+microservices&ia=web">“why not microservices”</a> and you’ll find lots of good articles on the subject. One of the recent ones I’ve read is from Tailscale: <a href="https://tailscale.com/blog/modules-monoliths-and-microservices/">Modules, monoliths, and microservices</a>.</p> | |||
| <p>So what’s my advice?</p> | |||
| <ul> | |||
| <li>Unless your company name is Google or Amazon, start with a monolith.</li> | |||
| <li>Once it starts having problems, optimize or refactor the pain points.</li> | |||
| <li>If it’s still having issues, buy a bigger server.</li> | |||
| <li>If you have a specific technical reason to split it up, fix that problem.</li> | |||
| <li>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.</li> | |||
| </ul> | |||
| <p>Okay, so this became more of an anti-microservices rant than I was planning, but so be it.</p> | |||
| <p>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 <a href="https://stackexchange.com/performance">architecture</a> 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.</p> | |||
| <p>My own side business, <a href="https://giftyweddings.com/">GiftyWeddings.com</a>, 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, <a href="https://aws.amazon.com/ec2/instance-types/t2/">t2.micro</a>. It costs about $8 per month, and I only have one tiny piece of infrastructure to maintain. I deploy using <a href="https://www.ansible.com/">Ansible</a> – a tool that is another good example of simple architecture and boils down to “just use ssh”.</p> | |||
| <p>Speaking of SQLite, there’s a growing number of developers who advocate using SQLite to run their websites. SQLite’s <a href="https://sqlite.org/whentouse.html">“when to use SQLite”</a> 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:</p> | |||
| <ul> | |||
| <li><a href="https://litestream.io/">Litestream</a> is an open source tool that provides streaming replication for SQLite. Read author Ben Johnson’s article, <a href="https://litestream.io/blog/why-i-built-litestream/">Why I Built Litestream</a>.</li> | |||
| <li>Go developer David Crawshaw has an article about what he calls <a href="https://crawshaw.io/blog/one-process-programming-notes">“one process programming”</a> (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 <a href="https://github.com/crawshaw/sqlite">Go SQLite library</a> that supports more SQLite-specific features than the other drivers.</li> | |||
| <li>Peewee ORM author Charles Leifer wrote an article <a href="https://charlesleifer.com/blog/five-reasons-you-should-use-sqlite-in-2016/">“Five reasons you should use SQLite in 2016”</a> that’s still very relevant in 2021. It ends with “I hope you’ll give SQLite a try. Don’t believe the <abbr title="Fear, uncertainty, and doubt">FUD</abbr> about it not being production-worthy, or not being suitable for use in web-applications.”</li> | |||
| <li>Sam Eaton of <a href="https://cravecookie.com/">Crave Cookie</a> runs a $200,000 per month side business (wow!) using a single server and SQLite. Read his <a href="https://www.indiehackers.com/podcast/166-sam-eaton-of-crave-cookie">Indie Hackers interview</a>.</li> | |||
| </ul> | |||
| <h2 id="summing-up">Summing up</h2> | |||
| <p>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 <a href="https://jaas.ai/">Juju</a>, which is not a small system by most measures.)</p> | |||
| <p>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.</p> | |||
| <p>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 <a href="https://lobste.rs/s/d6qwff/small_web_is_beautiful">Lobsters</a> or <a href="https://news.ycombinator.com/item?id=26305585">Hacker News</a> or <a href="https://www.reddit.com/r/programming/comments/lvfdq9/the_small_web_is_beautiful/">programming Reddit</a>.</p> | |||
+ 231
- 0
cache/2021/9d1a6e44ba8805d53071ba461df238b0/index.html
View File
| @@ -0,0 +1,231 @@ | |||
| <!doctype html><!-- This is a valid HTML5 document. --> | |||
| <!-- Screen readers, SEO, extensions and so on. --> | |||
| <html lang="fr"> | |||
| <!-- Has to be within the first 1024 bytes, hence before the <title> | |||
| See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset --> | |||
| <meta charset="utf-8"> | |||
| <!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 --> | |||
| <!-- The viewport meta is quite crowded and we are responsible for that. | |||
| See: https://codepen.io/tigt/post/meta-viewport-for-2015 --> | |||
| <meta name="viewport" content="width=device-width,initial-scale=1"> | |||
| <!-- Required to make a valid HTML5 document. --> | |||
| <title>Baptiste Morizot : « L’animalité est constitutive de notre identité dans ce qu’elle a de sain « (archive) — David Larlet</title> | |||
| <meta name="description" content="Publication mise en cache pour en conserver une trace."> | |||
| <!-- That good ol' feed, subscribe :). --> | |||
| <link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/"> | |||
| <!-- Generated from https://realfavicongenerator.net/ such a mess. --> | |||
| <link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png"> | |||
| <link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png"> | |||
| <link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png"> | |||
| <link rel="manifest" href="/static/david/icons2/site.webmanifest"> | |||
| <link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c"> | |||
| <link rel="shortcut icon" href="/static/david/icons2/favicon.ico"> | |||
| <meta name="msapplication-TileColor" content="#f0f0ea"> | |||
| <meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml"> | |||
| <meta name="theme-color" content="#f0f0ea"> | |||
| <!-- Documented, feel free to shoot an email. --> | |||
| <link rel="stylesheet" href="/static/david/css/style_2021-01-20.css"> | |||
| <!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. --> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
| <script> | |||
| function toggleTheme(themeName) { | |||
| document.documentElement.classList.toggle( | |||
| 'forced-dark', | |||
| themeName === 'dark' | |||
| ) | |||
| document.documentElement.classList.toggle( | |||
| 'forced-light', | |||
| themeName === 'light' | |||
| ) | |||
| } | |||
| const selectedTheme = localStorage.getItem('theme') | |||
| if (selectedTheme !== 'undefined') { | |||
| toggleTheme(selectedTheme) | |||
| } | |||
| </script> | |||
| <meta name="robots" content="noindex, nofollow"> | |||
| <meta content="origin-when-cross-origin" name="referrer"> | |||
| <!-- Canonical URL for SEO purposes --> | |||
| <link rel="canonical" href="https://www.humanite.fr/baptiste-morizot-lanimalite-est-constitutive-de-notre-identite-dans-ce-quelle-de-sain-658797"> | |||
| <body class="remarkdown h1-underline h2-underline h3-underline em-underscore hr-center ul-star pre-tick"> | |||
| <article> | |||
| <header> | |||
| <h1>Baptiste Morizot : « L’animalité est constitutive de notre identité dans ce qu’elle a de sain «</h1> | |||
| </header> | |||
| <nav> | |||
| <p class="center"> | |||
| <a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home"> | |||
| <use xlink:href="/static/david/icons2/symbol-defs.svg#icon-home"></use> | |||
| </svg> Accueil</a> • | |||
| <a href="https://www.humanite.fr/baptiste-morizot-lanimalite-est-constitutive-de-notre-identite-dans-ce-quelle-de-sain-658797" title="Lien vers le contenu original">Source originale</a> | |||
| </p> | |||
| </nav> | |||
| <hr> | |||
| <p><strong>Comment avez-vous découvert le pistage et comment le définissez-vous ? C’est à la fois une pratique de terrain et un concept philosophique…</strong></p> | |||
| <p> </p> | |||
| <p><strong>Baptiste Morizot : </strong> J’avais le sentiment qu’il était nécessaire de vivifier la pensée par des pratiques de terrain, au contact des vivants sur lesquels je réfléchissais. Et cette expérience a modifié certains aspects de ma recherche : ma méthode philosophique s’est métissée de pistage, d’attention aux signes et indices. Quant à le définir: d’abord il faut comprendre que le pistage est pour moi complètement désarticulé de la chasse : cela n’a rien à voir. Le « pistage philosophique» qui m’intéresse est plutôt de se rendre sensible à la manière dont les autres vivants habitent avec nous ce monde, pour inventer des formes de cohabitation plus riches et plus vivables pour tous. Je le définirai donc comme une manière renouvelée d’être attentif aux vivants. Sans nier l'existence de conflits potentiels et de rapports de force, mais avec pour mission de mettre en place un modus vivendi aussi pacifié que possible. Ce que j’aime dans cette affaire, c’est qu’il s’agit d’une pratique dans laquelle on est sorti de l’opposition entre pensée et sensibilité, entre théorie et pratique : dans le pistage, pour interpréter les indices laissés par un cerf, une panthère des neiges ou un loup, on tisse de manière très serrée les sens, l’intuition, l’imagination, et le raisonnement, le tout pour chercher un état d’attention très aiguisé, vibratile, à ce qui se passe autour. Les couples d'oppositions héritées de la Modernité sont bien loin.</p> | |||
| <p> </p> | |||
| <p><strong>Comment se former au pistage ? </strong></p> | |||
| <p> </p> | |||
| <p><strong>Baptiste Morizot :</strong> Cela n’exige aucune forme d’expertise, il suffit d’un peu d’entrainement. On ouvre l’espace du visible et du sensible petit à petit. Tous ces paysages où « on n’y voit rien » se peuplent d’indices, de signes, de présences, de relations. J’ai appris récemment qu’un oiseau de chez nous, le rouge-queue à front blanc, est assez fascinant: lorsqu’il migre au sud du Sahara, il est capable sur place d’apprendre la langue des passereaux chanteurs autochtones, pour négocier avec eux son territoire saisonnier. C’est un oiseau diplomate, dont les facultés de communication, de négociation pour travailler à des modus vivendi entre étrangers, étaient insoupçonnées. De même, il existe dans nos jardins des orchidées qui échangent des molécules de sucres avec des érables, par le biais du mycorhize souterrain qui les relie, en fonction de la période de l’année où chacun en a le plus besoin. Être sensible à cela, en croisant savoir et curiosité sur le terrain, produit une métamorphose de la disponibilité. Nous en avons besoin pour retisser des affiliations envers ces formes de vie qui sont nos parentes. Car cela s’étend aux végétaux, aux insectes, aux forêts et aux rivières, comme aux friches urbaines. Il faut réapprendre à partager la Terre avec tous ces vivants que nous avions rendus invisibles, en les considérant comme des automates ou de la matière inerte. </p> | |||
| <p> </p> | |||
| <p><strong>Vous parlez des animaux « diplomates », vous leur avez consacré un ouvrage en prenant l’exemple des loups. Quel est le sens de cette diplomatie ?</strong></p> | |||
| <p> </p> | |||
| <p><strong>Baptiste Morizot :</strong> C’est un certain rapport à l’autre. Nous héritons de la tradition occidentale l’idée que les vivants sont des choses, de la matière à gérer quantitativement, ou à mater par le rapport de force, où encore à sanctuariser dans des réserves microscopiques. Dès lors qu’on prend au sérieux ce que disent l’éthologie et l’écologie scientifique contemporaines (sciences subversives par excellence, qui ébranlent les conceptions scientistes du monde), il devient évident que les vivants ne sont pas des choses mais des êtres et des agents. Bien entendu, ils ne signent pas de traités, ni ne discutent comme nous le faisons, mais ils ont leurs modes de communication, et des manières de composer ensemble sur un même territoire, de réduire l’agressivité mutuelle entre espèces et entre individus. Ce sont déjà des formes de diplomatie, en un sens minimal. Mais surtout, ces communications, ces comportements, ces manières de créer des modus vivendi, sont encore largement ignorées (du fait même qu’on a postulé qu’elles n’existaient pas dans la nature). Face à des êtres aux mœurs inconnues, aux langages inaccessibles, qui faut-il envoyer ? Des diplomates, au sens de ces explorateurs pacifiques (il y en a eu) qui sont allés au-devant d’autres peuples pour apprendre leurs manières de penser, de communiquer, et de faire territoire. Cela pour jouer le rôle d’interprète et de truchement envers eux, entre eux et nous, et essayer d’imaginer des codes communs pour cohabiter malgré les conflits. C’est ce que j’essaie de penser concrètement avec les loups dans mon livre. Ces animaux, bien qu'on les fantasme comme des fauves assoiffés de sang, sont puissamment géopolitiques : les meutes entre elles, par exemple, respectent les frontières d'odeur des autres meutes. Enfin ils apprennent vite lorsqu'on leur envoie vigoureusement les bons messages. Toute la question est : par quels modes de communications les plus efficaces peut-on les détourner des troupeaux, dont ils n'ont pas besoin pour se nourrir ?</p> | |||
| <p> </p> | |||
| <p><strong>La nature est largement domestiquée, exploitée, quadrillée par l’homme. Comment penser la cohabitation que vous appelez de vos vœux à l’ère de l’anthropocène ?</strong></p> | |||
| <p> </p> | |||
| <p><strong>Baptiste Morizot :</strong> Tout le problème revient à trouver des inspirations pour penser de manière pertinente et émancipatrice la cohabitation. On peut en trouver dans l’histoire des relations entre les peuples humains étrangers. Le modèle qui m’intéresse, plus que celui de la colonisation brutale qui a été la norme de l’histoire européenne, ce sont ces rares cas de rencontres entre peuples où, pour des raisons historiques, il a été nécessaire de faire de la diplomatie et de cohabiter. C’est par exemple ce qui a eu lieu en partie dans la région des Grands Lacs, entreAmérindiens algonquins et colons français au 18ème siècle : c’est ce que l’historien Richard White appelle un « middle ground », c’est-à-dire un terrain commun entre des peuples qui n’ont pas le même langage, pas les mêmes lois, qui ne se reconnaissent d’ailleurs pas mutuellement le statut d’humains ou de personnes morales, mais qui doivent apprendre à communiquer et à cohabiter dans des territoires partagés. Richard White isole les conditions historiques qui font qu’une relation entre peuples, qui pourrait être brutale et impérialiste, devient diplomatique : schématiquement, cela advient lorsque les êtres en présence sont dans une relation de vulnérabilité mutuelle.</p> | |||
| <p> </p> | |||
| <p><strong>Comment appliquer ces travaux à nos relations avec la nature ?</strong></p> | |||
| <p> </p> | |||
| <p><strong>Baptiste Morizot : </strong>Mon raisonnement est simple : les rapports concernant l’état de la biodiversité et des dynamiques écologiques actuelles montrent que nos activités les ont ébranlées au point de les rendre instables et fragiles, mais aussi que nous avons besoin d’elles pour maintenir nos vies. La fragilisation des pollinisateurs est un problème majeur pour tout le maraîchage européen, comme la destruction de la vie des sols par l’agriculture productiviste à intrants fragilise nos conditions de vie futures. Nous sommes donc bien dans une situation de vulnérabilité mutuelle. C’est une situation qui appelle le "middle ground" diplomatique envers les vivants : il nous faut des diplomates abeilles pour comprendre ce dont elles ont besoin pour cohabiter parmi nous, comme il nous faut des agents pour faire de la diplomatie avec la microfaune fascinante des sols.</p> | |||
| <p> </p> | |||
| <p><strong>On assiste depuis quelque temps à des débats virulents sur le véganisme, sur les droits des animaux... La relation de l’homme avec le monde animal est-elle, selon vous, l’un des grands enjeux du XXIe siècle ? </strong></p> | |||
| <p> </p> | |||
| <p><strong>Baptiste Morizot : </strong>indépendamment de la question du traitement du bétail (qui n’est qu’une fraction des l’animalité), la grande violence invisible de notre civilisation est d’avoir fait des animaux des figures pour les enfants. S’y intéresser serait alors de la sensiblerie. Notre rapport à l’animalité et aux animaux est infantilisée, primitivisée, exotisée, alors qu’elle est constitutive de notre identité dans ce qu’elle a de sain. Les animaux ne sont pas seulement des peluches ou les objets de notre indignation morale. Nous partageons avec eux une ascendance. L’animal est un intercesseur privilégié avec l’énigme originelle, celle de notre manière d’être vivant. Il manifeste une altérité incompressible et en même temps il est assez proche de nous pour que mille formes de parallèles et de convergences soient sensibles, avec les mammifères, les oiseaux, les pieuvres, jusqu’aux insectes. Les bactéries, et souvent les végétaux, sont plus loin dans notre généalogie commune. Ils sont des parents si étrangers qu’il est moins facile de se sentir vivants comme eux : cela exige des passeurs. Les animaux, du fait de leur position liminaire, sont alors des intercesseurs.</p> | |||
| <p> </p> | |||
| <p><strong>Quelles leçons politiques pouvons-nous tirer du pistage? Comment peut-il nous aider à produire du collectif, du dialogue, du débat ? </strong></p> | |||
| <p> </p> | |||
| <p><strong>Baptiste Morizot : </strong>Une part décisive mais discrète du politique se joue dans les déplacements des seuils et des passages qui commandent l’attention. Par exemple, la question des rapports inégalitaires entre hommes et femmes a connu des déplacements dans les dernières décennies, grâce aux mobilisations féministes, et elle est conséquemment devenue un astre qui attire beaucoup d’attention politique. La question du travail aliéné et des rapports capital/travail, la la condition de ceux qui ne possèdent pas les moyens de production mais vendent leur force de travail, naturalisée dans le premier capitalisme, est devenue avec Marx un objet des plus vigoureuses attentions politiques. Les bougés dans l’art de l’attention d’un collectif humain se manifestent par un symptôme éloquent : le sens du tolérable et de l’intolérable. C’est une machine délicate, instruite par des flux sociaux et culturels. Par exemple, la monarchie de droit divin nous est devenue intolérable. </p> | |||
| <p> </p> | |||
| <p><strong>Comment cette notion de seuil du tolérable et de l’intolérable peut-elle modifier notre rapport au vivant ? </strong></p> | |||
| <p> </p> | |||
| <p><strong>Baptiste Morizot : </strong>Au sens où l’idée de disparition des oiseaux des champs, des insectes européens, à cause de notre cécité, de nos pratiques de productions aveugles, doit nous devenir intolérable. Dans mon livre, j’essaie de contribuer à cela, à petite échelle, par des récits qui préparent des rencontres possibles avec des animaux, auxquels on prête de nouveau attention : ils entrent dans le champ de l'attention politique. Ces rencontres nous font accéder à une forme de soi élargi. Je me souviens d’un passager du train qui regardait avec anxiété un ciel pluvieux de printemps par la fenêtre. Lorsqu’il me révéla la raison de sa préoccupation, je suis resté muet. Il m’annonça : « Les printemps pluvieux me préoccupent, ils sont mauvais pour les chauve-souris et leurs nouveaux-nés. Il y a beaucoup moins d’insectes. » Un soi élargi dans lequel les autres vivants emménagent, c’est certes quelques préoccupations de plus, mais c’est aussi étrangement émancipateur. Ce n’est qu’ensuite, et non parce qu’on a culpabilisé chacun par l’annonce quotidienne des apocalypses actuelles, que le système des valeurs de base se transforme. Pour changer le politique, il faut aussi (parallèlement à militer, désobéir, lancer l’alerte, et faire levier au plus près du pouvoir) transformer la culture. C’est un truisme. Regardez ce que la médiatisation de Notre-Dame des Landes a fait, comment les lignes architectoniques de la sensibilité bougent. C’est un travail de longue haleine, mais il mérite d’être fait, parce que nous vivants avons encore quelques millénaires à vivre ensemble sur cette planète cosmopolite. Autant s’y mettre tout de suite.</p> | |||
| <p class="TX"><strong>Sur la piste animale Baptiste Morizot Actes Sud, 208 pages, 20 euros</strong></p> | |||
| </article> | |||
| <hr> | |||
| <footer> | |||
| <p> | |||
| <a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home"> | |||
| <use xlink:href="/static/david/icons2/symbol-defs.svg#icon-home"></use> | |||
| </svg> Accueil</a> • | |||
| <a href="/david/log/" title="Accès au flux RSS"><svg class="icon icon-rss2"> | |||
| <use xlink:href="/static/david/icons2/symbol-defs.svg#icon-rss2"></use> | |||
| </svg> RSS</a> • | |||
| <a href="http://larlet.com" title="Go to my English profile" data-instant><svg class="icon icon-user-tie"> | |||
| <use xlink:href="/static/david/icons2/symbol-defs.svg#icon-user-tie"></use> | |||
| </svg> Pro</a> • | |||
| <a href="mailto:david%40larlet.fr" title="Envoyer un courriel"><svg class="icon icon-mail"> | |||
| <use xlink:href="/static/david/icons2/symbol-defs.svg#icon-mail"></use> | |||
| </svg> Email</a> • | |||
| <abbr class="nowrap" title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340"><svg class="icon icon-hammer2"> | |||
| <use xlink:href="/static/david/icons2/symbol-defs.svg#icon-hammer2"></use> | |||
| </svg> Légal</abbr> | |||
| </p> | |||
| <template id="theme-selector"> | |||
| <form> | |||
| <fieldset> | |||
| <legend><svg class="icon icon-brightness-contrast"> | |||
| <use xlink:href="/static/david/icons2/symbol-defs.svg#icon-brightness-contrast"></use> | |||
| </svg> Thème</legend> | |||
| <label> | |||
| <input type="radio" value="auto" name="chosen-color-scheme" checked> Auto | |||
| </label> | |||
| <label> | |||
| <input type="radio" value="dark" name="chosen-color-scheme"> Foncé | |||
| </label> | |||
| <label> | |||
| <input type="radio" value="light" name="chosen-color-scheme"> Clair | |||
| </label> | |||
| </fieldset> | |||
| </form> | |||
| </template> | |||
| </footer> | |||
| <script> | |||
| function loadThemeForm(templateName) { | |||
| const themeSelectorTemplate = document.querySelector(templateName) | |||
| const form = themeSelectorTemplate.content.firstElementChild | |||
| themeSelectorTemplate.replaceWith(form) | |||
| form.addEventListener('change', (e) => { | |||
| const chosenColorScheme = e.target.value | |||
| localStorage.setItem('theme', chosenColorScheme) | |||
| toggleTheme(chosenColorScheme) | |||
| }) | |||
| const selectedTheme = localStorage.getItem('theme') | |||
| if (selectedTheme && selectedTheme !== 'undefined') { | |||
| form.querySelector(`[value="${selectedTheme}"]`).checked = true | |||
| } | |||
| } | |||
| const prefersColorSchemeDark = '(prefers-color-scheme: dark)' | |||
| window.addEventListener('load', () => { | |||
| let hasDarkRules = false | |||
| for (const styleSheet of Array.from(document.styleSheets)) { | |||
| let mediaRules = [] | |||
| for (const cssRule of styleSheet.cssRules) { | |||
| if (cssRule.type !== CSSRule.MEDIA_RULE) { | |||
| continue | |||
| } | |||
| // WARNING: Safari does not have/supports `conditionText`. | |||
| if (cssRule.conditionText) { | |||
| if (cssRule.conditionText !== prefersColorSchemeDark) { | |||
| continue | |||
| } | |||
| } else { | |||
| if (cssRule.cssText.startsWith(prefersColorSchemeDark)) { | |||
| continue | |||
| } | |||
| } | |||
| mediaRules = mediaRules.concat(Array.from(cssRule.cssRules)) | |||
| } | |||
| // WARNING: do not try to insert a Rule to a styleSheet you are | |||
| // currently iterating on, otherwise the browser will be stuck | |||
| // in a infinite loop… | |||
| for (const mediaRule of mediaRules) { | |||
| styleSheet.insertRule(mediaRule.cssText) | |||
| hasDarkRules = true | |||
| } | |||
| } | |||
| if (hasDarkRules) { | |||
| loadThemeForm('#theme-selector') | |||
| } | |||
| }) | |||
| </script> | |||
| </body> | |||
| </html> | |||
+ 36
- 0
cache/2021/9d1a6e44ba8805d53071ba461df238b0/index.md
View File
| @@ -0,0 +1,36 @@ | |||
| title: Baptiste Morizot : « L’animalité est constitutive de notre identité dans ce qu’elle a de sain « | |||
| url: https://www.humanite.fr/baptiste-morizot-lanimalite-est-constitutive-de-notre-identite-dans-ce-quelle-de-sain-658797 | |||
| hash_url: 9d1a6e44ba8805d53071ba461df238b0 | |||
| <p><strong>Comment avez-vous découvert le pistage et comment le définissez-vous ? C’est à la fois une pratique de terrain et un concept philosophique…</strong></p> | |||
| <p> </p> | |||
| <p><strong>Baptiste Morizot : </strong> J’avais le sentiment qu’il était nécessaire de vivifier la pensée par des pratiques de terrain, au contact des vivants sur lesquels je réfléchissais. Et cette expérience a modifié certains aspects de ma recherche : ma méthode philosophique s’est métissée de pistage, d’attention aux signes et indices. Quant à le définir: d’abord il faut comprendre que le pistage est pour moi complètement désarticulé de la chasse : cela n’a rien à voir. Le « pistage philosophique» qui m’intéresse est plutôt de se rendre sensible à la manière dont les autres vivants habitent avec nous ce monde, pour inventer des formes de cohabitation plus riches et plus vivables pour tous. Je le définirai donc comme une manière renouvelée d’être attentif aux vivants. Sans nier l'existence de conflits potentiels et de rapports de force, mais avec pour mission de mettre en place un modus vivendi aussi pacifié que possible. Ce que j’aime dans cette affaire, c’est qu’il s’agit d’une pratique dans laquelle on est sorti de l’opposition entre pensée et sensibilité, entre théorie et pratique : dans le pistage, pour interpréter les indices laissés par un cerf, une panthère des neiges ou un loup, on tisse de manière très serrée les sens, l’intuition, l’imagination, et le raisonnement, le tout pour chercher un état d’attention très aiguisé, vibratile, à ce qui se passe autour. Les couples d'oppositions héritées de la Modernité sont bien loin.</p> | |||
| <p> </p> | |||
| <p><strong>Comment se former au pistage ? </strong></p> | |||
| <p> </p> | |||
| <p><strong>Baptiste Morizot :</strong> Cela n’exige aucune forme d’expertise, il suffit d’un peu d’entrainement. On ouvre l’espace du visible et du sensible petit à petit. Tous ces paysages où « on n’y voit rien » se peuplent d’indices, de signes, de présences, de relations. J’ai appris récemment qu’un oiseau de chez nous, le rouge-queue à front blanc, est assez fascinant: lorsqu’il migre au sud du Sahara, il est capable sur place d’apprendre la langue des passereaux chanteurs autochtones, pour négocier avec eux son territoire saisonnier. C’est un oiseau diplomate, dont les facultés de communication, de négociation pour travailler à des modus vivendi entre étrangers, étaient insoupçonnées. De même, il existe dans nos jardins des orchidées qui échangent des molécules de sucres avec des érables, par le biais du mycorhize souterrain qui les relie, en fonction de la période de l’année où chacun en a le plus besoin. Être sensible à cela, en croisant savoir et curiosité sur le terrain, produit une métamorphose de la disponibilité. Nous en avons besoin pour retisser des affiliations envers ces formes de vie qui sont nos parentes. Car cela s’étend aux végétaux, aux insectes, aux forêts et aux rivières, comme aux friches urbaines. Il faut réapprendre à partager la Terre avec tous ces vivants que nous avions rendus invisibles, en les considérant comme des automates ou de la matière inerte. </p> | |||
| <p> </p> | |||
| <p><strong>Vous parlez des animaux « diplomates », vous leur avez consacré un ouvrage en prenant l’exemple des loups. Quel est le sens de cette diplomatie ?</strong></p> | |||
| <p> </p> | |||
| <p><strong>Baptiste Morizot :</strong> C’est un certain rapport à l’autre. Nous héritons de la tradition occidentale l’idée que les vivants sont des choses, de la matière à gérer quantitativement, ou à mater par le rapport de force, où encore à sanctuariser dans des réserves microscopiques. Dès lors qu’on prend au sérieux ce que disent l’éthologie et l’écologie scientifique contemporaines (sciences subversives par excellence, qui ébranlent les conceptions scientistes du monde), il devient évident que les vivants ne sont pas des choses mais des êtres et des agents. Bien entendu, ils ne signent pas de traités, ni ne discutent comme nous le faisons, mais ils ont leurs modes de communication, et des manières de composer ensemble sur un même territoire, de réduire l’agressivité mutuelle entre espèces et entre individus. Ce sont déjà des formes de diplomatie, en un sens minimal. Mais surtout, ces communications, ces comportements, ces manières de créer des modus vivendi, sont encore largement ignorées (du fait même qu’on a postulé qu’elles n’existaient pas dans la nature). Face à des êtres aux mœurs inconnues, aux langages inaccessibles, qui faut-il envoyer ? Des diplomates, au sens de ces explorateurs pacifiques (il y en a eu) qui sont allés au-devant d’autres peuples pour apprendre leurs manières de penser, de communiquer, et de faire territoire. Cela pour jouer le rôle d’interprète et de truchement envers eux, entre eux et nous, et essayer d’imaginer des codes communs pour cohabiter malgré les conflits. C’est ce que j’essaie de penser concrètement avec les loups dans mon livre. Ces animaux, bien qu'on les fantasme comme des fauves assoiffés de sang, sont puissamment géopolitiques : les meutes entre elles, par exemple, respectent les frontières d'odeur des autres meutes. Enfin ils apprennent vite lorsqu'on leur envoie vigoureusement les bons messages. Toute la question est : par quels modes de communications les plus efficaces peut-on les détourner des troupeaux, dont ils n'ont pas besoin pour se nourrir ?</p> | |||
| <p> </p> | |||
| <p><strong>La nature est largement domestiquée, exploitée, quadrillée par l’homme. Comment penser la cohabitation que vous appelez de vos vœux à l’ère de l’anthropocène ?</strong></p> | |||
| <p> </p> | |||
| <p><strong>Baptiste Morizot :</strong> Tout le problème revient à trouver des inspirations pour penser de manière pertinente et émancipatrice la cohabitation. On peut en trouver dans l’histoire des relations entre les peuples humains étrangers. Le modèle qui m’intéresse, plus que celui de la colonisation brutale qui a été la norme de l’histoire européenne, ce sont ces rares cas de rencontres entre peuples où, pour des raisons historiques, il a été nécessaire de faire de la diplomatie et de cohabiter. C’est par exemple ce qui a eu lieu en partie dans la région des Grands Lacs, entreAmérindiens algonquins et colons français au 18ème siècle : c’est ce que l’historien Richard White appelle un « middle ground », c’est-à-dire un terrain commun entre des peuples qui n’ont pas le même langage, pas les mêmes lois, qui ne se reconnaissent d’ailleurs pas mutuellement le statut d’humains ou de personnes morales, mais qui doivent apprendre à communiquer et à cohabiter dans des territoires partagés. Richard White isole les conditions historiques qui font qu’une relation entre peuples, qui pourrait être brutale et impérialiste, devient diplomatique : schématiquement, cela advient lorsque les êtres en présence sont dans une relation de vulnérabilité mutuelle.</p> | |||
| <p> </p> | |||
| <p><strong>Comment appliquer ces travaux à nos relations avec la nature ?</strong></p> | |||
| <p> </p> | |||
| <p><strong>Baptiste Morizot : </strong>Mon raisonnement est simple : les rapports concernant l’état de la biodiversité et des dynamiques écologiques actuelles montrent que nos activités les ont ébranlées au point de les rendre instables et fragiles, mais aussi que nous avons besoin d’elles pour maintenir nos vies. La fragilisation des pollinisateurs est un problème majeur pour tout le maraîchage européen, comme la destruction de la vie des sols par l’agriculture productiviste à intrants fragilise nos conditions de vie futures. Nous sommes donc bien dans une situation de vulnérabilité mutuelle. C’est une situation qui appelle le "middle ground" diplomatique envers les vivants : il nous faut des diplomates abeilles pour comprendre ce dont elles ont besoin pour cohabiter parmi nous, comme il nous faut des agents pour faire de la diplomatie avec la microfaune fascinante des sols.</p> | |||
| <p> </p> | |||
| <p><strong>On assiste depuis quelque temps à des débats virulents sur le véganisme, sur les droits des animaux... La relation de l’homme avec le monde animal est-elle, selon vous, l’un des grands enjeux du XXIe siècle ? </strong></p> | |||
| <p> </p> | |||
| <p><strong>Baptiste Morizot : </strong>indépendamment de la question du traitement du bétail (qui n’est qu’une fraction des l’animalité), la grande violence invisible de notre civilisation est d’avoir fait des animaux des figures pour les enfants. S’y intéresser serait alors de la sensiblerie. Notre rapport à l’animalité et aux animaux est infantilisée, primitivisée, exotisée, alors qu’elle est constitutive de notre identité dans ce qu’elle a de sain. Les animaux ne sont pas seulement des peluches ou les objets de notre indignation morale. Nous partageons avec eux une ascendance. L’animal est un intercesseur privilégié avec l’énigme originelle, celle de notre manière d’être vivant. Il manifeste une altérité incompressible et en même temps il est assez proche de nous pour que mille formes de parallèles et de convergences soient sensibles, avec les mammifères, les oiseaux, les pieuvres, jusqu’aux insectes. Les bactéries, et souvent les végétaux, sont plus loin dans notre généalogie commune. Ils sont des parents si étrangers qu’il est moins facile de se sentir vivants comme eux : cela exige des passeurs. Les animaux, du fait de leur position liminaire, sont alors des intercesseurs.</p> | |||
| <p> </p> | |||
| <p><strong>Quelles leçons politiques pouvons-nous tirer du pistage? Comment peut-il nous aider à produire du collectif, du dialogue, du débat ? </strong></p> | |||
| <p> </p> | |||
| <p><strong>Baptiste Morizot : </strong>Une part décisive mais discrète du politique se joue dans les déplacements des seuils et des passages qui commandent l’attention. Par exemple, la question des rapports inégalitaires entre hommes et femmes a connu des déplacements dans les dernières décennies, grâce aux mobilisations féministes, et elle est conséquemment devenue un astre qui attire beaucoup d’attention politique. La question du travail aliéné et des rapports capital/travail, la la condition de ceux qui ne possèdent pas les moyens de production mais vendent leur force de travail, naturalisée dans le premier capitalisme, est devenue avec Marx un objet des plus vigoureuses attentions politiques. Les bougés dans l’art de l’attention d’un collectif humain se manifestent par un symptôme éloquent : le sens du tolérable et de l’intolérable. C’est une machine délicate, instruite par des flux sociaux et culturels. Par exemple, la monarchie de droit divin nous est devenue intolérable. </p> | |||
| <p> </p> | |||
| <p><strong>Comment cette notion de seuil du tolérable et de l’intolérable peut-elle modifier notre rapport au vivant ? </strong></p> | |||
| <p> </p> | |||
| <p><strong>Baptiste Morizot : </strong>Au sens où l’idée de disparition des oiseaux des champs, des insectes européens, à cause de notre cécité, de nos pratiques de productions aveugles, doit nous devenir intolérable. Dans mon livre, j’essaie de contribuer à cela, à petite échelle, par des récits qui préparent des rencontres possibles avec des animaux, auxquels on prête de nouveau attention : ils entrent dans le champ de l'attention politique. Ces rencontres nous font accéder à une forme de soi élargi. Je me souviens d’un passager du train qui regardait avec anxiété un ciel pluvieux de printemps par la fenêtre. Lorsqu’il me révéla la raison de sa préoccupation, je suis resté muet. Il m’annonça : « Les printemps pluvieux me préoccupent, ils sont mauvais pour les chauve-souris et leurs nouveaux-nés. Il y a beaucoup moins d’insectes. » Un soi élargi dans lequel les autres vivants emménagent, c’est certes quelques préoccupations de plus, mais c’est aussi étrangement émancipateur. Ce n’est qu’ensuite, et non parce qu’on a culpabilisé chacun par l’annonce quotidienne des apocalypses actuelles, que le système des valeurs de base se transforme. Pour changer le politique, il faut aussi (parallèlement à militer, désobéir, lancer l’alerte, et faire levier au plus près du pouvoir) transformer la culture. C’est un truisme. Regardez ce que la médiatisation de Notre-Dame des Landes a fait, comment les lignes architectoniques de la sensibilité bougent. C’est un travail de longue haleine, mais il mérite d’être fait, parce que nous vivants avons encore quelques millénaires à vivre ensemble sur cette planète cosmopolite. Autant s’y mettre tout de suite.</p> | |||
| <p class="TX"><strong>Sur la piste animale Baptiste Morizot Actes Sud, 208 pages, 20 euros</strong></p> | |||
+ 4
- 0
cache/2021/index.html
View File
| @@ -151,6 +151,8 @@ | |||
| <li><a href="/david/cache/2021/4121412b765fff38f76943b7bc6391a5/" title="Accès à l’article dans le cache local : Stumbling">Stumbling</a> (<a href="https://lucybellwood.com/stumbling/" title="Accès à l’article original distant : Stumbling">original</a>)</li> | |||
| <li><a href="/david/cache/2021/862d065d924906f327f8a95e23659295/" title="Accès à l’article dans le cache local : The small web is beautiful">The small web is beautiful</a> (<a href="https://benhoyt.com/writings/the-small-web-is-beautiful/" title="Accès à l’article original distant : The small web is beautiful">original</a>)</li> | |||
| <li><a href="/david/cache/2021/a722bf15647dfe923d3c28b2e229098c/" title="Accès à l’article dans le cache local : The Future of Web Software Is HTML-over-WebSockets">The Future of Web Software Is HTML-over-WebSockets</a> (<a href="https://alistapart.com/article/the-future-of-web-software-is-html-over-websockets/" title="Accès à l’article original distant : The Future of Web Software Is HTML-over-WebSockets">original</a>)</li> | |||
| <li><a href="/david/cache/2021/fd776407232cd6fd7627bac7dba39755/" title="Accès à l’article dans le cache local : Épuiser la pratique">Épuiser la pratique</a> (<a href="https://www.quaternum.net/2020/02/29/epuiser-la-pratique/" title="Accès à l’article original distant : Épuiser la pratique">original</a>)</li> | |||
| @@ -185,6 +187,8 @@ | |||
| <li><a href="/david/cache/2021/59bd3fea3b3b370bd6b116e77effb69e/" title="Accès à l’article dans le cache local : Nostalgie de l'ancien web">Nostalgie de l'ancien web</a> (<a href="https://osd.ovh/index.php?article10/nostalgie-de-lancien-web" title="Accès à l’article original distant : Nostalgie de l'ancien web">original</a>)</li> | |||
| <li><a href="/david/cache/2021/9d1a6e44ba8805d53071ba461df238b0/" title="Accès à l’article dans le cache local : Baptiste Morizot : « L’animalité est constitutive de notre identité dans ce qu’elle a de sain «">Baptiste Morizot : « L’animalité est constitutive de notre identité dans ce qu’elle a de sain «</a> (<a href="https://www.humanite.fr/baptiste-morizot-lanimalite-est-constitutive-de-notre-identite-dans-ce-quelle-de-sain-658797" title="Accès à l’article original distant : Baptiste Morizot : « L’animalité est constitutive de notre identité dans ce qu’elle a de sain «">original</a>)</li> | |||
| <li><a href="/david/cache/2021/75d7cccf22ce15ad026621e8e753d65b/" title="Accès à l’article dans le cache local : Comment fonctionne une centrale nucléaire ?">Comment fonctionne une centrale nucléaire ?</a> (<a href="https://couleur-science.eu/?d=268bbb--comment-fonctionne-une-centrale-nucleaire" title="Accès à l’article original distant : Comment fonctionne une centrale nucléaire ?">original</a>)</li> | |||
| <li><a href="/david/cache/2021/0c6966a8e9543b52c361ac6de68f08e4/" title="Accès à l’article dans le cache local : Understanding ProRAW">Understanding ProRAW</a> (<a href="https://blog.halide.cam/understanding-proraw-4eed556d4c54" title="Accès à l’article original distant : Understanding ProRAW">original</a>)</li> | |||
Loading…