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 ...
For further actions, you may consider blocking this person and/or reporting abuse
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)
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 👀
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. 😃
Haha, of course my first reaction was: “well… that’s a failure” because it wasn’t one of the top spots 😄 But after a moment I was like… hmm, maybe that’s actually not bad at all 😄
And thank you! The conference is exactly a week from now, so it’s the final stretch now!
requestAnimationFrameis great. You probably can skip theDate.now()part. The callback receives a timestamp as the first argument: developer.mozilla.org/en-US/docs/W...Good catch, you’re right! Thanks for the clarification 🙂
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.
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.
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.
I’ve noticed exactly the same thing. It’s a bit of a trap, if you don’t have enough context or experience, it looks like that’s just how things are supposed to be done. Complex problem → complex solution.
And that’s the tricky part: knowing what not to build is much harder than just building something.
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. 🙌
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
varkeyword 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.
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.
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.
Haha, on the other hand I used to be the first person to install a library for literally anything… and then came version mismatches and security audits 😅
The
<dialog>element is the one that changed my workflow the most. I used to reach for a modal library every single time — managing focus traps, backdrop clicks, escape key handling, scroll locking. Then I discovered<dialog>handles all of that natively withshowModal(). The accessibility wins alone make it worth the switch.navigator.onLineis a great mention too, though worth noting it only tells you if there's a network connection, not if the internet actually works. I've paired it with a lightweight fetch to a known endpoint for more reliable offline detection on sites that serve critical data.Container queries are the sleeper hit on this list. The shift from "how wide is the viewport" to "how wide is my container" fundamentally changes how you think about component design. Once you start using them, media queries for layout feel like a workaround.
Thanks a lot for this comment, and especially for the clarification about navigator.onLine. You’re absolutely right, it can be a bit misleading sometimes!
And yes, is such a game changer. The amount of time we all spent reimplementing modals from scratch… 😅
Hey, nice article again.
Could you please add links to the according MDN pages? This makes it easier if you want to learn more.
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 😄