I thouroughly enjoyed the walk through Pedro’s design process for his personal website. From where he drew inspiration, to live snapshots of the design’s iterations.

To repeat the words of Chris Coyier again:

Redesigning your personal website is one of life’s great pleasures.

The latest edition of Matthias Ott’s Own Your Web (which I recommend subscribing to!) points out that there are a lot of blogs out there, but they can be hard to discover. As a vessel to help others discover blogs, Matthias recommends curating a blogroll.

Blogrolls are great. I have one too! But I don’t think they’re enough. The visibility of a blogroll is limited to people that visit your blog and are curious enough to poke around. The content of a blogroll is limited to blogs you consistently follow, but individual posts are worth sharing too.

Lots of blogs do this: Chris Coyier occasionally shares links his thoughts intertwined, Freek’s blog is a mix of original articles and links, and I’ve come across a lot of unexpectedly interesting articles through larger blogs like Daring Fireball or Kottke. Some have a separate RSS feed for sharing content, like Jim Nielsen’s notes.

In the same edition of Own Your Web, Matthias shared a link to an article titled Curation is the last best hope of intelligent discourse. Joan Westenberg argues that with the rise of AI and algorithms, human curation is more important than ever.

Human curators can distinguish between nuanced arguments, recognise cultural subtleties, and evaluate the credibility of sources in ways that algorithms cannot. This human touch is essential for maintaining the integrity of our information ecosystem. It serves not only as a filter for quality but also as a signal for meaningful and trustworthy content amidst the overwhelming noise generated by AI systems.

Aside from its importance, an algorithm is not going to surprise you. I could listen to Spotify’s Discover Weekly recommendations all day, but my taste wouldn’t widen.

So, go forth and multiply content! Share what you find interesting, start a conversation, surprise your readers, and let the small web flourish!

A question I’ve gotten a few times after my talk or sharing Svelte by Example is which frontend framework I’d choose these days.

Here’s the good news: these days you can’t really go wrong with any of the major frameworks—at least from a technical perspective. React, Vue, Svelte, Angular… all have incredible teams, contributors & ecosystems backing them. Your frontend framework will not be the limiting factor of your architecture.

Choose a framework based on the non-technical needs of your team. If scaling up your team is important, React might make more sense because of its popularity on the job market. On the other hand, if your team hates the mental model of React, don’t feel pressured to use it regardless of its popularity. Choose your framework based on how it aligns with your team’s programming values, not performance needs. (Unless you’re building a Bloomberg terminal.)

My preference these days: I’m split between React & Svelte. (That is, when I’m working on a project I deem worthy of a JavaScript-heavy interface, for others I still prefer vanilla JS or Alpine.) I like them both because they each have a distinct direction. React is as JavaScript as a JavaScript framework can be, while Svelte stays as close to HTML & the DOM as possible. What they have in common is they’ve chosen a slice of the stack, and double down on enhancing it. I prefer tools with distinct directions.

Nat Eliason writes about how we’re making it hard for ourselves to become happy by reducing activities to hyper-focussed but anemic versions of them.

We separate “I’m working” and “I’m playing.” We want to make everything extremely efficient, so we opt for going for a run alone instead of trying to link up with people along the way. We need to “be productive” so we don’t work from a coffee shop with friends.

Last week I was installing a mocking framework with Composer and got the following prompt:

$ composer require mockery/mockery
mockery/mockery is currently present in the require-dev key and you ran the command without the --dev flag, which will move it to the require key.
Do you want to move this requirement? [no]?

How cool! I didn’t know you could hint Composer to suggest a dependency to be installed as a testing dependency.

After further inspection, Composer determines this based on the tags used for the package

If you add dev, testing, or static analysis keywords to your package’s composer.json, Composer will prompt users to install it as a dev dependency.

{
  "name": "spatie/tabular-assertions",
  "keywords": ["testing"]
}

I haven’t really played around with the new :has selector in CSS yet, but this example from Chris Coyier piqued my interest.

With this query, you can dynamically filter a list with pure CSS!

body:has([name="filter"][value="bakery"]:checked)
  .card:not([data-category="bakery"]) {
  display: none;
}

An interesting retrospective on how CloudFlare migrated from Gatsby to Hugo for their docs. Build times for the static site were up to an hour (!) long. At some point, the performance of a tool can really become a bottleneck for your team.

This podcast episode was a great introduction to React server components. A balanced take—whether you’re drinking frontend koolaid or push to backend all the things.

(Mostly Technical has been great lately, Justin Jackson compiled a hilarious Mostly Technical x Seinfeld supercut.)

From Manuel Moreale’s lovely People & Blogs series interview with Chris Coyier:

Redesigning your personal website is one of life’s great pleasures.

Isn’t it? My fingers are itching.

From The Tao of Pooh:

Remember when Kanga and Roo came to the Forest? Immediately, Rabbit decided that he didn’t like them, because they were Different. Then he began thinking of a way to make them leave. Fortunately for everyone, the plan failed, as Clever Plans do, sooner or later. Cleverness, after all, has its limitations. Its mechanical judgments and clever remarks tend to prove inaccurate with passing time, because it doesn’t look very deeply into things to begin with. The thing that makes someone truly different — unique in fact — is something that Cleverness cannot really understand.

Think of this next time you write Clever Code.

Earlier this week, we tagged spatie/laravel-export v1. I wrote the bulk of this package 5 years ago. (Wow, I was surprised by this, time really does fly sometimes!) But I never tagged a stable version because I wanted to add more features. Instead, I chose the way of Arrakis and decided it was ready for a v1.

Laravel Export was inspired by Next.js. Next allows you to write your React app and access data on the server, to export it to a static site after. Next does this by crawling your routes. I built exactly this for Laravel using our crawler package. After configuring, you can run an artisan command to export your static site to a folder.

php artisan export

This is a great fit for websites you don’t want full blown hosting for but just want to drop on something like Vercel or Netlify. Docs & details in the repository!

A post on enums & interfaces. I didn’t realize you could implement an interface on an enum!

This way you get the best of both worlds: the default implementations are neatly grouped in an enum, but others can extend using their own class implementing the interface.

enum ColorOption: string implements Color
{
    case Red = 'red';
    case Blue = 'blue';
    case Green = 'green';

    public function name(): string 
    {
        return $this->value;
    }
}

Read more

Read more

Today I tagged v1 of a new testing package: spatie/tabular-assertions. It’s a distillation of a testing method I’ve been using in client projects the past two years. The package supports both PHPUnit and Pest out of the box.

With tabular assertions, you describe the expected outcome in a markdown-like table format.

expect($order->logs)->toLookLike("
    | type        | reason   | price | paid  |
    | product     | created  | 80_00 | 80_00 |
    | tax         | created  |  5_00 |  5_00 |
    | tax         | created  | 10_00 | 10_00 |
    | shipping    | created  |  5_00 |  5_00 |
    | product     | paid     |  0_00 |  0_00 |
    | tax         | paid     |  0_00 |  0_00 |
    | tax         | paid     |  0_00 |  0_00 |
    | shipping    | paid     |  0_00 |  0_00 |
");

Tabular assertions have two major benefits over other testing strategies: expectations are optimized for readability & failed assertions can display multiple errors at once.

For an in-depth introduction to tabular testing, I’ve written two separate guides for Pest & PHPUnit.

• Tabular assertions with Pest
• Tabular assertions with PHPUnit

Inspiration

I haven’t come across this exact method anywhere else, so I had to come up with a name. If there’s prior art that matches this with a better name, I’d love to know!

The idea was inspired by Jest, which allows you to use a table as a data provider.

Snapshot testing is also closely related to this. But snapshots aren’t always optimized for readability, are stored in a separate file (not alongside the test), and are hard to write by hand (no TDD).

Tabular assertions have been a huge help when comparing large, ordered data sets like financial data or a time series. I hope you find it useful too!