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.
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.
This is such an important reminder. We have become so used to running npm install for every minor problem that we forget how powerful the browser has actually become. Learning these native APIs instead of just importing libraries is exactly the kind of fundamental knowledge that builds faster and more sustainable applications. 🙂
Exactly 🙂 Otherwise you sometimes realize a noticeable part of your app depends on something like the legendary isOdd package 😄
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 😄
Love this!! Few new ones for me to play with :)
Thanks a lot! 💖 And yeah, browser vendors definitely aren’t slowing down 😄
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 🙂
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!
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.
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.
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.
Really enjoyed this — it’s a great reminder that the browser itself is often the most underrated “framework” we have. I like how you kept it light but still practical, and the examples make it very easy to rethink habits like reaching for libraries by default.
My takeaway is that the real skill now is knowing when not to add dependencies and trusting the platform more as it evolves. I’m especially interested in how this mindset can simplify long-term maintenance and performance in real products. Looking forward to more posts like this, and your WebGPU + WASM talk sounds 🔥.
Thanks a lot - really glad it resonated 🙂 And I agree, a big part of seniority now is knowing when not to add a dependency and trusting the platform more. Happy you enjoyed the tone and examples, and thanks for the kind words about the upcoming talk too 🙂
Really appreciate you sharing that — your perspective shows a lot of experience and clarity. Love how you highlight restraint and trust in the platform; it’s inspiring and genuinely valuable for other developers to hear.
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 🙂
Cool banner, Sylwia
Thanks, Ben ☺️
Welcome Sylwia :)
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 😄
This is helpful. Thanks for sharing
Thanks! Glad it was helpful 🙂
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 😄
Amazing! Most of these I did not know about ... powerful!
Thanks a lot! Glad you found them useful 🙂
This post came at the perfect time for me.
I recently removed a date library from one of my projects and replaced it with native Intl APIs — bundle size went down noticeably.
Reading this makes me want to audit my dependencies again.
Do you have a checklist or approach you follow before deciding whether a library is actually needed?
I don’t really have a formal checklist. I try to be mindful from the start of a project, which makes it much easier than cleaning things up later.
In practice, every new library addition has to go through a tech lead review. That simple gate already filters out a lot of unnecessary dependencies 🙂
That makes a lot of sense. Being intentional from the start definitely saves a lot of refactoring later. The tech lead review gate sounds like a solid way to keep dependency sprawl under control.
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 😊
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!
the Intl APIs are so underrated. i swear half the projects i've worked on pull in moment.js or date-fns just for basic date formatting when
Intl.DateTimeFormathandles 90% of use cases out of the box.also worth mentioning
structuredClone()— replaced so many jankyJSON.parse(JSON.stringify())hacks in my codebase. native deep clone is one of those things that feels too good to be true when you first discover it.great list, bookmarking this for the next code review where someone tries to npm install something we don't need
Same here 😄 Every new library has to go through my “do we really need this?” review first. And Moment… that one is a classic - even the Moment team themselves recommend using alternatives now. 😅
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!
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!
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 🙂
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!
At the risk of sounding like a blow hard.. i love using api's for a lot of stuff that others don't.. i built an api that allows user to instantly update the pics, description, features, ect .. all that is in the api .. so when we update the dashboard it updates the app instantly .. this includes limit updates and prices.. tiers and inventory .. one api four calls done.. so just make a simple store grid and let claude code set up your api to server your products and then just update the api and the site and app updates with no code no deploy.. i love it
Nice - having a good API layer definitely makes apps more flexible and easier to update 🙂 Different layer than the browser APIs I mentioned here, but still a solid approach for dynamic apps!
This is such a fantastic reminder of how much power the browser has quietly packed all along.
Too often we default to npm install for the tiniest things, forgetting that native APIs like structuredClone, IntersectionObserver, or BroadcastChannel not only reduce dependencies but also make our apps faster, leaner, and easier to maintain.
I love how this post highlights the “escape hatches” frameworks give us. Whether it’s useRef in React or element references in Angular, knowing when to lean on the platform itself is the kind of practical wisdom that separates junior hacks from senior-level engineering.
Honestly, embracing these APIs feels like uncovering secret superpowers — once you start thinking in terms of what the browser can do, your mental model of the web transforms entirely. Native, stable, lightweight, and surprisingly elegant — sometimes the “boring” solution is actually the most future-proof.
Bookmarking this for life — I’ll be revisiting it every time someone suggests yet another tiny utility library that the platform could handle out-of-the-box.
Thank you - I really appreciate this thoughtful comment 🙂 You summed it up beautifully. That mindset shift toward “what can the platform already do?” really changes how you approach frontend architecture. And yes, sometimes the boring, native solution ends up being the most future-proof one 😄 Glad it resonated!
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! 😄
The “stop installing libraries” angle hits home so many of these are things people re-implement (poorly) without realizing the browser already has an answer. Structured Clone and IntersectionObserver especially feel like “why did we suffer for years?” APIs.
I also like that you’re honest about browser support instead of overselling everything. That makes it feel grounded, not hypey.
Haha, I love that “why did we suffer for years?” phrasing 😄
This is a great wake-up call for those of us who still reach for npm install the second a project gets slightly complex.
Honestly, the File System Access API is the one that still feels like "cheating." I remember the dark days of hidden file inputs and cursed hacky downloads; being able to actually showOpenFilePicker() feels like the web finally grew up. It’s definitely that "distributed systems meets frontend" vibe you mentioned—we're basically building desktop apps in a sandbox now.
I’m also glad you gave BroadcastChannel a shout-out. It’s such a clean way to handle things like "Logout everywhere" or "Sync dark mode" without having to mess with localStorage event listeners or heavy state management libraries. It’s one of those APIs that, once you use it, you wonder why you ever did it the hard way.
Great list—it’s a perfect reminder that sometimes the best "new tech" isn't a framework update, but just a native feature we finally stopped ignoring.
I really like that perspective too - the idea that we’re getting closer and closer to “native-like” capabilities in the browser 🙂 It honestly feels like that’s the direction things are heading. JavaScript engines are heavily optimized, we have WASM, now WebGPU, and APIs like File System Access… it’s clear the platform is evolving fast.
Browser vendors definitely aren’t sleeping - the web is moving in a very interesting direction right now 🙂
Cool, this is helpful. Appreciate it!
Thanks a lot 😊
Last two are dope. Awesome list
Thanks! Glad you liked them 😄
That's awesome, Thanks for sharing :)
Thanks! Glad you liked it 🙂
Bookmarked for everyday use. Thank you
excellent, worthy of learning and exploration
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.
Thanks for this, I admit I missed lots of these.
It's a good reminder that we shouldn't ever forget to update our knowledge, even if we're busy, or we lose bits on the way.
Exactly 🙂 Browser capabilities are evolving so fast these days - it’s hard to keep up sometimes, but it’s worth it!
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!
Thanks.