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

Finding another hosting platform #

Having used Next.js a lot at my latest job, I had deployed many things on Vercel's platform. I also knew a free tier was available that allowed 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 easy task scheduling.

The API #

The synergy between Next.js and Vercel led me to spin up a minimalist Next.js app exposing a single /api/check endpoint.

When this route, protected by a secret, is called, a simple .json configuration file is parsed. From it, a collection of URLs to check is iterated over. On success, everything is fine and the script continues. On failure, it retries a configurable number of times. Definitive errors are listed in a simple report sent via email through nodemailer, alerting me to any app failure relatively quickly. I couldn't think of a simpler solution.

Below is 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 that checks whether things are working properly only once a day isn't really useful. I'm not running critical services that need permanent observability, but triggering a check every hour seemed like the right interval 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 closed the lid.

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 that.

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, one could also eliminate the intermediate API and use only 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 the number of checks required for each app throughout the day.

The API allows me to centralize everything in a single place and handle check and retry logic.

Then I stumbled upon the MDN documentation page, and there is more to this simple attribute.

When you declare an id attribute, the HTML element to 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 id 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 HTML data-* attributes and the WAI standard. That means you'll see a lot of aria-label and data-tooltip 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 lay the foundations of our tooltip system. The --offset variable can be adjusted to fit your needs. The same goes for the 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 ignores 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 with both aria-label and 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. This 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 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 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 following 3 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's system theme. Once the component is loaded, it detects if the user has already chosen a theme, in which case their 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 that 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 an aria-label showing a "Needs JS" message when hovered and is also disabled at the start. The web component handles styles with its class attribute; that way it will be displayed correctly 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 over a really slow network, preventing a layout shift.

Another example #

In a simpler 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 asset loading.

There are surely more applications than I can think of!

If planning and orchestrating a full optimization pass on a system or a website seems easy, preventing long-term degradation is another matter entirely.

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 I was done with every tweak I could think of to keep the payload as light as possible, I introduced, on second thought, a film-like grain effect over the background of my website. It was a simple .png file of 250px by 250px, and 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 alternative way to create 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 same grain when shown on its own like that, but when used as an overlay, the effect is pretty much the same using this bit of CSS and adjusting the 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 #

Below, you'll find 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 can be 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 necessary to take things slow and reflect on every change if I want to keep things clean.

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 images 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.

Lastly, the img is added inside this backdrop with a tabindex="0", allowing it to be focused 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 design suggestion; it can be adjusted to fit your needs perfectly.

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 the image backdrop in position: fixed when its child image is 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 the image on top of the backdrop in position: fixed when it is 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 on the image and focus the backdrop. As a result, the gallery will close the opened image.

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

A nice touch would be to inform the user about the controls that allow them 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 targeting only devices using a mouse, which generally implies a keyboard.

This bit will only work in browsers supporting the :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 didn't cost me a dime!

So why part ways?

Working with Next.js on a website as simple as mine always felt like using a war machine where a much more basic tool could be used. On top of that, I was never fully at ease when using Vercel as a hosting solution. I felt 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 against a background of vendor lock-in, but I can at least say that I'm more comfortable with a fully independent open-source solution.

I also wanted to build 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's 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 with CSS, leveraging the new layer system and allowing full control over specificity in the 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 JavaScript 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 I wanted a website working with HTML and CSS only, there were some things that were impossible to create without JavaScript.

The perfect example is this interactive demo for simple-bar, which obviously cannot exist 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 more compatible with environments without JavaScript:

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 a 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 into 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 compatible image format.

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 come from France.

Reducing the size of all the assets - 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 these rules, every hovered internal link triggers a pre-render of the targeted page, allowing for 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 always brings 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 when starting from scratch, you'll generally add icons one by one as needed, so it doesn't feel like a big deal.

The basic setup for this usage is to create a single .svg sprite file that will reference several icons inside <symbol> 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 caching does 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 requests 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 is the result in a video:

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

"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 problem, and this code can be adjusted or completely rewritten if necessary.

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

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, overused // 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 website codebases?

I think it is easy to say it was a good call: the 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 generates 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 elements in the HTML. But above, at the .carousel__dots level, a count has been made, so the counter is equal to the total number of .carousel__dot elements in the HTML.

The rest was simply positioning and styling.

I'm always amazed by the capabilities of basic CSS over JavaScript solutions. We often tend to 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 currently 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 a 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 with the available options. I wanted to have total control over the feature set and its appearance.

Working mainly with JavaScript and React and stumbling upon Ü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 slowly started hitting 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 have contributed to simple-bar, helping me a lot to perfect 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 several people suggested it, I implemented a custom widget system allowing users to display their 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 commands to enable or refresh specific widgets or parts of the bar.

This solution eliminates one of the original weaknesses of simple-bar: its slowness when asked to refresh. 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 structure 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 lags far behind SketchyBar, its accessibility and extensibility keep 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 lore, you can skip the "origins" and sarcasm part and 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 holding me back, as I was manipulating a lot of code snippets that looked much better with some syntax highlighting, so I created a second type of note in order to handle these.

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 a floating TinyMCE action bar allowing text formatting and image upload.

After that I found the need to add shareable versions of my notes in read-only mode. Next came the chat 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 backups 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 the 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 note 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 would this madness end?

I wasn't inventing anything at all and, setting aside the small amount of knowledge I gained, 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 many artifices to keep track of my ideas: plain text - or at most 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 come 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 two 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 persistent and relative to the viewport.
• Notes can also be displayed in an orderly manner.
• Categories are identified by a color; they are created directly in the database as I don't need new categories every day.
• Plain text that can be previewed as markdown.
• Each post-it can be downloaded as .md.
• Notes can be associated with 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 of CSS variables, each UI element was rapidly in place.

As for the demo, a series of videos will speak louder than words in demonstrating these 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 these stacked notes, but this is not a problem as everything can be quickly sorted and filtered.

Now that it's done #

I think I came to a result that suits my needs perfectly. I developed it in less than two days as I had 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 the hassle of handling dragging events disappear.

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 reading!