Caddy (Revisited); [Observable] Plot (Redux); Neat (CSS)

Another day, another planned Drop gets the kibosh thanks to froody intraweek tech developments.

Observable gave one of my fav “new” datavis environments a new, gorgeous home, which means I have to talk about it. Said obligation required coming up with a new theme for the day. So, today, I make good on a recent promise, introduce yet-another super-simple CSS framework, and wax poetic about Observable Plot.

Caddy (Revisited)

I am sufficiently ancient of days enough that my pop-culture references can, and do, fall super flat sometimes. So, if you’re not familiar with Caddyshack, the Drop’s theme title is likely lost on you. But, I just cannot help using that movie as a backdrop when I think of the Caddy web server.

Back on April 4, I promised to re-visit the Caddy (GH) web server, so…I did!

Through a combination of events, including €20 in free credits — which I will repay, in kind, here in three months when I’m eligible for a referral code — I’m now the proud “owner” of yet-another digital Gotham-esque internet “safe house”1. I wanted to check out the performance of Hetzner‘s €3.29/month ARM Ampere VPS environments (2 vCPU/4GB RAM/40GB SSD/20TB traffic), and that desire dovetailed nicely with giving Caddy another go.

NOTE: You can 100% just do all this on your local system. Caddy is in all the package managers.

Despite being a massive Nginx fanboi, I may just be hooked on Caddy.

First up, the installation worked perfectly with zero glitches. These commands (provided by Caddy):

$ sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
$ curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo $ gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
$ curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
$ sudo apt update
$ sudo apt install caddy

had a Caddy server up and running on HTTP port 80 in mere seconds.

By default, Caddy’s control file in /etc/caddy/caddyfile has:

:80 {
  # rest of the very tiny config
}

and swapping out :80 with the domain name I created for this host (thats.hrbrmstr.dev):

thats.hrbrmstr.dev {
  # rest of the very tiny config
}

had Caddy deal with the SSL/TLS Let’s (dafly) Encrypt (everything) nonsense for me (also in seconds), giving me a fully armed, and operational2, web server to start playing with.

If you’re playing along on your local system, make a project directory, cd to it, use something like:

localhost:8080 {
  # set the root folder for serving documents from
  root * . 

  # tell Caddy we want to be just a boring webserver
  file_server 
}

run caddy run --watch (so it watches the config file for changes), then hit

https://localhost:8080

(yes, you get local TLS/SSL for free, too! You likely had to approve some admin-level auth prompts since Caddy stores its self-signed certificate in your system’s keystore) to test it out (mebbe have an index.html file to look at or use the repo I mention in the next section).

You can also launch it in the background with caddy serve, but I’d use run during development if I were you.

There are many ways to tweak, configure, and wield Caddy, and running caddy help will give you a tome to peruse.

The aforementioned caddyfile is an Nginx-esque configuration file format which the Caddy folks have gone overboard re: documentation. Their snippets concept is pretty neat, since they save you from repeating common configuration directives (if you have a complex setup).

Like Nginx, Caddy can also be a “reverse proxy” — i.e., it faces the scary, cruel user-facing network and then shunts the request to some back-end. And, you don’t even need a caddyfile. Just do something like caddy reverse-proxy --to :9000 and you have a fully functional redirector, front-ended with TLS/SSL for free (you can also do the same for just serving local files).

HTTP/3 support comes along for the ride for free (check it out in Developer Tools’ “Network” tab on thats.hrbrmstr.dev).

While the caddyfile configuration format is familiar, you can use the CLI to tweak the running config, or use a JSON file for it. Or, use what you like, since they support many config formats, including the evil YAML, for all the monsters out there.

Caddy is written in Golang, and you can extend it via modules. There are lots of modules in the Caddy ecosystem.

So, Caddy is:

• easier to setup than nginx or apache

• makes SSL/TLS painless

• supports modern HTTP protocols out-of-the-box

• meets you where you are config-format-wise

• has versatile configuration options

• sets up in seconds

Sorry, Nginx. I may never look back.

Hit up the basic demo site I rigged up for today’s Drop to see Caddy in action. Also: hit up the companion repo to see an example of the Caddy JSON configuration method.

P.S. Raw ChatGPT-4 is sadly horribly bad at converting nginx `conf` files to either `caddyfile` format or Caddy JSON config file format; BUT, Perplexity.ai is quite good at it.

Neat (CSS)

I wanted to put together a small website to help talk about both Caddy (previous section) and Plot (next section). Since I recently came across neat, a tiny CSS framework that will have you up and running with a good-looking basic site in no time, I decided to use it for the demo.

This:

curl -O https://neat.joeldare.com/neat.css
curl -O https://neat.joeldare.com/neat.html

gets you up and running with “neat” in no time.

This minimalist CSS framework is designed to help developers build efficient websites. It was created by Joel Dare and inspired by other minimalist sites like Hundred Rabbits and similar blogs.

The framework is tiny, opinionated, and “made to last”, with a size of ~2Kb. Neat was designed for blogs, journals, technical sites, documentation, books, and simple shops.

It’s easy to customize by creating a new custom.css file (check out the one in the companion repo for this Drop) and adding a <link> to the <head> of the page.

Neat’s design decisions center around being small, low energy, long-lasting, not minified, and having a max-width of 800px by default. The <body> is also centered by default, and images are 100% width with no border.

This micro-framework is responsive and has a simple grid system that automatically sizes each column.

Observable Plot (next section) worked really well in it, too.

[Observable] Plot (Redux)

While first introduced in Observable Notebooks, Plot works just fine outside of both those notebooks and without the Observable runtime.

Plot’s new home sports a modern look/feel, and consolidates + enhances all the technical documentation from the Plot repo

As you’ll see in the source for the demo site, this makes Plot available to any web page (this also shows how to add a Plot to the DOM):

<script type="module">
<div id="myplot"></div>
<script type="module">

import * as Plot from "https://cdn.jsdelivr.net/npm/@observablehq/plot@0.6/+esm";

const plot = Plot.rectY({length: 10000}, Plot.binX({y: "count"}, {x: Math.random})).plot();
const div = document.querySelector("#myplot");
div.append(plot);

</script>

The new documentation site covers all the features:

• Plots

• Marks

• Scales

• Projections

• Transforms

• Facets

• Legends

• Curves

• Formats

• Markers

• Shorthand

• Accessibility

all the “marks” (“geoms” for R folks):

• Area

• Arrow

• Auto

• Axis

• Bar

• Box

• Cell

• Contour

• Delaunay

• Density

• Dot

• Frame

• Geo

• Grid

• Hexgrid

• Image

• Line

• Linear Regression

• Link

• Raster

• Rect

• Rule

• Text

• Tick

• Tree

• Vector

and all the “transforms” (“stat” and “position” for R folks):

• Bin

• Centroid

• Dodge

• Filter

• Group

• Hexbin

• Interval

• Map

• Normalize

• Select

• Sort

• Stack

• Tree

• Window

with rich, easy-to-follow examples.

In their own words:

Observable Plot is for exploratory data visualization. It’s for finding insights quickly. Its API, while expressive and configurable, optimizes for conciseness and memorability. We want the time to first chart to be as fast as possible.

And the speed doesn’t stop there: Plot helps you quickly pivot and refine your views of data. Our hope with Plot is that you’ll spend less time reading the docs, searching for code to copy-paste, and debugging—and more time asking questions of data.

Compared to other visualization tools, including low-level tools such as D3 and less expressive high-level tools such as chart templates, we think you’ll be more productive exploring data with Plot. You’ll spend more time “using vision to think” and less time wrangling the machinery of programming.

Or put more simply: with Plot, you’ll see more charts.

My demo site shows off two Plots: one that just renders some text in a responsive SVG, and another that re-creates one of the ggplot2 facet_wrap examples.

If I have a datavis targeting the web, my default is now Plot. And, in my highly opinionated view, folks who are looking to play with WebR should strongly consider having Plot be the go-to datavis framework unless you like slowing down initial page load.3

FIN

Methinks I may have to weave Plot into the WPE tomorrow. ☮