As I’m refactoring an existing design system, this article by Elise Hein came quit timely.

We consider HTML to be cheap, but wrapping divs in divs in divs comes with a cost that slowly creeps up.

Why avoid extra wrapper elements?

1. Bloated html hurts performance
2. Redundant elements can create problems with accessibility
3. Redundant elements can break styling
4. Deeply nested dom trees are annoying to work with

When using whereHas in Laravel, it’s not uncommon to also eager load the relation using with.

$posts = Post::query()
    ->with('author')
    ->whereHas('author', function (Builder $query) {
        $query->where('name', 'Seb');
    })
    ->get();

Laravel also has a more succinct method that combines the two: withWhereHas.

$posts = Post::query()
    ->withWhereHas('author', function (Builder $query) {
        $query->where('name', 'Seb');
    })
    ->get();

Since this blog is a static site, I don’t have a server running to do something dynamic when I publish a new post. I was about to set up Zapier or IFTTT to auto-toot blog posts to Mastodon, until I realized I finally had a use case to give val.town a shot.

With val town you can write lambda-ish functions in a GitHub gist-ish interface. Single functions are called “vals”. The fun part is you can reference your own and other people’s vals, which creates a network of atomic actions you can stack like Lego blocks. Vals can be scheduled so you can use them as background services.

First I created a generic postToMastodon val to toot a status on Mastodon. Then I created a tootLatestPosts val that combines it with an existing @stevekrouse.newRssItems val, which fetches RSS items from a feed.

Finally, I scheduled tootLatestPosts to run every hour. Now posts from this blog automatically appear on my Mastodon profile!

I was building wireframes for a website with HTML & CSS. Since it’s a prototype, not all actions are functional. When a visitor reviewing the prototype tries to click something that isn’t hooked up, I wanted to clarify what they could interact with. This also allows visitors to click anywhere on the page to highlight what they can click.

In the past, I’ve used JavaScript to add an outline to clickable elements when something non-interactive was clicked. But with the :has and :is selectors, this is doable with plain CSS.

html:active:not(:has(a:active, button:active, label:active)) :is(a, button, label) {
  outline: 2px solid blue;
}

How it works:

• html:active will match whenever you hold down your mouse on the page
• :not(:has(a:active, button:active, label:active)) will not match when you’re holding down your mouse on an a, button, or label element, to avoid the outline from appearing when the user clicks something that is functional
• :is(a, button, label) matches all a, button, and label elements on the page

View a demo on CodePen.

I started using a hyper key on macOS. A hyper key is a single key mapped to Shift + Ctrl + Opt + Cmd. Since this isn’t exactly practical to pull off with your fingers, apps don’t use this combination for built-in shortcuts. This means you have a layer for custom shortcuts without worrying about clashes.

My hyper key is mapped to Caps Lock. I actually already use caps lock as an escape key. Less travel than reaching for Esc with your pinky! Thanks to Karabiner Elements and Brett Terpstra’s guide I was able to remap it as Esc and a hyper key.

When I give Caps Lock a short tap, it functions as Esc. If I hold it and press another key, it functions as a hyper key, Shift + Ctrl + Opt + Cmd.

I still have a lot of room to map to, but for now I’m using my hyper key for a few global application shortcuts like Quick Entry in Things. In the future, I’m planning to map more Raycast commands too.

As I roam deeper into Svelte territory, I came across this talk from 2019 by Rich Harris, creator of Svelte.

Rich explains how he arrived at Svelte’s reactivity from first principles, swimming against the virtual-DOM stream other frameworks follow.

Despite being from 2019, it’s still relevant. Even if you’re not into Svelte, it’s worth watching as a great standalone talk.

Timeless advice from Derrick Reimer:

Not all projects are inherently small, but you can always break them down into smaller chunks. […]

Each incremental task brought us one step closer to a functioning v1. By shipping these tiny branches to production as we go, we became increasingly confident in the “bones” of the feature. As soon as a slice of the project was ready to test, the whole team hammered on it in production – an effective way to tease out bugs and rough spots in the user experience.

Set Studio—founded by Andy Bell—has a new website.

Aside from the good looks, it’s refreshing to see a page of that size to load and feel so fast.

Crypto, AI, JavaScript frameworks,… are interesting tech, but that doesn’t mean they need to be shoehorned into every product.

Set a direction, and choose the tools you’ll need to get there. Don’t choose a direction based on the tools in your disposal.

… by chasing trends we would never be the ones to set them.

For the past few months, I’ve been experimenting with Svelte & SvelteKit. Svelte peaked my interest because it’s a tool molded by the web. A lot of Svelte APIs piggyback on existing web affordances like plain HTML and CSS variables.

Shorthex is a small app to transform 6-digit hex color codes to 3-digit codes. Here’s a quick overview of the features of Svelte I enjoyed using.

Read more

Putting this in a blog post because I always forget.

To view PHP logs from Laravel Valet:

open ~/.config/valet/Log/php-fpm.log

To view NGINX logs from Laravel Valet:

open ~/.config/valet/Log/nginx-error.log

When I’m working on a feature or refactor, I often leave @todo comments to remain in flow and deal with other points later.

I don’t mind committing them to my feature branch, as long as I work them away before merging in.

On large branches, it can be easy to forget about that todo I left in there a few days ago.

class PodcastController
{
    public function process(Podcast $podcast): void
    {
        $podcast->process();

        // @todo Broadcast event to trigger webhooks

        return $podcast;
    }

Before I merge, I pipe git diff into a grep call to scan for changes that include @todo.

git --no-pager diff main..feature-branch | grep -i "^\+[^$]*@todo"

+        // @todo Broadcast event to trigger webhooks

If you want to double check your changes before comitting, you can use the same command with git diff HEAD.

git --no-pager diff HEAD | grep -i "^\+[^$]*@todo"

Pouring this in a bash function

Here’s a quick bash function to scan for todos:

function todos() {
  git --no-pager diff ${1:"HEAD"} | grep -i "^\+[^$]*@todo"
}

Use it without an argument to look for todos you haven’t committed yet, or pass the revisions you want to compare between.

# Look at current changes
todos

# Look for todos added between main and feature-branch
todos main..feature-branch

In Laravel, you can register a class as a singleton to always resolve the same object.

However, you might want to build another instance of the class. You could manually construct the class without Laravel’s container, but if it has a bunch of dependencies it can be tedious.

With the build method, Laravel won’t resolve a registered instance of the class, but build a new one with the container.

// AppServiceProvider::register()
$this->app->singleton(MastodonClient::class);

// Resolve the singleton instance from the container
$mastodon = resolve(MastodonClient::class);

// Build a new instance
$anotherMastodon = app()->build(MastodonClient::class);

This can be useful when a Laravel package registers a class as a singleton but you need another instance.

This one’s permanently stored in my Pinboard — a conversation I had this morning triggered a re-read.

“A user is only part of one team”. Until we decide to add multi-team support, and the $user->team BelongsTo relation suddenly needs to be replaced in 50 places.

Golden advice from swyx:

It is a LOT easier to scale code from a cardinality of 2 to 3 than it is to refactor from a cardinality of 1 to 2.

Freek shares a few patterns we employ to let developers override behaviour in our packages.

One of the ways we keep maintenance burden low is by making our packages customizable. In this blog post, I’d like to cover some of our best tips to make a Laravel package easy to customize. Some of these tips will apply to regular projects as well.