The web platform is evolving at an unprecedented pace, rendering many of the JavaScript libraries we once considered essential obsolete. For Vijay Raina, a specialist in enterprise SaaS technology and software architecture, this shift represents a golden opportunity for developers to streamline their applications. By leveraging “Baseline” features—standards that are now supported across all major browsers—teams can significantly reduce their bundle sizes and improve performance without sacrificing functionality. In this discussion, Vijay explores how a systematic audit of dependencies can reveal where the browser has finally caught up to our needs. He provides a roadmap for distinguishing between bleeding-edge features and stable defaults, offering a strategic framework for developers who want to ship less code and rely more on the power of the native platform.
When auditing dependencies, how do you distinguish between features that are newly available versus those that are truly safe for production across the board?
We rely on the Baseline project from the WebDX Community Group to provide that clarity, which categorizes features into three distinct states: Limited, Newly available, and Widely available. A feature is marked as Baseline Newly available the moment it lands in all major engines—Chrome, Edge, Firefox, and Safari—meaning it works for anyone on an up-to-date browser, but might fail for users on older hardware. The real threshold for most enterprise applications is Baseline Widely available, which only happens after a feature has been supported by all major engines for 30 months. During that 30-month gap, you have to be incredibly careful because while a feature like Intl.DurationFormat might have landed in March 2025, it won’t be considered Widely available until 2027. I always advise developers to check their analytics first; a B2B dashboard where users are forced onto the latest version of Chrome is a perfect playground for Newly available features. However, if you are running a public-facing site with a long tail of old Android devices, jumping the gun on a feature that isn’t Widely available yet can lead to a broken experience for a significant chunk of your audience.
Before a developer starts deleting libraries in favor of native APIs, what specific criteria should they use to evaluate the risk of that transition?
I follow a rigid three-question framework to ensure we aren’t just trading one problem for another. First, you must ask if the replacement is Baseline-safe for your specific audience, which requires looking at your browserslist configuration rather than just an abstract compatibility table. Second, you have to calculate the actual cost of the swap; for instance, if you replace a 3 KB library with a native feature that requires a 44 KB polyfill to work on Safari, you’ve actually made your bundle significantly heavier. Finally, you must verify that the platform feature actually covers your real-world use case, as libraries often provide “sugar” that the native API lacks. A classic example is axios, which handles JSON parsing and request cancellation elegantly, whereas a raw fetch call requires you to manually check res.ok and handle AbortController yourself. If you’re relying on complex interceptors or upload progress bars, a blind find-and-replace with fetch might leave you spending hours re-implementing logic that the library already perfected.
Internationalization is often cited as a major source of bundle bloat. Which specific native tools under the Intl namespace are providing the biggest wins right now?
The Intl namespace has become a powerhouse, allowing us to drop a whole cluster of dependencies that used to be standard. You can replace timeago.js, which is about 1 KB gzipped, with Intl.RelativeTimeFormat to handle strings like “3 hours ago” or “yesterday” with the numeric: "auto" option. Then there is numeral, a 3.9 KB library that many teams use for currency and percentages, which is now entirely covered by Intl.NumberFormat. We also see people using pluralize or small list-joining helpers, but Intl.PluralRules and Intl.ListFormat are both Widely available and handle the nuances of the Oxford comma and local language rules natively. If you combine all these—humanize-duration, timeago.js, pluralize, and numeral—you are looking at saving roughly 14 KB gzipped just by moving to the platform. It feels incredibly satisfying to delete those packages and realize the browser is doing the heavy lifting with better localization than a third-party script ever could.
For many developers, moving away from a robust HTTP client like axios feels risky. How do you weigh the benefits of fetch against the missing features like interceptors or automatic retries?
It is a more nuanced trade-off than just looking at the 17 KB gzipped size of axios. The native fetch API is Widely available and handles basic GET and POST requests perfectly, but it does require more explicit code, such as calling res.json() and manually verifying the status code since it doesn’t reject on 404 or 500 errors. I have personally used a custom class wrapped around fetch for years to handle interceptors for auth tokens, shipping it to millions of users with great success. However, there are still gaps where the platform falls short; for example, fetch still cannot report upload progress in a first-class way, which is a dealbreaker if you’re building a file uploader with a progress bar. If your app only performs straightforward data fetching, dropping axios for a thin fetch wrapper is a clear win, but if you rely on automatic retries or complex request transformations, the library might still earn its place in your package.json.
The UI Primitives cluster seems to offer some of the most dramatic improvements in accessibility. How do native elements like the dialog tag change the way we build modals and tooltips?
The shift toward native UI primitives is a massive win for both performance and accessibility because elements like handle the complex “plumbing” that we used to build by hand. A standard modal library often needs to bundle focus-trap (6.6 KB) and body-scroll-lock (1.3 KB) just to ensure a user doesn’t accidentally tab out of the window or scroll the background. The element, which is now Widely available, does all of this natively when you call showModal(), automatically moving focus, making the rest of the page inert, and even providing a ::backdrop for styling. We can even replace the body-scroll-lock library with a single line of CSS using the :modal pseudo-class: body:has(dialog:modal) { overflow: hidden; }. When you add in the Popover API for dropdowns and CSS anchor positioning for tooltips, you can potentially strip out 24 KB gzipped of code while gaining better accessibility defaults than most hand-rolled solutions ever achieved.
Lodash used to be a staple in every project, but you suggest its footprint is shrinking. Which specific utility functions have been rendered unnecessary by recent updates to the JavaScript language?
Lodash is a great example of a library that served as a bridge to the future, and now that we’ve arrived, many of its parts are redundant. Object.groupBy and Map.groupBy are huge additions that landed in March 2024; they let you reorganize arrays into objects keyed by property without needing a 25 KB library or a standalone helper. We also have structuredClone, which is Widely available and handles deep cloning of objects, including tricky cases like circular references and Date objects, far better than the old JSON.parse hack. Even complex Set operations like union, intersection, and difference became Baseline Newly available in June 2024, meaning you no longer need Lodash for basic data manipulation. By dropping just lodash.clonedeep and lodash.groupby, you save about 8 KB gzipped, and for most modern apps, you only really need to keep Lodash around for things like debounce or throttle, which still don’t have a native equivalent.
You mentioned that Temporal is a “case study in not dropping a library yet.” Why should developers be cautious about adopting this new date API even though it is technically superior?
Temporal is the future of date handling in JavaScript—it’s immutable, handles time zones sanely, and finally fixes the nightmare of zero-indexed months—but from a bundle perspective, it’s currently a trap. It reached Stage 4 in March 2026 and is shipping in Chrome and Firefox, but as of early 2026, Safari has only moved it into Technology Preview, meaning it isn’t Baseline yet. Because it’s in Limited availability, you would need a polyfill to use it across all browsers, and the official @js-temporal/polyfill weighs in at a staggering 44 KB gzipped. Compare that to a lightweight library like dayjs, which is only 3 KB gzipped, and the math just doesn’t work out. You would be adding 41 KB to your bundle just to use a “native” feature; the right move here is to stick with your current date library and revisit the audit once Safari stable ships Temporal and it officially reaches Baseline.
For a team that hasn’t audited their dependencies in a year, what are the first practical steps they should take to identify these potential “platform wins”?
The process starts with visibility; you can’t optimize what you can’t see, so the first step is running a command like npm list --prod to see what is actually shipping to your users. From there, you need to measure the cost of each package using tools like Bundlephobia for a quick glance, or source-map-explorer and vite-bundle-visualizer to see how those dependencies sit in your actual production bundle. Once you have a list of the heaviest hitters, you check their Baseline status on webstatus.dev or look for the Baseline badge on the MDN documentation for the replacement feature. If you find a candidate that is Newly available, don’t just delete the library; instead, implement a feature check in your code to serve the native version to modern browsers while keeping the old library as a fallback for everyone else. It’s not a one-time cleanup task but a quarterly habit that can eventually shave 60 KB to 90 KB off a typical mid-sized app’s gzipped bundle.
What is your forecast for the web platform over the next few years?
I believe we are entering an era of “The Lean Web,” where the browser becomes a high-level application framework rather than just a document viewer. Over the next 24 months, as Temporal moves from Limited to Widely available and CSS anchor positioning matures across all engines, the “JavaScript tax” we pay for basic UI and data handling will plummet. We will see a significant decline in the usage of massive utility libraries as developers realize that shipping 90 KB of polyfills and helpers is a performance debt they no longer need to carry. By late 2026, the 2024 batch of features like array grouping and new Set methods will be Widely available, and that 30-month stability window will make native-first development the default choice for enterprise architecture. The most successful teams won’t be those who know the most libraries, but those who best understand how to get out of the browser’s way and let the platform do its job.
