All my apps are running on a single OVH VPS. Knowing this, I couldn't setup a monitoring tool on the same infrastructure just in case of global failure.

Finding another hosting platform #

Having used Next.js a lot at my latest job, I deployed a lot of things on Vercel's platform. I also knew a free tier was available allowing hosting small apps with low traffic for personal use: a status checker app was the perfect use-case.

On top of that, a project specific CRONTAB allows for an easy task scheduling.

The API #

Next.js synergy with Vercel made me choose to spawn a minimalist Next.js app exposing a single /api/check endpoint.

When calling this route protected by a secret, a simple .json configuration file is parsed. From it, a collection of URLs to call is iterated over. On success, everything is fine, continue... On failure, a configurable number of retries is made. Definitive errors are listed inside a simple report sent via email through nodemailer alerting me of any app failure relatively fast. I couldn't think of a simpler solution.

Below the content of such an email:

The following endpoint failed health checks:Name: jeantinland.comURL: https://www.jeantinland.comAttempts: 3Timeout: 3000msChecked at: 2026-01-20T17:49:36.211ZError: HTTP 403 Forbidden

Triggering the checkup #

My first approach was simply to set up a repeating CRON task every hour of the day except the "Hobby" plan wouldn't allow more than a daily task. A status checker checking if things are working properly only one time a day isn't really useful. I'm not running critical services that need permanent observability but triggering a check every hour seemed the right amount to aim for when I imagined the solution.

The missing piece #

As the integrated CRONTAB wasn't an option, I first created a local CRON job on my laptop knowing well enough it was only a band aid as it was going to fail as soon as I close the lid off.

Then, it clicked.

The real need was to be able to send a GET request reliably every hour. And if my laptop isn't open all day long, my phone is.

Thanks to the "Automation" system available out of the box on iPhone, it is possible to do exactly so.

I created 15 identical tasks:

• When: "Every hour from 07:30AM to 09:30PM"
• Do: "Get contents of .../api/check?secret=xxx"

That's it.

Afterthought #

Looking at this setup, we can also think of eliminating the intermediate API and only use iOS shortcuts by creating an automation for each app to monitor and analyze the returned content in order to detect failures.

This approach would multiply the number of automations needed by a factor of the number of checks needed each across the day.

The API allows centralizing everything in a single place and handling check-up and retry logic.

Mind you all, I stumbled on the mdn documentation page, and there is more to this simple attribute.

When you declare an id attribute, the HTML element on which it is attached is automatically exposed on the global window object.

This allows for quick access to this element from anywhere in your page.

// Thisconst element = document.getElementById("myElementId");// Is equivalent toconst element = window.myElementId;

The only caveat is name collisions: your ìd attribute value must be a valid JavaScript identifier and must not collide with existing properties on the window object.

That said, we will work on the opposite here: how to implement the most basic accessible tooltip system in pure HTML/CSS. The title HTML attribute will not be covered, but that would in fact be the absolute winner in a "simplest tooltip system" contest.

If you want to skip the explanations and get directly to the code, head to the full CSS implementation section.

What do we need? #

Our system will leverage both the data-attributesHTML specification and the WAI standard. Meaning, a lot of aria-label and data-tooltip are to be seen below.

First, the HTML markup #

We'll create a simple aria-label on the desired element: a button containing an SVG icon.

<button aria-label="RSS Feed"> <svg aria-hidden="true"> <use href="/public/images/icons/rss.svg#icon" /> </svg></button>

Do not forget to set an aria-hidden="true" attribute on decorative icons. Otherwise, they will be announced by screen readers regardless of their uselessness.

Now that we have an accessible button, a data-tooltip attribute needs to be added in order to flag elements on which we want to display a tooltip.

<button aria-label="RSS Feed"data-tooltip=""> <svg aria-hidden="true"> <use href="/public/images/icons/rss.svg#icon" /> </svg></button>

Everything is in place; we'll go on with the CSS.

Then, a minimalist stylesheet #

[aria-label][data-tooltip] { position: relative;}[aria-label][data-tooltip]::after { --offset: 8px; content: attr(aria-label); position: absolute; top: calc(100% + var(--offset)); left: 50%; transform: translateX(-50%); width: max-content; padding: 6px 10px; color: black; background-color: white; font-size: 15px; white-space: nowrap; opacity: 0; pointer-events: none; transition: opacity 160ms; z-index: 10;}

These rules are laying the foundations of our tooltip system. --offset variable can be adjusted to fit your need. Same for padding, color, background-color, font-size and transition properties.

A last required set of rules needs to be defined in order to make everything work.

@media not (hover: hover) { [aria-label][data-tooltip]::after { content: none; }}[aria-label][data-tooltip]:is(:active, :focus:not(:focus-visible))::after { content: none;}@media (hover: hover) { [aria-label][data-tooltip]:is(:hover, :focus-visible)::after { opacity: 1; }}

The @media not (hover: hover) media query disables the tooltip system on touch devices.

:is(:active, :focus:not(:focus-visible)) also disables the tooltip on an active or focused element but ignore keyboard-focused elements.

The last rule wrapped inside the @media (hover: hover) simply makes the tooltip associated with the hovered element visible.

We're good to go: we now have a really basic system displaying a bottom tooltip on hovered elements having both an aria-label & data-tooltip attributes.

Going further #

As our tooltips are always displayed at the bottom, we may face problems: tooltips can be shown outside the viewport. It can easily be circumvented by adding a direction to our data-tooltip attributes when needed.

Supposing our button is displayed in the footer of your website, add a top value in the existing data-tooltip attribute.

<button aria-label="RSS Feed" data-tooltip="top"> <svg aria-hidden="true"> <use href="/public/images/icons/rss.svg#icon" /> </svg></button>

The following CSS rules handle displaying tooltips in all directions.

[aria-label][data-tooltip="top"]::after { bottom: calc(100% + var(--offset)); top: auto;}[aria-label][data-tooltip="left"]::after { right: calc(100% + var(--offset)); left: auto;}[aria-label][data-tooltip="right"]::after { left: calc(100% + var(--offset)); right: auto;}[aria-label][data-tooltip="top-left"]::after { top: unset; bottom: calc(100% + var(--offset)); right: 0; left: unset; transform: none;}[aria-label][data-tooltip="top-right"]::after { top: unset; bottom: calc(100% + var(--offset)); left: 0; transform: none;}[aria-label][data-tooltip="bottom-left"]::after { top: calc(100% + var(--offset)); bottom: unset; left: 0; transform: none;}[aria-label][data-tooltip="bottom-right"]::after { top: calc(100% + var(--offset)); bottom: unset; right: 0; transform: none;}

It also relies on the --offset custom property providing a uniform positioning across tooltips displayed in every direction.

This is it, a complete naive tooltip system with ~85 lines of CSS. It is framework agnostic and won't require any maintenance.

And of course, the caveats #

With these 85 lines, we are far from the Radix UI or Base UI implementation.

We have indeed no collision detection, automatic positioning, or accessibility announcements when displayed.

That said, both collision and positioning should not be vital, as you should keep the length of your tooltip to the shortest possible. Be concise; nobody wants to read a whole novel when hovering over a button or a link. Tooltips should be used to give extra context on an element, not to explain everything about it.

The full CSS implementation #

In case you want to copy/paste the full implementation, here it is:

[aria-label][data-tooltip] { position: relative;}[aria-label][data-tooltip]::after { --offset: 8px; content: attr(aria-label); position: absolute; top: calc(100% + var(--offset)); left: 50%; transform: translateX(-50%); width: max-content; padding: 6px 10px; color: black; background-color: white; font-size: 15px; white-space: nowrap; opacity: 0; pointer-events: none; transition: opacity 160ms; z-index: 10;}@media not (hover: hover) { [aria-label][data-tooltip]::after { content: none; }}[aria-label][data-tooltip]:is(:active, :focus:not(:focus-visible))::after { content: none;}@media (hover: hover) { [aria-label][data-tooltip]:is(:hover, :focus-visible)::after { opacity: 1; }}[aria-label][data-tooltip="top"]::after { bottom: calc(100% + var(--offset)); top: auto;}[aria-label][data-tooltip="left"]::after { right: calc(100% + var(--offset)); left: auto;}[aria-label][data-tooltip="right"]::after { left: calc(100% + var(--offset)); right: auto;}[aria-label][data-tooltip="top-left"]::after { top: unset; bottom: calc(100% + var(--offset)); right: 0; left: unset; transform: none;}[aria-label][data-tooltip="top-right"]::after { top: unset; bottom: calc(100% + var(--offset)); left: 0; transform: none;}[aria-label][data-tooltip="bottom-left"]::after { top: calc(100% + var(--offset)); bottom: unset; left: 0; transform: none;}[aria-label][data-tooltip="bottom-right"]::after { top: calc(100% + var(--offset)); bottom: unset; right: 0; transform: none;}

However, given that a good amount of people are walking around with JavaScript fully disabled, your website shouldn't rely on it for critical UI parts.

My remarks are not aimed at complex web apps or UX parts that could never work without JS enabled: this isn't what is targeted here.

A right-fitting use case #

This website exposes a <theme-selector /> in the sticky navigation. This selector is a web component displaying a simple select with the 3 following options:

• Auto = system theme
• Light = forced light theme
• Dark = forced dark theme

The default option being "auto", this website will automatically sync with the visitor system theme. Once the component is loaded, it detects if the user has already chosen a theme, in which case its choice will be stored in window.localStorage, then applies it. But what happens if the user has disabled JS?

Simply nothing.

In case JavaScript is never executed, the website is only synced with the system theme. Nothing indicating this information is shown to the user, and that's too bad.

Progressive enhancement #

I found out the best way to reconcile this web component with a version of this website served without JavaScript was to initialize it this way:

<theme-selector class=":btn" aria-label="Theme (needs JS)" data-tooltip disabled> <button>Auto </button></theme-selector>

<theme-selector /> now has a button as a child displaying a default value. It also has a aria-label showing a "Needs JS" message when hovered and is also disabled at the start. The web component is handling styles with its class attribute: that way it will be correctly displayed with or without JS.

Now, if JS is allowed to run, the web component will replace its innerHTML with a shadow root containing a select with the three possible options. The web component will also update the aria-label and remove the disabled attribute in its connectedCallback:

connectedCallback() { this.setAttribute("aria-label", "Change theme"); this.removeAttribute("disabled"); /* ... */}

This approach brings two main benefits:

• A disabled theme selector is still displayed, showing a tooltip indicating it needs JS to work correctly.
• A placeholder is displayed in case theme-selector.js is loaded from a really slow network preventing a layout shift.

Another example #

In a more simple use case, like this animated demo, a fallback image is displayed in case JavaScript is not enabled:

<simple-bar-demo playing="true"> <noscript> <img class="introduction__image" src="/public/images/toolbox/simple-bar/preview.jpg" alt="simple-bar demo" /> </noscript></simple-bar-demo>

Here, the noscript tag is important, as without it, the fallback image would start to load immediately before the <simple-bar-demo /> web component is fully loaded. It is needed in order to prevent unnecessary assets loading.

There are surely more applications than I can think of!

If it seems easy to plan then orchestrate a full optimization of a system or a website, it is another set of affairs preventing long term degradation.

As I'm not planning on building an observability system for my personal website, I'll have to be careful with asset additions and changes like this one.

The culprit #

Once done with every thinkable tweak allowing for the lightest payload possible, I introduced, on second thought, a film-like grain effect applied over the background of my website. It was a simple .png file of 250px/250px, I didn't think much of its size. On top of that, it was converted and served either as a webp or an avif depending on the browser capabilities.

Taking my homepage as an example, with this new grain.avif image, I was going from these stats:

35 requests27.4 kB transferred66.1 kB resourcesFinish: 10.95sDOMContentLoaded: 4.71 sLoad: 8.91 s

To these:

36 requests147 kB transferred185 kB resourcesFinish: 11.33 sDOMContentLoaded: 4.67 sLoad: 9.26 s

Stats recorded with a 3G throttled connection.

The impact on loading time is anecdotal, but multiplying the transferred size by more than 5 feels like chopping my optimization work with an axe.

A simple fix #

At first, I was tempted to simply remove this effect, thus immediately resolving the issue. Except I'm quite fond of the texture it adds to my otherwise bland background.

Then, I searched for an alternate way of making a noisy grain effect that would be lighter and found it in the svg specification.

The following simple code was the answer:

<svg viewBox='0 0 110 110' xmlns='http://www.w3.org/2000/svg'> <filter id='grain'> <feTurbulence type='fractalNoise' baseFrequency='0.55' numOctaves='3' stitchTiles='stitch' /> </filter> <rect width='100%' height='100%' filter='url(#grain)' /></svg>

This svg file weighs only 292b: more than 119kb less than the previous image.

The result #

Here, side by side, are the old and new noisy grain effects:

It is clearly not the exact grain when shown bare like that, but when used as an overlay, the effect is pretty much the same using this bit of css and adjusting opacity:

.grain { position: absolute; inset: 0; background: repeat center/110px url("/public/images/grain.svg"); border-radius: 0; opacity: 20%; pointer-events: none;}

opacity needs to be adjusted: on a light background you may need to set it higher than on a dark one. mix-blend-mode can also be used in order to improve the grain integration depending on the color of your background.

Bonus: a live noise grain generator #

You'll find below a small web component I built in order to generate your own grain effect svg file with custom parameters. You can adjust the baseFrequency and numOctaves of the grain effect. Opacity can also be adjusted and text toggled for preview purposes.

See MDN documentation if you are interested in understanding the different parameters available for the <feTurbulence> SVG element.

As I keep moving things around on my website, it seems mandatory to take it slow and reflect on every change if I want to keep things clean.

I know these files are cached but still, it is at least downloaded once in a while, that's already too much for something as subjective as fonts.

The further we go, the more clean and lean the defaults system font are becoming.

But how to use these fonts in your CSS?

There goes the sans-serif fonts #

--sans-serif-font: system-ui, -apple-system, blinkmacsystemfont, "Segoe UI", "Roboto", "Oxygen", "Ubuntu", "Cantarell", "Fira Sans", "Droid Sans", "Helvetica Neue", arial, sans-serif;

system-ui will be the default font set system-wide by the user. You could instead use ui-sans-serif in order to be sure that the displayed font is really a sans serif font, but this value isn't supported outside Safari for now.

The browser will try to load every other values successively until one matches. All fonts used here are matching the default fonts used in every major OS (macOS, Windows, Ubuntu, etc.)

Monospaced fonts #

--monospace-font: ui-monospace, menlo, monaco, "Cascadia Mono", "Segoe UI Mono", "Roboto Mono", "Oxygen Mono", "Ubuntu Monospace", "Source Code Pro", "Fira Mono", "Droid Sans Mono", "Courier New", monospace;

The same logic applies here, ui-monospace is currently only supported in Safari, but the next matching font will be used depending on user OS.

And last but not least, serif fonts #

--serif-font: ui-serif, Georgia, Garamond, Cambria, "Times New Roman", Times, serif;

Again, same here, ui-serif is not widely supported. The other fonts should come pre-installed in almost all OS, you can order them as it suits you.

Font uniformization #

As it is not possible to know what font will be used for each user in the end, you can set the font-size-adjustCSS property to ex-height 0.5 in order to uniformize the space occupied by the loaded font regardless of its family.

This should prevent UI breaking in most cases.

body { font-size-adjust: ex-height 0.5;}

A nice explanation by Alex Kladov is available here if you want to know more about this CSS property.

If you are looking to optimize your pages loading and avoid either the blocking while font load or the font swap when enabled, I recommend you to ditch these customs fonts and a rely on the user system ones. They are almost always good enough.

In my opinion, you'll differentiate your design a lot more with delightful colors, design, and animations. Fonts can often be overrated.

The idea is to leverage the tabindex attribute coupled with the :focus & :focus-withinCSS pseudo selectors.

Images used are loaded from picsum.photos, which takes its sources from Unsplash.

HTML markup and basic styles #

Assuming you need to display a variable number of images, you'll have to generate a variable markup looking like this:

<div class="image-gallery image-gallery--4"> <div class="image-gallery__item"> <div class="image-gallery__backdrop" tabindex="-1"> <img class="image-gallery__image" src="https://picsum.photos/seed/7cb42b45/1500/750" tabindex="0" /> </div> </div> <div class="image-gallery__item"> <div class="image-gallery__backdrop" tabindex="-1"> <img class="image-gallery__image" src="https://picsum.photos/seed/4dd8300c/1500/750" tabindex="0" /> </div> </div> <div class="image-gallery__item"> <div class="image-gallery__backdrop" tabindex="-1"> <img class="image-gallery__image" src="https://picsum.photos/seed/b66a4549/1500/750" tabindex="0" /> </div> </div> <div class="image-gallery__item"> <div class="image-gallery__backdrop" tabindex="-1"> <img class="image-gallery__image" src="https://picsum.photos/seed/5783fa29/1500/750" tabindex="0" /> </div> </div></div>

Note that the .image-gallery element also has a class containing the number of image displayed inside the gallery: .image-gallery--4. Adding this information helps a lot when styling all layout possibilities, as you'll see below in the CSS part.

Each .image-gallery__item contains a backdrop element with tabindex="-1" making it focusable on click but not accessible while cycling through items with the tab key.

At last, the img is added inside this backdrop with a tabindex="0" allowing to focus it on click and with the tab key.

We'll need to add some styles to this gallery:

.image-gallery { width: 100%; display: grid; grid-template-columns: repeat(2, 1fr); gap: 1px; margin: 0 auto;}@media (min-width: 1001px) { .image-gallery { grid-template-columns: repeat(4, 1fr); }}.image-gallery__item { width: 100%; height: 100%; aspect-ratio: 1400 / 650;}.image-gallery--1 .image-gallery__item { grid-column: 1 / -1;}@media (min-width: 1001px) { .image-gallery:is(.image-gallery--1) { grid-template-rows: 1fr; } .image-gallery:not(.image-gallery--1, .image-gallery--3) { grid-template-rows: 250px 250px; }}.image-gallery__item { background: linear-gradient( to bottom right, #f5f5f5 0%, #c5c5c5 50%, #fff 100% );}@media (min-width: 1001px) { .image-gallery:is(.image-gallery--2, .image-gallery--3) .image-gallery__item:not(:nth-child(1)), .image-gallery:not(.image-gallery--1, .image-gallery--2, .image-gallery--3) .image-gallery__item:nth-child(4), .image-gallery:not( .image-gallery--1, .image-gallery--2, .image-gallery--3, .image-gallery--4 ) .image-gallery__item:nth-child(n + 5) { grid-column: span 2; } .image-gallery:not(.image-gallery--1) .image-gallery__item:nth-child(1), .image-gallery--2 .image-gallery__item:nth-child(2) { grid-column: span 2; grid-row: span 2; }}.image-gallery__backdrop { width: 100%; height: 100%; transition: background-color 160ms; z-index: 1;}.image-gallery__image { width: 100%; height: 100%; object-fit: cover; border-radius: inherit; cursor: zoom-in; user-select: none; outline: none;}

We now have a nice responsive image gallery handling any number of images:

This is of course only a suggestion of design, it can be adjusted to fit perfectly your needs.

Making it interactive #

We can now focus on making these images zoomable! And that's the beauty of CSS, with only two sets of rules, the magic happens.

This one will display in position: fixed the image backdrop when its child image will be focused:

.image-gallery__backdrop:not(:focus):focus-within { position: fixed; top: 0; left: 0; display: flex; align-items: center; justify-content: center; background-color: rgba(0, 0, 0, 0.1); cursor: zoom-out; z-index: 2; user-select: none;}

And this one will also display in position: fixed the image on top of the backdrop when focused:

.image-gallery__image:focus { width: auto; max-width: 90%; height: auto; max-height: 90%; object-fit: contain; border-radius: 8px; pointer-events: none; z-index: 3; animation: image-gallery-zoom-in 160ms;}@keyframes image-gallery-zoom-in { 0% { opacity: 0; transform: scale(0.98); }}

The pointer-events: none property will allow clicks to go through, which will make the user lose focus over the image and focus the backdrop. In consequence, the gallery will close the opened image.

As images are now focusable elements thanks to the tabindex="0" attribute, you cycle between images with tab and cycle back with shift+tab.

A nice touch would be to inform the user about the controls allowing to cycle through the images. It would of course need to be displayed only if an image is focused and not on a mobile device.

You can add this piece of HTML at the end of the .image-gallery container. It must be located inside this container in order to have a parent selector with :has.

<div class="image-gallery__keyboard-indicator"> Use <code>Tab</code> or <code>Shift</code>+<code>Tab</code> to navigate between images</div>

.image-gallery__keyboard-indicator { display: none; position: fixed; bottom: 26px; left: 50%; padding: 8px 12px; font-size: 14px; background-color: #f5f5f5; border-radius: 4px; transform: translateX(-50%); z-index: 4;}@media (pointer: fine) { .image-gallery:has(.image-gallery__image:focus) .image-gallery__keyboard-indicator { display: block; }}.image-gallery__keyboard-indicator > code { padding: 2px 4px; font-size: calc(1rem - 2px); background-color: #fff; border: 1px solid #c2c2c2; border-radius: 4px;}

This indicator will be displayed only when the gallery is focused, thanks to .image-gallery:has(.image-gallery__image:focus).

The @media (pointer: fine) allows for targeting only device using a mouse, which generally brings its keyboard.

This bit will only work in browsers supporting :has pseudo selector so we'll call it progressive enhancement.

Result #

Sure, it is less comfortable than the experience provided by a full-blown Lightbox plugin, but it comes at absolutely no cost.

If your needs are simple, start with the simplest solution you can come up with.

And it was great: with Vercel on the free plan, I didn't have to think about anything. A simple git push and my website was up to date a minute later. With the low traffic I'm experiencing on my website, it doesn't costed me a dime!

So why part away?

Working with Next.js on a website as simple as mine always felt like using war machine where a way, way, more basic tool could be used. On top of that, I was never fully at ease when using Vercel as a hosting solution. I was feeling like my website should be hosted at home, with a local hosting provider.

I'm not going to speak about other controversies like this one on a vendor lock-in background but I can at least say that I'm more comfortable with a fully independent open-source solution.

I also wanted to make simpler things and rely less on JavaScript for everything.

An ode to simplicity #

Instead of relying on a big meta framework like Next.js coupled with Vercel' infrastructure, my website is now built with Hono and self hosted on a tiny VPS provided by OVH, a French hosting provider.

This new website, with a design heavily inspired by zed.dev, is statically generated locally on my machine then deployed on my VPS with a basic rsync command.

HTML is generated by JSX components - Hono provides support out of the box - and styled by CSS leveraging the new layer system allowing full control over specificity in a context of a global stylesheet.

Hono's JSX let me reuse a lot of my Next.js assets as it supports async components.

Escaping the bundling hell #

Sure, I still use a package.json and rely on some external dependencies while I develop and build my website:

{ "devDependencies": { "@types/bun": "latest", "@types/uglify-js": "^3.17.5", "classnames": "^2.5.1", "front-matter": "^4.0.2", "hono": "^4.8.5", "lightningcss": "^1.30.1", "marked": "^16.1.1", "serve": "^14.2.4", "sharp": "^0.34.3", "shiki": "^3.8.1", "uglify-js": "^3.19.3", "zx": "^8.7.1" }}

But in the end, I only have .html and .css files.

Trying to work without JavaScript#

React.js was really great for building absolutely anything but it was also pushing me to use JavaScript everywhere, even when it wasn't needed. The goal, with this new website, was to use JavasScript only as a last resort. As I wanted my website to still be fully functional without JavaScript enabled.

In order to eliminate almost all JavaScript usage, I had to rethink most of the interactive parts of my website and leave some functionality behind.

I made a lot of things work with pure CSS:

A responsive navigation #

A basic image gallery with zoom #

24/07/2025 edit: The process of creating this image gallery is now detailed in this article.

Using JavaScript on non-critical parts #

Even if wanted a website working with HTML and CSS only, there were some things impossible to create without JavaScript.

The perfect example is this interactive demo for simple-bar which obviously cannot exists without JavaScript.

Using web components and in this case a shadow root makes this demo fully autonomous and isolated from the rest of the website.

A noscript tag allows to render an image instead of the demo if JavaScript is disabled:

<simple-bar-demo playing="true"> <noscript> <image className="introduction__image" src="/public/images/toolbox/simple-bar/preview.jpg" alt="Simple Bar Demo" /> </noscript></simple-bar-demo>

I also re-implemented my lazy loaded icon component using a web component. Its source can be found here, on my GitHub.

Using a noscript fallback made it "JavaScript less" compatible:

export default function Icon({ code, className }: Props) { const href = `/public/images/icons/${code}.svg#icon`; return ( <lazy-icon code={code} class={className}> <noscript> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" class={className} > <use href={href} /> </svg> </noscript> </lazy-icon> );}

A handmade Image component #

The Image component provided by Next.js was really easy to use as a simple drop-in replacement for <img /> tags. As I was moving from an hybrid static website running with a Node.js server to a fully static website, I had to find another way to optimize my images.

I settled on creating a custom <Image /> component that would handle image optimization and resizing during build time. Generating all my website images at once takes around 2 minutes but I only have to do it once globally, otherwise, images are generated during dev time.

This <Image /> component is async and uses sharp in order to transform the requested image in 3 output files:

• An optimized version in the same format
• A .webp version
• An .avif version

These 3 files are used inside a <picture> tag:

<!-- Input --><image className="about__description-picture" src="/public/images/about/picture.png" width="{60}" height="{60}" loading="lazy" alt="Jean Tinland"/><!-- Output --><picture class="about__description-picture"> <source srcset="/_generated/w60h60/images/about/picture.avif" type="image/avif" /> <source srcset="/_generated/w60h60/images/about/picture.webp" type="image/webp" /> <img src="/_generated/w60h60/images/about/picture.png" alt="Jean Tinland" loading="lazy" /></picture>

That way, the browser loads the first image format compatible.

Enters the speculation rules #

Hosting my website in France outside a CDN made it slower than before for almost all my visitors as very few comes from France.

Reducing all the assets size - mostly with a big refactor and minification - plus enabling HTTP/2 already reduced loading time a lot.

A nice touch was to enable this relatively recent feature pushed by the Chrome team: the Speculation Rules API.

const rules = { prerender: [ { where: { and: [{ href_matches: "/*" }] }, eagerness: "moderate", }, ], prefetch: [ { urls: ["/portfolio/", "/toolbox/", "/blog/"], referrer_policy: "no-referrer", }, ],};export default function SpeculationRules() { return ( <script type="speculationrules" dangerouslySetInnerHTML={{ __html: JSON.stringify(rules) }} /> );}

With theses rules every internal link hovered triggers a pre-render of the targeted page allowing for a really fast navigation. Coupled with the View Transition API, everything feels snappy and smooth!

Closing thoughts #

I know this doesn't look like much, but the feeling of creating something more powerful with fewer resources is always bringing a lot of satisfaction.

As time goes by, I think, like everyone else, I try to simplify every aspect of my life I can. Upgrading the dependencies of my personal website every couple of weeks didn't work in any way with this approach.

I already have a good amount of work with my open-source projects; it was not necessary to top that with extra maintenance that wasn't adding any real value to my website.

31/07/2025 edit: This article has been featured in This Week in React#244. Thank you Sébastien Lorber! :)

Icons used in this article are extracted from the Remix Icon library.

The inline way #

Maybe you are using a popular icon library like react-icon, or @remixicon/react. In that case, each icon you import will likely be inline injected in your final HTML. Depending on the complexity of these icons or their number, this can lead to a significant increase in your bundle size.

The sprite way #

Another approach that I find interesting is to use SVG icons with the <use> tag. This way, you can reference the same SVG file multiple times in your HTML without having to duplicate the SVG code.

Downloading, optimizing (with SVGOMG), and importing icons inside your project can be a lot of work if you need numerous icons for your application but starting from scratch you'll generally add icons one by one when needed so it doesn't feel like a big deal.

The basic setup for this usage it to create a single .svg sprite file that will reference several icons inside elements.

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" style="display: none"> <symbol id="arrow-right" viewBox="0 0 24 24"> <path d="m16.172 11-5.364-5.364 1.414-1.414L20 12l-7.778 7.778-1.414-1.414L16.172 13H4v-2h12.172Z" /> </symbol> <symbol id="arrow-left" viewBox="0 0 24 24"> <path d="M7.828 11H20v2H7.828l5.364 5.364-1.414 1.414L4 12l7.778-7.778 1.414 1.414L7.828 11Z" /> </symbol></svg>

If your sprite.svg is located in /images/icons/sprite.svg, you can call your icons like this:

<svg> <use href="/images/icons/sprite.svg#arrow-right"></use></svg>

Doing this will allow you to reference the same SVG file multiple times without increasing your bundle size.

However, if you use only one or two icons in a specific page, you'll load the entire sprite file just for these icons. Depending on its size, it can be acceptable or not.

Splitting your sprite into individual files #

To avoid loading the entire sprite file, you can split your sprite into individual files.

<!-- arrow-left.svg --><svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" style="display: none"> <symbol id="icon" viewBox="0 0 24 24"> <path d="M7.828 11H20v2H7.828l5.364 5.364-1.414 1.414L4 12l7.778-7.778 1.414 1.414L7.828 11Z" /> </symbol></svg><!-- arrow-right.svg --><svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" style="display: none"> <symbol id="icon" viewBox="0 0 24 24"> <path d="m16.172 11-5.364-5.364 1.414-1.414L20 12l-7.778 7.778-1.414-1.414L16.172 13H4v-2h12.172Z" /> </symbol></svg>

These icons can be used like this:

<svg> <use href="/images/icons/arrow-right.svg#icon"></use></svg>

Browser cache is doing the rest: icons used in several places will be loaded instantly after their first use.

Usage in React.js #

In order to reduce boilerplate, you can create a component that will handle the loading of your icons.

// @/components/icon.tsxtype Props = React.SVGProps<SVGSVGElement>& { code: string;};export default function Icon({ code, ...props }: Props) { return ( <svg width={24} height={24} {...props}> <use href={`/images/icons/${code}.svg#icon`} /> </svg> );}// Usage:<Icon code="arrow-right" />;

Now with lazy loading #

I find it interesting to lazy load these icons because it allows for a reduced number of request during the initial page load: only icons that are in view are requested over the network.

You'll need to adjust your icon.tsx component like this:

// @/components/icon.tsx// This code implements lazy loading for SVG icons using the Intersection Observer API.type Props = React.SVGProps<SVGSVGElement>& { code: string;};export default function Icon({ code, ...props }: Props) { // Creates a ref to track the SVG element const ref = React.useRef<SVGSVGElement>(null); // Uses useState to track if the icon is in viewport const [inView, setInView] = React.useState(false); React.useEffect(() => { // Checks if IntersectionObserver is supported by the browser const isCompatible = "IntersectionObserver" in window; if (isCompatible) { const svg = ref.current; // Checks if not already inView before setting the observer if (svg && !inView) { // Creates an observer that triggers when icon enters viewport const observer = new IntersectionObserver( ([entry]) => { if (entry.isIntersecting) { setInView(true); } }, // Adds a root margin to trigger the observer a bit earlier: 24px before svg enters the viewport { rootMargin: "24px" } ); // Sets up observation of the SVG element on mount observer.observe(svg); return () => { // Cleans up by unobserving when icon is inView or unmounted observer.unobserve(svg); }; } } else { // Falls back to always showing the icon setInView(true); } }, [inView]); // Only sets the SVG reference when icon is in view // Prevents unnecessary loading of SVG icons outside viewport const href = inView ? `/images/icons/${code}.svg#icon` : undefined; return ( <svg ref={ref} width={24} height={24} {...props}> {href && <use href={href} />} </svg> );}

Here the result in video:

Below the code I use on my website without comments and with the addition of a IconCode type more specific allowing for auto completion for the code property when using the <Icon /> components.

"use client";import * as React from "react";export type IconCode = "arrow-left" | "arrow-right";type Props = React.SVGProps<SVGSVGElement>& { code: IconCode;};export default function Icon({ code, ...props }: Props) { const ref = React.useRef<SVGSVGElement>(null); const [inView, setInView] = React.useState(false); React.useEffect(() => { const isCompatible = "IntersectionObserver" in window; if (isCompatible) { const svg = ref.current; if (svg && !inView) { const observer = new IntersectionObserver( ([entry]) => { if (entry.isIntersecting) { setInView(true); } }, { rootMargin: "24px", } ); observer.observe(svg); return () => { observer.unobserve(svg); }; } } else { setInView(true); } }, [inView]); const href = inView ? `/images/icons/${code}.svg#icon` : undefined; return ( <svg ref={ref} width={24} height={24} {...props}> {href && <use href={href} />} </svg> );}

Of course, this is only an approach to this specific problematic, this code can be adjusted or completely rewritten if necessary.

The logic of detecting and rendering the Icon was fixed thanks to @mohammadazeemwani!

Return to my roots #

I think my appeal for modelism - simply put, painting minis - is one of the many things I inherited from my father.

As far as I can remember, I have always been fascinated by these recreations of war or everyday life scenes. I started gluing and “painting” some WW2 planes before I was ten. These were not what I would call successes, but it was a blast simply to try. It was also way too fragile for a child liking to break things apart.

Soon enough, and with some friends, I discovered the dark and heavy world of Warhammer 40000… I spent years going through cycles of frenetically assembling and painting only to stop and going at it again later. Each time I improved a bit on my “technique” without attaining an excellent level. That said, I'm quite satisfied with the result of my latest try.

To this day, I'm stuck with a big box of painted and unpainted minis from Games Workshop. I'm also stuck with this urge to paint something from time to time.

Yeah, I could simply pick some of these and paint them but this Sci-Fi world is not appealing to me anymore as it used to be. I'm more into the historical side of things now.

Finding an excuse to buy a new model #

With Christmas approaching, gifts were bought and packed. Among them, I thought it would be cool if I bought a tank model for my father.

Coming back home I was wondering if it was in fact a good idea… I may be more patient than my dad when it comes to these practices.

I then decided that I would graciously assemble and paint the tank and offer it as is. Yeah, yeah, I know, very generous and not a gift to myself at all!

About the model #

I settled on a French Somua S35 tank at 1/35 scale produced by Tamiya. This should provide a lot of details and have an acceptable size : not to small, not to big.

For the historical bits, the Somua S35 was a medium tank produced by France between 1936 and 1940. It was an excellent tank providing speed, maneuverability, protection!

The hull was made of cast steel which enhanced durability and prevented bolts and rivets to fly everywhere inside on heavy impact. This phenomenon observed on other tanks of this era could make huge damages to the crew.

One of its main weaknesses, other than the quantity produced that wouldn't meet the army's need at the time, was that it was a one-person turret. This meant that the commander had to handle commanding, loading, and firing at the same time. Demographics can partly explain this design choice as France was less populated than Germany at the time: fewer people to man those tanks.

Some pictures of the build process #

It begins with the bottom part of the tank.

Once the main part assembled, it's time to add the tracks.

These sets of tracks are each composed of 102 chain links. That's a lot of microscopic parts to assemble…

The hull is done.

Tools are adding a nice level of details.

Some other details are added.

The turret is now assembled.

The tank commander is ready to hop in the turret.

This tank needs some optics!

Tank is fully assembled!

Paiting time! #

Tamiya provides a really nice painting guide in the box. I choose to reproduce the camo of the Somua S35 No. 20 of the 4th Reg. de Cuirassiers.

Impossible to paint correctly without a light subcoating.

After two successive coats, my paint is finally covering enough.

Decals #

I must say I was apprehending this step a lot as I remembered childhood “traumas” when my decals were almost systematically torn while trying to apply them. I don't know if decals improved with time or if I simply am more precise and focused now.

I'm pretty okay with this!

Final result #

In order to age the appearance of this tank and make it look less pristine, I used a contrast paint on its entirerity.

That's all! It is certainly not a piece of art, but I hope my father will like it as is.

My use case: a carousel with numbered slides #

One of the first externalized components was the infamous carousel. Time after time I added more personalization options to the markup and logic: horizontal sliding transition, previous and next controls, current element indicators with dots, touch support, etc. The source file of this specific component was becoming a bit of a mess.

With the complete revamp of Valraiso's website, our graphic designer added a nice carousel on the home page.

The one from our common library was to be put to good use!

As you can see in this picture, almost everything was already taken care of; the only missing part was on the current slide counter.

Instead of implementing the feature right away, I left the classic, too much used // TODO. As expected, this comment stayed in place way too long.

A CSS only approach #

After joking for two years about this with our graphic designer, I finally asked an intern to take care of the problem, as it seems to be a great exercise.

While he was starting to add more and more logic to the javascript, I thought it would be interesting to go another way: after all, only this website needed this specific feature; why add weight to all websites code bases?

I think it is easy to say it was a good call: problem was solved with only 3 lines of CSS.

Here is what we had to do in order to make it work.

Our markup was looking like this. For a variable number of sections, our component is spawning a corresponding dot. The current dot is identified with a specific CSS class: carousel__dot--current.

<div class="carousel"> <div class="carousel__inner"> <section></section> <section data-current=""></section> <section></section> <section></section> <section></section> </div> <div class="carousel__dots"> <button class="carousel__dot"></button> <button class="carousel__dot carousel__dot--current"></button> <button class="carousel__dot"></button> <button class="carousel__dot"></button> <button class="carousel__dot"></button> </div></div>

With that in mind, we only had to declare a counter and increment it for each .carousel__dot:

.carousel__dot { counter-increment: home-carousel-dots;}

Now, by using this value at two different places, it was done.

.carousel__dot--current::before { content: "0" counter(home-carousel-dots); /* in our case 02 */}

.carousel__dots::after { content: "/0" counter(home-carousel-dots); /* /05 */}

The secret resides in the fact that depending on the scope in which you use your counter, it doesn't have the same value.

At the .carousel__dot--current level, the counter is equal to the current count of .carousel__dot in the HTML. But above, at the .carousel__dots level, a count has been made, so the counter is equal to the total of .carousel__dot in the HTML.

The rest was simply positioning and styling.

I'm always amazed by the capabilities of basic CSS over javascript solutions. We tend to often overlook other, simpler viable options.

On top of that, I had a lot of free time, allowing me to tweak my workflow between two fir tree cuttings.

While working on a Mac, I was missing tools that would allow me to have better control over my windows. I had already tried to use yabai as a window manager in the past but couldn't stick to it as I was missing an important piece: the hotkey daemon that would articulate everything.

Installing both yabai and skhd (both developed by asmvik) then became the foundation of my setup.

One thing that was lacking in my new setup was a status bar displaying some basic information like the current focused workspace, the current process title, or simply today's date and time. This feature was originally implemented out of the box in yabai but was stripped in the later version as it wasn't really in the scope of the project.

Taking the matter into my own hands #

At the time, there was already a status bar that would answer this need, but I wasn't satisfied by the offer. I wanted to have total control over the feature set and the appearance of it.

Working mainly with Javascript and React and stumbling on Übersicht, my choice was quickly made.

Übersicht is a macOS utility that allows you to run widgets written in React on your desktop. These widgets are fed with output from shell scripts.

First foundation #

simple-bar was born with, at first, a read-only role. It was a simple display of numbered workspaces with an indicator on the focused one. At its center, it was showing the currently focused window title. And finally, on its right side, it was displaying the current date and time with a battery level indicator.

I open-sourced it, and after a few months, people started slowly to hit the "star" button. It made me realize I wasn't the only one working on macOS with this feeling of missing a piece of interface on my desktop.

Interactivity #

Soon enough, Übersicht allowed for direct interaction with its widgets. Thanks to that, workspaces became clickable and allowed users to swiftly land on any workspace.

The battery widget could toggle caffeinate on click, the date display would open the calendar app by default, and wifi could also be toggled on click, among a lot of other possible interactions.

It was at this time that people started to suggest more and more features that I was happy to implement. I also had a lot of pull requests; to this day, 63 users contributed to simple-bar, helping me a lot in perfecting the product.

More and more features #

With almost 150 customization options added, a settings module was a must. When the 19 default data widgets were not enough and after having several people suggest it, I implemented a custom widget system allowing the user to display its own shell script output in simple-bar.

One of the latest upgrades of the project was the creation of an http node server coupled with a websocket server, allowing the user to plug simple-bar into it and send curl enabling or refreshing specific widgets or parts of the bar.

This solution eliminates one of the original weaknesses of simple-bar : its slowness when asked to be refreshed. It also enabled the option to synchronize the default and custom widgets with users' workflows.

The realization #

Oh, the irony...

It was only a few days ago, as I switched my main display to a big external screen and needed to move simple-bar to the bottom of it, that it clicked.

I spent four years trying to create a replacement for the default macOS status bar, only to end up with a magnificent Windows task bar (plus the workspaces list).

Working on this project and dealing with more than 240 issues and 160 pull requests was an incredibly formative experience.

The difficult part comes from accepting to let people down with some requests and bug fixes I couldn't implement due to lack of time and sometimes motivation.

At the same time, I worked really hard on the structuration and code quality of the project in order to make it easily forkable, and I think it worked: I saw more than 110 forks after four years of existence.

I think the choice of Übersicht, thus developing simple-bar as a simple React app, guaranteed appreciable accessibility: working on this project is almost the same as working with HTML and CSS only. It allowed more participation to the project compared to others written in C for example.

Even if I know that, performance wise, simple-bar is lagging far behind SketchyBar, its accessibility and extensibility are keeping it a viable alternative.

I love to think I also indirectly contributed to SketchyBar thanks to @kvndrsslr, who created sketchybar-app-font based on a forked icon set used in simple-bar.

We are here to see what path I followed before arriving at a satisfactory and basic solution.

If you are not here for the blabla, you can skip the "origins" and sarcasme part an go directly to the presentation of the app.

Early attempts #

I started simple with a PHP application linked to a MySQL database. My notes were organized inside categories that I could manage directly in the application. My plain text notes were soon enough holding me back as I was manipulating a lot of code snippets that were looking way better with some syntax highlighting so I created a second type of notes in order to handle theses.

But that wasn't the end of it: for some reason I thought it would be better if my notes could contain some rich text, images, anchors... A third type of note was added with an floating TinyMCE action bar allowing text formatting and image upload.

After that I find the need to add shareable version of my notes in read-only mode. Next came the tchat feature as the app was used by several people. Finally, all my work was literally burnt to the ground as the server hosting the app was lost in a fire and no backup were to be found (git you said? Nope, coding through FTP like a pro!).

I took this hit as a time to reflect and came to the following conclusion: what was I thinking trying to build from ground up the entire set of features offered by Google Docs?

Only months later I was going again with a new project that was meant to be a simplified version of the previous iteration: 1 type of rich text notes all sorted inside manageable categories. That was it. But here again I was simply recreating the exact set of features anyone could find inside the "Notes" app made by Apple. Except for the little knowledge in Javascript and PHP that it brought me, it was a bit of a waste of time.

I let it die and moved on... for a while. COVID hit and I couldn't think of any better way to spend my time than to develop a revolutionary app that would be a mix between the Apple Note app and the Apple Finder! This time it was rich text notes kept inside unnamed but colored categories. Before being done I had a realization: where this madness will end?

I wasn't inventing anything at all and taking aside the small knowledge gain I pretty much wasted my time, again.

Reflecting on these "mistakes" #

Several years later, I was collecting my thoughts on these attempts to create a viable and durable note app and I realized the following:

• I don't need plenty artifices to keep track of my ideas: plain text - or at max markdown - would largely suffice.
• The simpler, the better: I can't burn so much time in random pet projects.
• Why keep trying to organize ideas that comes and go as they want, I like wild post-its!

Based on these points, I was ready for a last try.

A fresh start #

Now better equipped with all my thinking and experience with notes, I decided to set 2 ground rules before beginning:

• This is an express project: it must be done in 2 work days.
• The feature set must be kept to a minimum.

And here are the selected features:

• Post-its like notes dropped on a canvas.
• Post-its can be moved and resized as desired.
• Position of post-its is persistant and relative to the viewport.
• Notes can also be displayed in an orderly manner.
• Categories are identified by a color, they a created directly in database as I don't need new categories every day.
• Plain text that can be previewed as markdown.
• Each post-it can be download as .md.
• Notes can be associated to a date.
• Bonus: system synced theme.

Used tools:

• Next.js with app router: useful for rendering the notes on the server and clean refresh of the app on content update with the revalidation helper.
• Framer Motion: perfect for easy implementation of dragging and resizing of notes.
• Postgres database hosted on Vercel linked to the Vercel project.
• React Markdown for markdown previewing.

Result #

Capitalizing on an existing basic design system, I was able to work swiftly on core features.

Based on those components (buttons, inputs, etc...) and a full theme composed by CSS variables, each UI element was rapidly in place.

As for the demo, a series of videos will speak louder than words demonstrating theses functionalities.

Note creation #

I can create a new note by simply clicking on the "New draft" button or dragging and dropping it anywhere on the canvas.

Note resizing #

Each note can be resized from its edges.

Organizing post-its #

Notes can be moved (drag mode is activated by pressing cmd or ctrl), stacking order is determined by the last time each one has been modified.

Categories #

Each note can be assigned to a specific category.

Basic search engine #

A simple search bar is available to filter notes by title.

Organized grid view #

All notes can be displayed in a grid view.

Notes & dates #

Notes can be associated with a date. If this date has passed, the relevant note will be displayed with a red border.

Light and dark themes #

The application is automatically synced with the system theme. This one was really easy with a simple switch of shades of grey and the use of the prefers-color-scheme media query.

Overview #

You can see I embraced the mess with all theses stacked notes but this is not a problem as everything can be quickly sorted and filtered.

Now that its done #

I think I came to a result that suits perfectly to my needs. I developed it in less than two day as I planned to. Of course I had to patch some things and adjust some CSS after deploying it but those were quick patches!

In technical terms, the Next.js/Vercel environment allowed me to deploy the app more quickly than any other solution I could think of: it was done in minutes. Framer Motion was perfect: it made disappear the hassle of handling dragging events.

To my knowledge, no notes app was offering the same set of features as mine. I'm pretty content with the idea of having developed something relatively unique.

I hope you'll find at least some inspiration in this project.

I’m beginning to enjoy writing about things, and I do it as it comes. Don’t expect crazy stories; these articles will be dull for most people, but the point is to have a basic place of expression for myself.

That being said, feel free to contact me if you want me to speak about a specific subject.

I hope you enjoy your reading!