The web platform is way more powerful than most developers realize — and every year it quietly gains new superpowers.
Sometimes choosing a topi...
For further actions, you may consider blocking this person and/or reporting abuse
You captured it perfectly. It really comes down to your mental model. When you're writing a UI in React, it helps to remember that your code ultimately runs in a platform‑specific environment, the browser. That means at least two engines are involved in interpreting your work: V8 for JavaScript (ECMAScript) and, for example, Blink for DOM operations, rendering, and the browser APIs you mentioned.
React is simply a tool that embraces a compositional approach, helping developers build UI components quickly and consistently. But it’s completely valid to interact directly with browser APIs or even the DOM itself when needed. React may call it an anti‑pattern, but it still gives you the escape hatches, like useRef to do it when the situation calls for it.
And here’s the fun part: I spent several years at Facebook working closely with the React team, not as a member of the team, but as a microservices systems engineer. Even there, it was understood that sometimes writing an “anti‑pattern” is the pragmatic choice.
Exactly 🙂 Those APIs exist for a reason - to be used when they make sense. Frameworks are great abstractions, but the browser is still the actual runtime and it’s good to stay aware of that layer.
And honestly, I wouldn’t call useRef some huge anti-pattern either - it’s more like an escape hatch for when you really need to interact with the platform directly. Used thoughtfully, it’s just pragmatic engineering.
I mostly work in Angular day to day, but the idea is the same there: sometimes going a bit closer to the platform is simply the right tool for the job 🙂
Even if you write React code, so many times happen need to reach that browser API in a useEffect.
Congratulations!
For speaking and for your post: browser APIs are useful and powerful, but often underrated. Your post is a great reminder, I'll keep it handy…
Thanks, Pascal! 🙂 And yes - especially in the era of a million frontend libraries, native APIs are such a great option. Honestly, I might write something about frontend node_modules one day too… that whole ecosystem can be quite a circus 😄
Great list 👌
Honestly, APIs like
ResizeObserver,IntersectionObserver, andAbortControllerreplaced so many small libraries in my projects without me realizing it. The browser already solves problems we often reach for npm packages for.Posts like this are a good reminder to check “can the platform do this?” before installing another dependency.
Oh yes - thanks for this comment! That’s exactly the point I was hoping to highlight 🙂 The platform has grown so much that it often solves problems we used to reach for libraries for by default. Sometimes it’s just about pausing and asking “can the browser already do this?” before adding another dependency.
One thing I have noticed after working on AI heavy and security sensitive products is that native browser APIs age far better than most helper libraries. Dependencies tend to multiply risk over time. Audits, updates, breaking changes, abandoned maintainers. Meanwhile browser APIs evolve more conservatively and with long term stability in mind.
In AI powered applications this becomes even more important. When your bundle already includes large runtimes like LLM, WASM, or media processing, every extra dependency has a real cost. Not only in size, but also in trust, review time, and operational complexity.
Treating the browser as a first class platform, not just a host for frameworks, leads to cleaner mental models and better architectural decisions. Frameworks like React are great productivity tools, but knowing when to lean on the platform directly is a senior level skill.
This post is a great reminder that sometimes the most modern choice is also the most boring one. And that is usually a very good sign.
Exactly this 🙂 And that’s not even touching how those dependencies often look in practice - layers of peer-dependencies (sometimes for the most trivial things), and then explaining every single one in security reports, including packages you didn’t even knowingly install.
The longer I work in this field, the more I’m convinced it’s worth thinking three times before adding a utility library - especially for UI concerns that the platform can often handle already. Fewer dependencies usually means fewer surprises later.
Good reminder: don’t reach for a library before checking native browser APIs. Modern web has built-in solutions for many common needs - using them keeps bundles smaller, performance higher, and complexity lower.
ABSOLUTELY - I couldn’t agree more, and the longer I work in this field, the more I feel it. Especially when you go through security audits that scrutinize every package and dependency 😄 Suddenly that “tiny helper library” doesn’t feel so tiny anymore.
Thanks for putting this list together! There are so many useful Browser APIs that we don't use on a daily basis, it’s great to to refresh that knowledge. Infinite scroll without IntersectionObserver though, not even sure how to approach that 😅
Haha, it really was a nightmare 😄 I still remember implementing it in early Angular days - even with a library it was a painful journey. IntersectionObserver was a lifesaver when it arrived.
For the people that like reading documentation:
Thanks for sharing the links! And absolutely - if any of these APIs spark someone’s interest, diving into the documentation is the best next step 🙂
About the ResizeObserver,
I have tried it out in the past, created a handler for it and had it working too but then I came across the *'window.visualViewport' together with its 'resize' listener.
A long story short, I abandoned that handler and switched to that straight away.
Thanks for sharing! It’s always great to hear real “from the trenches” experiences 🙂
I’d say though that it’s not exactly the same thing - visualViewport and ResizeObserver solve slightly different problems. One is more viewport-level, the other is element-level, so it really depends on the use case.
Love this!! Few new ones for me to play with :)
Thanks a lot! 💖 And yeah, browser vendors definitely aren’t slowing down 😄
This is a great reminder.
The web platform is more powerful than most devs realize.
Fewer dependencies also means fewer surprises long-term.
Oh yes, absolutely! The more dependencies you add, the bigger circus they become to maintain later 😄
Ah! Here we go again: developer.mozilla.org/en-US/docs/W...
Ah, I know what you mean - sounds like you’d enjoy a follow-up post 😄
Cool banner, Sylwia
Thanks, Ben ☺️
Welcome Sylwia :)
Some of these I didn't know about and could come in handy! Bookmarked for later, thanks for sharing :)
Thank you! Happy to hear that 🙂 Hope they’ll be useful when you need them!
Thanks for this article as it's refreshing and open better perspectives than using library. You are right a we need to stay up to date which is not really easy with strict requirement at work. This gives me new question for the small side project i'm doing for those who begin the web development ficus. It's offline using
indexedDBfor now and i'm currently working to migrate toward a BAAS to avoid writing all the backend part from scratch. Check it out if you have time. It's a small think to help my student too understanding concept and more with a direct link toward the docThanks for the kind words 🙂 I’ll take a look when I get a moment - sounds like a nice initiative!
Good article!
Thank you 😊
missing Atomics + SharedArrayBuffer, cross browser too if you know how to enable those, a topic ignored so much I wish I could give a talk at jsday.it/ about that but that's unfortunately right after another trip ... bummer!
Absolutely love this comment 🙂 I 100% agree. I actually had a big dilemma choosing which 10 APIs to include - there are so many good ones. SharedArrayBuffer + Atomics could easily be a great topic for a dedicated article on their own. And it’s a shame we’ll miss each other at jsday - would’ve been a great chance to chat!
This is such a great reminder of how powerful the web platform already is,
We often reach for libraries by default, but many of these native APIs are cleaner, faster, and easier to maintain once you know they exist.
Loved the mix of practical examples and real-world use cases — especially structuredClone, IntersectionObserver, and AbortController.
Definitely bookmarking this. Thanks for sharing and spreading awareness of underused browser superpowers
Thank you so much 🙂 And yes - in many cases native browser APIs tend to be more stable and future-proof than a random library. The platform evolves carefully, and once you know what it offers, it can save a lot of complexity. Glad you found it useful!
I really appreciate the list of browser APIs you shared. There are plenty of browser APIs we can use before jumping straight to NPMs. I'm all about vanilla JS first and only go for NPMs where it really matters. I'll definitely keep this handy for later and use it when needed.
Thanks a lot 🙂 And exactly - NPM when it’s really needed, not by default. Glad you found it useful!
great post again. Thanks
that is truly a very useful list.
There are some that i use occasionally, but for some it was mind opening. will revisit this again to take notes!
Thanks a lot! Really glad it was useful 🙂
Thanks for putting this together! This is a great set of tools that are not as well known as they should be!
I would caution about using the performance API for micro-optimizations. MDN makes vague mention of Reduced Precision, but there is a fair amount of history to it. Some things, like intentional timer jitter in the JavaScript engine to prevent certain vulnerabilities can make small performance tests invalid or badly skew the results.
I wrote about Micro Performance Testing, and some pitfalls of the process, plenty of which I've fallen into over my career.
That’s a very fair point - thanks for bringing it up 🙂 Micro-benchmarks can definitely be tricky, and reduced precision or jitter can skew results more than people expect. I treat the Performance API more as a directional tool than an absolute truth, especially for small measurements. Your write-up sounds interesting!
This is a fantastic list! I’m a huge advocate for 'betting on the platform,' and seeing structuredClone finally kill the JSON.parse(JSON.stringify()) hack is such a win. I actually think the BroadcastChannel API is the real sleeper hit here—it makes multi-tab state sync feel like magic instead of a chore.
Also, so stoked to hear you’re speaking at jsday.it about WebGPU and WASM! That’s the true frontier of the web right now. I always love your work and the way you make these deep dives feel so accessible. Definitely looking forward to more 'sneaky' tech tips!
Thank you so much for these words - seriously, I really appreciate it 🙂 That’s exactly my goal: to explain things in a simple, approachable way without too much complexity or hype. If someone gets curious and wants to dive deeper, they absolutely can on their own. I’m just happy to spark that interest 🙂
The File System API is a game changer for building browser-based tools. I've been working on dev tools that run entirely in the browser and being able to read/write files without a server makes it feel almost native.
structuredClone is another one I wish existed years ago - the number of times I've debugged weird reference issues from shallow copies...
Exactly! The File System API is honestly amazing - it really makes some browser tools feel almost native 🙂 And structuredClone… yeah, where was this years ago? 😄 Would’ve saved a lot of debugging time. I personally also have a soft spot for ResizeObserver and IntersectionObserver - such practical APIs.
WebGPU + WASM ? Interesting topic!
Oh yes - so many possibilities there! 😄
This is helpful. Thanks for sharing
Thanks! Glad it was helpful 🙂
That's awesome, Thanks for sharing :)
Thanks! Glad you liked it 🙂
Last two are dope. Awesome list
Thanks! Glad you liked them 😄
Cool, this is helpful. Appreciate it!
Thanks a lot 😊
Love this kind of post. So many projects ship a dependency when the browser already solved the problem. StructuredClone + observers alone can replace a surprising amount of “utility” code.
Glad you enjoyed it 🙂 And yes — it’s surprising how far you can get with just structuredClone and the observer APIs. The platform already covers a lot more than we sometimes assume.
JS is my kryptonite, but you could explain the features clearly and fast, you are incredibly. I go to talk with my students about it, Thanks for sharing
That’s really kind of you - thank you! 🙂 That was exactly my goal: to explain and show things in a simple, practical way, not like documentation. Glad it helped, and good luck sharing it with your students!
Amazing! Most of these I did not know about ... powerful!
Thanks a lot! Glad you found them useful 🙂