Baseline Can Reveal the JavaScript Your PWA No Longer Needs
The cheapest performance upgrade for an installable web app may already be sitting in its dependency list, waiting to be deleted. Browsers have absorbed jobs that once required dedicated libraries, but many production applications still ship those libraries on every launch because nobody has revisited the original decision.
A new practical guide from Smashing Magazine argues that Baseline can turn that forgotten maintenance task into a repeatable engineering discipline. For PWA teams, the opportunity is bigger than a tidier package file. Less unnecessary JavaScript can mean a smaller application payload, less work on the main thread, fewer third-party packages to maintain, and a faster route to the responsiveness users expect from installed software.
What happened
Published on August 7, Jad Joubran’s guide explains how teams can use Web Platform Baseline to compare old dependencies with capabilities now built into browsers. The examples cover familiar application work: formatting dates and numbers, making HTTP requests, displaying dialogs and popovers, cloning structured data, and grouping collections.
The author estimates that a typical mid-sized JavaScript application can often contain 60 KB to 90 KB of minified and compressed dependencies whose responsibilities the platform can now handle. That is an estimate from the guide, not a universal benchmark. The savings will depend on the application, its browser-support contract, tree-shaking, package choices, and how much of each dependency actually reaches users.
The important development is therefore not one new browser API. It is the emergence of a compatibility framework that helps teams recognize when an old architectural trade-off has expired.
Why this is a PWA story
An installable web app competes with native software at the moment of use, not at the moment of installation. Users notice how quickly it opens, whether controls respond immediately, whether overlays behave predictably, and whether the experience remains stable on an ordinary phone. A manifest and service worker can make the app installable and resilient, but they cannot make excessive client-side code free.
A service worker may prevent a cached library from crossing the network again. The browser can still need to parse, compile, execute, and retain that code. Those costs matter most on slower processors, under memory pressure, or during a cold launch—the exact conditions in which the gap between “website” and “app” becomes visible.
Replacing an appropriate dependency with a browser capability can also improve consistency. The platform already provides primitives such as Intl formatting, fetch, the dialog element, the Popover API, and structuredClone. These are maintained with the browser and increasingly share behavior across engines. They do not eliminate product engineering, styling, accessibility checks, or error handling, but they can remove plumbing that no longer differentiates the product.
Baseline makes compatibility an operating decision
Baseline classifies web features according to support across Chrome on desktop and Android, Edge, Firefox on desktop and Android, and Safari on macOS and iOS. “Newly available” means a feature has become interoperable across that core set. “Widely available” means 30 months have passed since that interoperability point.
That distinction is useful because “supported somewhere” is not the same as “safe for this product.” A consumer app with rapidly updating browsers may adopt a newly available feature with progressive enhancement. An enterprise tool, public service, or product serving older iPhones may choose a fixed Baseline year or the widely available set.
Baseline is a compatibility signal, not an instruction to delete every library. It does not replace analytics, real-device testing, accessibility testing, security review, or investigation of embedded WebViews. It gives teams a clearer starting point for those decisions.
A practical dependency-audit playbook
The strongest response is a measured audit rather than a rewrite:
- Define the real support contract. Use product analytics and customer requirements to identify the browser and operating-system versions that matter, including older devices and embedded contexts.
- Inventory dependencies by job. Record what each package does, how much code reaches production, where it runs, and whether it blocks startup or interaction.
- Check the specific platform replacement. Confirm its Baseline status and semantic fit. A native dialog is not automatically a drop-in replacement for every custom overlay, and structuredClone deliberately does not clone every JavaScript value.
- Replace one low-risk slice. Keep the change reviewable, retain progressive enhancement where necessary, and verify keyboard, screen-reader, touch, offline, and error behavior.
- Measure the result. Compare transferred JavaScript, execution time, cold and repeat launches, Interaction to Next Paint, memory behavior, and failures on representative devices.
Teams can then make the audit continuous. Baseline-aware Browserslist queries, linters, documentation badges, and Lighthouse analysis can help prevent compatibility assumptions from becoming permanent architecture. The useful cadence is not “remove dependencies once”; it is “reconsider them as the platform moves.”
Who should care
Developers gain a smaller maintenance surface and fewer abstractions to learn. Product teams gain a credible path toward faster, more predictable app-like interactions. Founders gain leverage: performance and reliability improvements can arrive without financing a platform-specific rewrite. Investors and distribution partners should care because a leaner web application strengthens the economics of reaching users directly through a URL while still offering an installed experience.
This does not make every framework or component library wasteful. Dependencies remain valuable when they provide tested accessibility, complex state management, specialized algorithms, consistent design systems, or support beyond the browsers a product can require. The target is duplicated platform work, not JavaScript itself.
The trust and security payoff needs careful language
Removing unnecessary packages may reduce supply-chain exposure, update work, and the number of third-party maintainers a team must trust. That is a useful risk reduction, but it is not proof that an application is secure. Native APIs can still be used incorrectly, browser vulnerabilities still exist, and dependency removal does nothing by itself to fix authentication, authorization, unsafe caching, or privacy-invasive data collection.
Trust comes from making the application simpler and validating the result. Teams should preserve lockfile controls, vulnerability monitoring, content-security policies, permission discipline, and transparent privacy behavior after the bundle becomes smaller.
What changes for installable web apps
Baseline does not alter manifest requirements, service-worker registration, installation prompts, or app-store policies. Its impact is subtler and potentially more durable: it helps teams deliver more of the experience with the shared web platform and less product-specific compatibility code.
That improves the open web’s competitive position. A capability implemented across browser engines can benefit one codebase across desktop, Android, and iOS without requiring a store-mediated update. For products built around direct distribution, that is both a technical advantage and a business one.
What IndApp watches next
- Whether PWA teams publish real-device before-and-after results rather than bundle-size claims alone.
- How quickly Baseline data becomes a standard input for build tools, code review, and dependency automation.
- Whether older iOS versions, enterprise browsers, and embedded runtimes limit otherwise attractive replacements.
- Which native primitives can remove code while preserving accessibility and polished app-like behavior.
The broader signal is clear: browser progress now deserves a place in dependency management. The web platform is no longer merely adding features at the edge. It is quietly taking over mature, everyday application work.
For installable web apps, the next leap forward may not require another framework. It may begin with one practical question: what are we still shipping that the browser already knows how to do?
Further reading
Recent news
