This in-depth article offers valuable insights and practical tips for web designers and website owners.

I’m now running pi-hole through my Raspberry Pi 2b. It’s both amazing and depressing just how many trackers are being blocked by it. I even noticed a regular ping being made to an Amazon endpoint exactly every 10 minutes. I will try and write up my set up soon, which is a mix of setting […]

On Twitter I came across a great tip on displaying empty states with CSS.

When you're rendering a list, I often wrap a loop in an if/else statement to display an empty state when the list is empty.

<section>
    @if($events->isNotEmpty())
        @foreach($events as $event)
            <article>
                {{ $event->name }}
            </article>
        @endforeach
    @else
        <p>No events created yet!</p>
    @endif
</section>

If you want to reduce nesting and drop the conditional, here's a smart trick with the :only-child selector to display the message when there are no events.

<section>
    @foreach($events as $event)
        <article>
            {{ $event->name }}
        </article>
    @endforeach
    <p>
        No events created yet!
    </p>
</section>

section > p {
  display: none;
}
 
section > p:only-child {
  display: block;
}

We hide the message, but when it's the only child in the section, we'll display it. Since there are no other children, we know there are no events.

Using Tailwind

Using Tailwind, we can use the only: variant to do the same.

<section>
    @foreach($events as $event)
        <article>
            {{ $event->name }}
        </article>
    @endforeach
    <p class="hidden only:block">
        No events created yet!
    </p>
</section>

---

PS: Extra goodie for Laravel devs: another way to do this is with the lesser-known @forelse Blade directive.

<section>
    @forelse($events as $event)
        <article>
            {{ $event->name }}
        </article>
    @empty
        <p class="hidden only:block">
            No events created yet!
        </p>
    @endforelse
</section>

I love this description of the Go programming language from Rob Napier:

Go feels under-engineered because it only solves real problems. If you've ever worked in a wood shop, you've probably made a jig at some point. They're little pieces of wood that help you hold plywood while you cut it, or spacers that tell you where to put the guide bar for a specific tool, or hold-downs that keep a board in place while you're working on it. They're not always pretty. They often solve hyper-specific problems and work only with your specific tools. And when you look at ones that have been used a lot, they sometimes seem a little weird. There might be a random cutout in the middle. Or some little piece that sticks off at an angle. Or the corner might be missing a piece. And when you compare them to “real” tools, “general” tools like you'd buy from a catalog, they're pretty homey or homely depending on how you're thinking about it.

But when you use one of them in your shop, you learn that the random cutout is because you store it against the wall and it would block the light switch otherwise. And if you put your hand on that little extra piece that sticks out, then the board won't fall at the end of the cut. And the corner… well the corner is where you messed up when you were first making it and it's kind of ugly, but it never actually matters when you use it. And that's Go.

↗ robnapier.net