Standards are useful, but after a while they represent the beliefs of the past, not the needs of the future.

A good quote from Mathias Verraes on standards.

Thanks to my colleague Sam I recently learned about the form attribute on the <button> element.

By setting a form attribute, the button becomes a submit button for a form on the page with that ID, without having to nest the button on the page.

This could be useful for a logout link, used on different places.

<nav>
  <!-- … -->
  <button type="submit" form="logout">
    Log out
  </button>
</nav>
 
<footer>
  <!-- … -->
  <button type="submit" form="logout">
    Log out
  </button>
</footer>
 
<form id="logout" method="POST" action="/logout">
</form>
<nav>
  <!-- … -->
  <button type="submit" form="logout">
    Log out
  </button>
</nav>

<footer>
  <!-- … -->
  <button type="submit" form="logout">
    Log out
  </button>
</footer>

<form id="logout" method="POST" action="/logout">
</form>

If you’re going to read one thing today, make it this. So much good stuff in here I could quote just any paragraph.

complexity is spirit demon that enter codebase through well-meaning but ultimately very clubbable non grug-brain developers and project managers who not fear complexity spirit demon or even know about sometime […]

grug no able see complexity demon, but grug sense presence in code base

Rich Harris & the rest of the Svelte team have previously mentioned that they use TypeScript with JSDoc instead of .ts files. That gives TypeScript’s safety benefits during development and on CI, without an additional build step.

There are a few nuances to this, Pascal Schilp did a great job reviewing the background and benefits behind this decision.

When you define too much work up front, you add unnecessary management overhead. More importantly, you create a bias and stifle a team’s creativity to solve the problem.

No one defines all the work up front. That’s a fools errand. Assuming you know too much up front is the best way to find out you’re wrong in the end. Instead we define the direction, the purpose, the reason, and a few specific “must haves” up front. The rest — all the rest, which is mostly everything — is determined during the project, by the people on the project.

When you want to compare two database columns in Laravel, you can’t use where because it treats the argument you’re comparing to as a value.

Instead, Laravel has a whereColumn method you can use to compare a value to another column’s value.

// Retrieve posts that were updated after
// they were published.
 
Post::query()
    ->whereColumn('updated_at', '>', 'published_at')
    ->get();
// Retrieve posts that were updated after
// they were published.

Post::query()
    ->whereColumn('updated_at', '>', 'published_at')
    ->get();

Timeless advice from Freek & Brent.

Just like reading text, grouping code in paragraphs can be helpful to improve its readability. We like to say we add some “breathing space” to our code.

$page = $this->pages()->where('slug', $url)->first();
if (! $page) {
    throw new Exception();
}
$page = $this->pages()->where('slug', $url)->first();
if (! $page) {
    throw new Exception();
}

$page = $this->pages()->where('slug', $url)->first();
 
if (! $page) {
    throw new Exception();
}
$page = $this->pages()->where('slug', $url)->first();

if (! $page) {
    throw new Exception();
}

Just one line of space can make the difference.

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();
$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();
$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!