```
A popover closes on outside click and on `Esc`, and renders in the top layer, so there's no `z-index` to tune. A dialog opened with `showModal()` traps focus, makes the background inert and closes on `Esc`. Those are exactly the accessibility details that hand-rolled versions tend to forget.
## Islands: JavaScript only where it's needed
If most of a page is static content, there's no reason to turn the whole page into a JavaScript app. That's the "islands" idea behind tools like Astro: render HTML on the server and hydrate only the interactive parts. A simple version needs no build step:
```html
```
```javascript
const io = new IntersectionObserver((entries) => {
for (const entry of entries) {
if (!entry.isIntersecting) continue;
io.unobserve(entry.target);
const el = entry.target;
import(`./islands/${el.dataset.island}.js`).then((mod) => mod.mount(el));
}
});
document.querySelectorAll("[data-island]").forEach((el) => io.observe(el));
```
Each island's code is fetched only when it scrolls into view. A chart at the bottom of the page costs no network or main-thread time until the user gets there. For an island that shows live data, feeding it from the server over [WebSockets](/en/posts/websocket-real-time-communication/) or SSE is a natural match.
## Web Components: framework-independent components
Components don't require a library either. Custom elements and Shadow DOM are browser standards and work inside any framework, which makes them a good fit for a UI kit shared across projects:
```javascript
class ProductCard extends HTMLElement {
connectedCallback() {
if (this.shadowRoot) return;
const root = this.attachShadow({ mode: "open" });
root.innerHTML = `
```
Putting a value that might come from a user into `innerHTML` through a template string is a very common security bug in framework-free code. Write the static template with `innerHTML` and the dynamic values with `textContent`.
## State: events and a tiny signal
On a medium-sized page you rarely need a global store for components to talk. The DOM's own event system is a pub/sub mechanism:
```javascript
document.addEventListener("click", (event) => {
const button = event.target.closest("[data-action='add-to-cart']");
if (!button) return;
cart.push(button.dataset.sku);
document.dispatchEvent(new CustomEvent("cart:updated", { detail: { count: cart.length } }));
});
document.addEventListener("cart:updated", (event) => {
document.querySelector("#cart-count").textContent = event.detail.count;
});
```
The first listener uses event delegation: instead of attaching a listener to hundreds of buttons, one listener checks where the click came from. Buttons added later work automatically.
For a value read in many places, a small signal does the job:
```javascript
function signal(initial) {
let value = initial;
const subscribers = new Set();
return {
get: () => value,
set(next) {
value = next;
subscribers.forEach((fn) => fn(value));
},
subscribe(fn) {
subscribers.add(fn);
fn(value);
return () => subscribers.delete(fn);
},
};
}
const count = signal(0);
count.subscribe((v) => (document.querySelector("#cart-count").textContent = v));
count.set(3);
```
Solid, Preact Signals, Vue and Angular all build on this idea, and there's a TC39 proposal to standardize it. When your state outgrows something like this, that's a good sign it's time for a framework.
## Measure performance
Google's Core Web Vitals are LCP (when the largest content appears), INP (how fast the page responds to interactions) and CLS (layout shift). INP replaced FID in March 2024 and measures every interaction across the page's lifetime, not just the first click. Large JavaScript bundles hurt it most, because clicks wait while the main thread is busy.
Measure instead of guessing:
- Record a trace in the Chrome DevTools Performance panel. Long tasks (over 50 ms) and forced reflow warnings from interleaved DOM reads and writes are the first things to look at.
- For real-user data, the `web-vitals` library is a few KB and can send metrics to your own analytics endpoint.
- Run Lighthouse CI and axe-core on every PR, and fail the build when the performance score or accessibility checks drop below your threshold.
## Accessibility and the law
The European Accessibility Act has applied since June 2025 and makes accessibility a requirement for many digital products and services in the EU. Technically, most of it comes down to using basic HTML correctly:
- Use `header`, `nav`, `main` and `button` instead of `div` for everything. A click handler on a `div` means writing keyboard and screen reader support yourself.
- Give icon-only buttons an `aria-label`.
- Navigate the page with `Tab` only, no mouse. Is focus visible? Does the order make sense?
That's also why `dialog` and `popover` are worth using: focus handling and keyboard behavior come built in.
## So when do you need a framework?
My split: content-heavy pages, dashboards and small tools get plain HTML, modern CSS and islands. A multi-page app with heavy state and many people working in the same codebase gets a framework, because its structure and ecosystem pay for themselves there.
## Where to go next
Take a component in an existing project that uses media queries, switch it to a container query and drop it into columns of different widths; you'll see the difference right away. Track browser support on [MDN](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_containment/Container_queries) and [Baseline](https://web.dev/baseline). MDN shows the status as a badge at the top of each reference page:
If you want to feed live data into pages like these, my [WebSocket post](/en/posts/websocket-real-time-communication/) covers the server side, and my [awesome-trending-repos post](/en/posts/awesome-trending-repos-web/) shows a site built with a framework.