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.

↗ ped.ro

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.

↗ blog.nateliason.com

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"]
}

↗ php.watch