Baseline allows you to clean up unnecessary JavaScript dependencies (npm packages) in your projects by tracking web features that are now natively supported by modern browsers. An average mid-sized web application contains libraries ranging from 60KB to 90KB used for functionalities that the browser can already handle natively. By using Baseline data, you can safely remove these packages and improve site performance.
Dependencies Left Behind by Browser Capabilities
Developers frequently audit the libraries added to their `package.json` files for security (`npm audit`), but they rarely ask the question: "Is this library still doing something the browser cannot?" While operations like date and number formatting, HTTP requests, modal windows, tooltips, deep cloning, and array grouping used to require external packages, they have now become standard capabilities of the modern web platform.
Baseline Statuses: When Should a Package Be Removed?
Developed by the WebDX Community Group, Baseline classifies how safe a feature is across all major browsers (Chrome, Edge, Firefox, Safari) into three stages:
- Limited availability: Not yet supported across all engines; requires fallback code.
- Baseline Newly available: Recently arrived in all major engines; works on current browsers but may pose a risk for older devices.
- Baseline Widely available: Has been present in all engines for 30 months and can be used directly without any additional precautions.
This 30-month gap is a critical threshold for dependency auditing. While external libraries can be removed directly for features with "Widely available" status, target audience analysis is recommended for those with "Newly available" status. Feature statuses can be queried via webstatus.dev, MDN documentation, or the `web-features` npm package.
Decision Framework Before Deletion
The fact that a browser can perform a task natively does not mean the existing library should be deleted immediately. Before removing packages, developers need to examine the target audience's browser usage rates, test whether native APIs support the exact same edge cases as the libraries, and weigh potential performance gains.
Industry Implications and Performance Gains
Choosing browser-native built-in APIs directly reduces the amount of JavaScript sent to the client-side, positively impacting load times and Core Web Vitals metrics. Reducing bloat in package managers is a practical optimization step that improves the overall user experience by easing the CPU load, especially on mobile devices.
Frequently Asked Questions
What tools can be used to integrate Baseline data into projects?
While webstatus.dev and MDN badges can be used to manually check feature statuses, the `web-features` npm package can be integrated into project development workflows for automation.
Is it necessary to write polyfills for older browsers when adding a "Widely available" feature to a project?
No, "Widely available" features supported across all major engines for 30 months generally do not require additional polyfills, as they cover the vast majority of current internet traffic.
*This news article was prepared based on data published by Smashing Magazine.
💬 Comments
No comments yet. Be the first!
You must be logged in to comment.
🔑 Log In