9 Things You’re Overengineering (The Browser Already Solved Them)

I love writing philosophical essays — thoughts about code, work, all that stuff. I also love deep technical dives. But I know you love my lists of cool features that not everyone has heard about yet 😄

What’s up with me? This week I’m preparing for a conference, fighting performance issues, and trying to get at least somewhat ready for the upcoming holidays 😉

Something nice happened too. I enjoy writing — not just technical articles, but in general. Last summer my life changed quite a bit, and to keep my sanity I started writing a sci-fi story, which I submitted to a Polish science fiction foundation competition. I didn’t win, but my story made it pretty far — around 13th place out of 179 submissions. Considering it was my first attempt at this kind of writing… it could have gone worse 😄

And speaking of sci-fi — the kind happening right in front of us 😉 Today I’ve prepared a batch of things the browser can already do, which honestly didn’t fit in my head not that long ago. A lot of these are still not that widely known, and yet many of them are already supported across modern browsers. Have fun!

---

1. “Let me just run this later” → requestIdleCallback

At first I thought this API was pointless. It basically lets you run some code when nothing interesting is happening. Ok… cool… but why would I care?

Turns out — there are tons of use cases. For example, collecting data about how the user behaves on your page — definitely not something you want to do while your 200 components are rendering 😅 Or loading less important data, preprocessing something, generating images in the background.

Honestly, there are probably as many use cases as there are developers.

function trackUserScrolling() {
  console.log("User scrolled. This changes everything.");
}

if ("requestIdleCallback" in window) {
  requestIdleCallback(trackUserScrolling);
} else {
  setTimeout(trackUserScrolling, 0);
}

Support: modern browsers (historically missing in Safari, so fallback is still a good idea)

---

2. “Why is my input not highlighting???” → :focus-within

It’s easy to style an element that has focus. But what if you want to style the parent div? For example, make it pink, add some flowers 😉 You can write 40 lines of JavaScript… or just use :focus-within.

Works. No listeners. No bugs. No suffering.

.form-field {
  border: 1px solid #ccc;
  padding: 12px;
}

.form-field:focus-within {
  border-color: hotpink;
}

<div class="form-field">
  <input placeholder="Type something meaningful..." />
</div>

Support: basically everywhere that matters

---

3. “Let’s show offline mode” → navigator.onLine

Have you ever built a PWA? Because I have, and the eternal problem is what to do when the user loses connection (e.g. they’re in the wilderness or just walked into an elevator 😄). You can write a bunch of complicated ifs, or just listen to offline and online. On offline you can store data in IndexedDB, and when the user is back online, send it to the server.

window.addEventListener("offline", () => {
  alert("You are offline. Time to panic.");
});

window.addEventListener("online", () => {
  alert("You're back. Panic cancelled.");
});

Support: widely supported (but “online” ≠ “your backend works” 😅)

---

4. “Smooth animation, but make it cursed” → requestAnimationFrame

We’ve all seen this:

setInterval(() => {
  element.style.left = Math.random() * 100 + "px";
}, 16);

You can feel this is not the best idea 😉 It just lags. Luckily we have requestAnimationFrame, which is synced with the browser repaint cycle, so things are actually smooth.

function animate() {
  element.style.transform = `translateX(${Date.now() % 300}px)`;
  requestAnimationFrame(animate);
}

requestAnimationFrame(animate);

Support: everywhere

---

5. “This card should adapt… but only here” → container queries

This feature feels almost unfair. I’m at a point in my career where I barely write CSS anymore (well, except for occasional moments like the one I described here: Is learning CSS a waste of time in 2026?).

But there was a time when I wrote a lot of it. And wow — how much I would have given to apply media queries to a specific element instead of the whole viewport. Now we finally can. The component becomes self-aware, and we can go grab a coffee.

.card-wrapper {
  container-type: inline-size;
}

.card {
  display: grid;
}

@container (min-width: 400px) {
  .card {
    grid-template-columns: 1fr 2fr;
  }
}

Support: modern browsers (add fallback if needed)

---

6. “Random ID, what could go wrong?” → crypto.getRandomValues

const id = Math.random().toString(36).slice(2);

This is how bugs are born. It looks like “good enough” crypto from AliExpress and works… until it doesn’t. First of all, it depends on the engine implementation — we don’t really know what’s happening under the hood. Some patterns are absolutely possible, and with enough IDs you’re basically asking for duplicates.

Luckily, we now have a simple native solution. It’s not a silver bullet, but crypto.getRandomValues is pretty solid — much better entropy, no weird patterns, dramatically reduces the chance of collisions. The browser just does it properly.

const bytes = new Uint8Array(8);
crypto.getRandomValues(bytes);

const id = Array.from(bytes)
  .map(b => b.toString(16).padStart(2, "0"))
  .join("");

console.log("Secure-ish ID:", id);

Support: widely supported

---

7. “We need a modal” → <dialog>

It’s honestly nice that browsers finally stepped up and said: fine, here’s your modal 😄 No more installing 12KB libraries just to open a dialog that users love so much. This one is also accessible by default, so win-win.

<dialog id="modal">
  <p>Are you sure you want to deploy on Friday?</p>
  <button onclick="modal.close()">Cancel</button>
  <button onclick="alert('Good luck 😬')">Deploy</button>
</dialog>

<button onclick="modal.showModal()">Open modal</button>

Support: modern browsers

---

8. “Voice input would be cool…” → Speech API

Are you already installing transformers.js because you need speech recognition? Relax — turns out the browser has something for that too. Well… at least Chromium does 😄 So if you can “encourage” users to use Chrome, Edge, or something similar, you’re good. Personally, I’d still be careful with production use, but for demos? Why not.

const SpeechRecognition =
  window.SpeechRecognition || window.webkitSpeechRecognition;

if (SpeechRecognition) {
  const recognition = new SpeechRecognition();

  recognition.onresult = e => {
    console.log("You said:", e.results[0][0].transcript);
  };

  recognition.start();
}

Support: mostly Chromium

---

9. “Will this CSS explode?” → @supports

Here’s a modern solution to the classic “it works on my machine” — at least in CSS 😉 You don’t have to guess whether something will break your layout. Just wrap it in @supports. There is a small catch — while support is very good, it’s not literally everywhere, so ironically… we could use @supports for @supports.

.card {
  background: white;
}

@supports (backdrop-filter: blur(10px)) {
  .card {
    backdrop-filter: blur(10px);
    background: rgba(255, 255, 255, 0.6);
  }
}

Support: very good

---

⚠️ But don’t get me wrong

Libraries are great. Sometimes you absolutely need them. But sometimes… you’re installing a dependency for something the browser solved years ago. Before installing anything, just ask yourself (or Google): “Is the browser already smarter than me here?” Sometimes the answer is yes. And that’s… perfectly fine 😄

Comments

[Peter Vivo]

Wow the times os going ower my head, I don't know about voice input is aviable in browser.
( my Mac is know that by douple press fn by default)

[Sylwia Laskowska]

Haha yeah, it’s one of those features that feels a bit like sci-fi creeping into everyday life 😄
You’re right though, the support is still a bit limited and not something you’d rely on everywhere in production yet. But things like what you mentioned on macOS show exactly where this is heading.
Feels like we’re slowly moving toward voice being just another normal input method in apps 👀

[Hauke T.]

requestAnimationFrame is great. You probably can skip the Date.now() part. The callback receives a timestamp as the first argument: developer.mozilla.org/en-US/docs/W...

[Sylwia Laskowska]

Good catch, you’re right! Thanks for the clarification 🙂

[Hauke T.]

I like requestIdleCallback. I read about a pattern you can implement with it: idle-until-urgent:
There are some expensive calculations required for some function the user is likely to invoke. Instead of doing it once it is required, you can do it once you have time for it. Basically pre-caching.
But: when the result is required before the work was done, you cancel the callback and do it just-in-time.

[Sylwia Laskowska]

Exactly this! It’s such a beautiful pattern. Idle-until-urgent really changes how you think about work scheduling in the browser. Instead of “do everything immediately”, it becomes “do it when it makes sense… unless the user needs it now”.
Feels like a small thing, but it actually shifts your whole mental model of what the browser can handle for you today.

[Harsh]

Guilty as charged on a few of these. 🙈

The native form validation one hit closest to home. I've definitely built custom validation from scratch complete with error states, custom styling, the whole thing only to realize later that the browser already does 80% of it, and more reliably. The time we waste rebuilding what's already there is honestly embarrassing to think about.

The popover API is another one I discovered embarrassingly late. Spent a weekend building a custom tooltip system once. Never again.

I think part of the problem is how we learn most tutorials start with here's how to build it yourself and never mention or you could just use the browser's built-in thing. So we grow up as developers assuming everything needs to be hand-rolled.

That said, there's a fine line. Sometimes custom makes sense for complex edge cases. But the default should always be: does the browser already do this?

Thanks for the reminder bookmarking this as a read before reaching for a new npm package reference. 🙌

[Hauke T.]

There also is the problem with outdated teaching/learning material.

Any material from before 2015 can safely be ignored.
If I see code examples that use the var keyword I skip the article. If it's a recent article the author is incompetent. If not, it is just outdated.

I bet there are only a few high quality resources, from before 2015 that are worth reading today.

[Sylwia Laskowska]

Exactly this. The knowledge gets outdated really fast. And the pace at which browsers evolve right now is honestly a bit insane. Even if someone works as a frontend dev daily, but doesn’t follow things very closely, there are just whole areas they simply don’t know about.

I was at a JS conference this year where a speaker showed the native — and people were literally sitting there with their jaws dropped. And these weren’t beginners. These were people from the industry, engaged enough to attend a conference!

I think that’s also where the popularity of these list-style posts comes from. Some of them go into tens of thousands of views, and it’s not because the ideas are groundbreaking — it’s just that it’s really hard to keep up with everything that the browser can already do now.

[Hauke T.]

Hey, nice article again.
Could you please add links to the according MDN pages? This makes it easier if you want to learn more.

[Sylwia Laskowska]

Great idea, thanks for suggesting it! 😊 It would definitely make it easier to dig deeper into each feature. I’ll add MDN links, just probably not this week 😄

[NorthernDev]

Casually mentioning that you almost won a national sci-fi competition right before diving into native browser APIs is an incredible flex. I am genuinely impressed by that combination of skills. 🥳

The technical list is spot on. The amount of heavy dependencies I have seen installed just to replicate that exact native dialog behavior is depressing. Also, your offline mode panic alert logic is exactly the kind of architecture the web needs more of.

Good luck with the conference this week. Try not to let the performance issues keep you up writing code all night. We both know exactly where that leads. Get some actual rest before the holidays, and let me know how the presentation goes. 😃

[Nimrod Kramer]

brilliant compilation! the popover API one hits hard - i've definitely been that person with the custom tooltip weekend. these browser evolutions happen so fast it's genuinely hard to keep up. daily.dev has saved me here more than once, surfacing these "wait, browsers can do that now?" moments before i dive into building yet another wheel. the Speech API support caveat is spot on though - chromium-only features always feel like they're teasing us with the future.

[MergeShield]

the agent overengineering problem is worse - it'll implement a custom state machine for something the browser handles natively because it's pattern-matching on "complex problems need complex solutions." knowing what not to build is harder to encode than what to build.