I'm excited to share that I've been invited to display three of my Touchless Interfaces paintings at a show with the Wave Collective, along-side 8 other great artists in their curated exhibition "Shapes and Bodies".

The exhibition will be open at Wave Collective Space, 440 Haight St, San Francisco, from August 4th to September 16th 2023.

There's an opening reception at the gallery on the 4th August between 6 - 9pm, which I'll be in attendance at. Come say hi!

A short & sweet overview of get(), cursor(), chunk(), and lazy() to retrieve models from the database. It's a tradeoff between speed and memory usage.

Just a Twitter account I've been enjoying lately. Small worlds posts a tiny sci-fi story every day (with lovely visuals!)

Follow @smllrworlds on Twitter.

You have likely participated in several Devographics surveys before, such as State of CSS, or State of JS. These surveys have become the primary source of unbiased data for the practices of front-end developers today (there is also the Web Almanac research, but because this studies what is actually used on the web, it takes a lot longer for changes in developer practices to propagate).

You may remember that last summer, Google sponsored me to be Survey Design Lead for State of CSS 2022. It went really well: we got 60% higher response rate than the year before, which gave browsers a lot of actionable data to prioritize their work. The feedback from these surveys is a prime input into the Interop project, where browsers collaborate to implement the most important features for developers interoperably.

So this summer, Google trusted me with a much bigger project, a brand new survey: State of HTML!

For some of you, a State of HTML survey may be the obvious next step, the remaining missing piece. For others, the gap this is filling may not be as clear. No, this is not about whether you prefer <div> or <span>! It turns out, just like JavaScript and CSS, HTML is actually going through an evolution of its own! New elements like <selectmenu> and <breadcrumb> are on the horizon, or cool new features like popovers and declarative Shadow DOM. There are even JS APIs that are intrinsically tied to HTML, such as e.g. Imperative slot assignment or DOM APIs like input.showPicker() Historically, these did not fit in any of these surveys. Some were previously asked in State of JS, some in State of CSS, but it was always a bit awkward. This new survey aims to fill these gaps, and finish surveying the core technologies of the Web, which are HTML, CSS and JavaScript.

Designing a brand new survey is a more daunting task than creating the new edition of an existing survey, but also an exciting one, as comparability with the data from prior years is not a concern, so there is a lot more freedom.

Each State of X survey consists of two parts: Part 1 is a quiz: a long list of lesser-known and/or cutting-edge (or even upcoming) features where respondents select one of three options:

Starting with State of CSS 2022, respondents could also add freeform comments to provide more context about their answer through the little speech bubble icon. One of my goals this year is to make this feature quicker to use for common types of feedback, and to facilitate quantitative analysis of the responses (to some degree).

At the end of the survey, respondents even get a knowledge score based on their answers, which provides immediate value and motivation which reduces survey fatigue.

Part 2 is more freeform, and usually includes multiple-choice questions about tools and resources, freeform questions about pain points, and of course, demographics.

One of the novel things I tried in the 2022 State of CSS survey was to involve the community in the design process, with one-click voting for the features to ask about. These were actually GitHub Issues with certain labels. Two years prior I had released MaVoice: an app to facilitate one click voting on Issues in any repo, and it fit the bill perfectly here.

This process worked exceptionally well for uncovering blind spots: it turned out there were a bunch of CSS features that would be good to ask about, but were simply not on our radar. This is one of the reasons I strongly believe in transparency and co-design: no one human or small team can ever match the collective intelligence of the community.

Predictably, I plan to try the same approach for State of HTML. Instead of using MaVoice, this year I’m trying GitHub Discussions. These allow one click voting from the GitHub interface itself, without users having to authorize a separate app. They also allow for more discussion, and do not clutter Issues, which are better suited for – well – actual issues.

I have created a Discussions category for this and seeded it with 55 features spanning 12 focus areas (Forms & Editing, Making Web Components, Consuming Web Components, ARIA & Accessibility APIs, Embedding, Multimedia, Interactivity, Semantic HTML, Templating, Bridging the gap with native, Performance, Security & Privacy). These initial ideas and focus areas came from a combination of personal research, as well as several brainstorming sessions with the WebDX CG.

Vote on Features for State of HTML 2023!

You can also see a (read-only) summary of the proposed features with their metadata here though keep in mind that it’s manually updated so it may not not include new proposals.

If you can think of features we missed, please post a new Discussion in this category. There is also a more general 💬 State of HTML 2023 Design category, for meta-discussions on Part 1 of the survey, and design brainstorming on Part 2.

Some things to keep in mind when voting and generally participating in these discussions:

• The votes and proposals collected through this process are only one of the many variables that feed into deciding what to ask about, and are non-binding.
• There are two goals to balance here:
  1. The survey needs to provide value to developers – and be fun to fill in!
  2. The survey needs to provide value to browsers, i.e. get them actionable feedback they can use to help prioritize what to work on. This is the main way that these surveys have impact on the web platform, and is at least as important as (1).
• While the title is “State of HTML”, certain JS APIs or even CSS syntax is also relevant, especially those very close to HTML, such as DOM, ARIA, Web Components, PWAs etc.
• Stable features that have existed for a long time and are widely known are generally less likely to make it to the survey.

Now go vote! 🗳

When building a CRUD interface in an event sourced system, you'll come across the dilemma of how granular your events should be. Should you have a large PostUpdated event, or granular TitleUpdated, ContentUpdated, and AuthorUpdated events?

The main benefit of single, large events are how straightforward they are. Little code required. One event, one method on the aggregate root, one projector.

Besides that, granular events win.

Large events store unnecessary data. A single event always stores all data, even when unchanged. If I update a post's title, the PostUpdated event will contain the content and author as well. Granular events only contain the data that changed.

Large events can be difficult to change. If you add a property, you need to ensure old events don't break when they're deserialized. Granular events change less often. You'd add a new event for a new property, or stop dispatching an event for an old one.

Large events are difficult to react to. If I want to react to a title change, the PostUpdated event is not enough, as I don't know if the title actually changed. To know whether something changed, you need to query the current state in the aggregate root or projections. Granular events are only dispatched when something changed.

If the data is not critical or most importantly you don't plan to react to, large events are fine. Otherwise, granular events are the more versatile choice.