Questioning the Cost of Modern Front-End Tooling

In this episode of the Smashing Podcast, host Drew McLellan sits down with Chris Ferdinandi—front-end developer, author of The Lean Web, and host of The Vanilla JavaScript Podcast—to examine whether the industry's current "best practices" may be doing more harm than good.

Ferdinandi has built a following around streamlining web development by stripping away unnecessary layers of complexity. With his background teaching JavaScript and writing about tooling, he shares a candid perspective on the toll that heavy frameworks and elaborate build processes can take on project performance, maintainability, and the people who use the resulting sites.

The Hidden Weight of Our Build Pipelines

The core concern raised is that many of the tools the industry now accepts as standard bring enormous overhead that gets passed directly to users. Ferdinandi points out that while these tools often promise productivity gains for developers, they frequently overlook the base cost of delivering megabytes of JavaScript to browsers—particularly for visitors browsing on low-end devices or unreliable connections.

What was once a simple web page can quickly become bloated with thousands of dependencies, transpiled code layers, and a mix of frameworks pulling in separate bundles for every feature. He notes that these costs are not theoretical: they translate directly to longer parse times, more on-device memory consumption, and slower time-to-interactive, all of which degrade the experience, especially for the audiences that enter the site on cheaper hardware.

Complexity in the Wrong Places

The conversation extends into productivity, where the discussion challenges the assumption that modern engineering patterns inherently make teams faster. Ferdinandi argues that a number of established forms—such as redundant state management libraries where browser features would suffice—actually add cognitive friction and demand that each team member learn and operate entire ecosystems of tooling before touching a product.

He identifies a recurring theme: the tools have become the focus, shifting attention from the user experience itself. Instead of defaulting to an expressive front-end framework and the supporting network of plugins, Ferdinandi encourages teams to question whether the goals of the project genuinely require it—or whether simple JavaScript methods, well-structured HTML and CSS could deliver the outcome in a more direct, dependable, and lightweight way.

From his book The Lean Web, he distills this philosophy into a clear question for engineering teams asking "should we adopt a new tool?": weigh the long-term maintenance and transferability against the benefits it claims to offer today. His advice is to start with the baseline and introduce complexity only where a real problem exists.

Looking Toward a Lighter Web for Everyone

As the episode draws to a close, Ferdinandi emphasizes that this approach isn't a call to abandon all new technology, but rather a push for a more deliberate mindset—defaulting to progressive enhancement, writing plain JavaScript for tasks where suited, and clearly documenting the unique content structure as a foundation rather than an afterthought.

He believes that a tilt back toward keeping the "web" in web development makes products faster, resilient, and genuinely more accessible to an international audience—some of whom will never experience your site on a modern fiber connection. It is, he argues, a matter of respecting our users' constraints as much as our own comfortable workflows.

Show Notes

Weekly Roundup

Framework Weight, Fragility, and the Case for a Leaner Web

Chris Ferdinandi, author of the Vanilla JS Pocket Guide Series and creator of the Vanilla JS Academy, joins the podcast to discuss his "Lean Web" philosophy. He argues that the industry’s reliance on heavy frameworks and tooling, despite being marketed as "best practices," often degrades performance, excludes talented developers, and creates fragile, over-engineered websites.

Ferdinandi is clear that he doesn't believe frameworks are inherently evil. Instead, he sees them as useful for a narrow set of complex scenarios, yet points out they are routinely used for projects that don't require their power. This dependency, he contends, is the root of many modern web issues.

The Real Cost of the Virtual DOM

To illustrate the cost of heavy frameworks, Ferdinandi contrasts them with lightweight alternatives. He cites that while React and Vue are roughly 30 kilobytes after minification and gzipping, much of that weight is devoted to the virtual DOM, an abstraction layer designed to improve performance by comparing in-memory object maps rather than querying the real DOM repeatedly on every update.

For most interfaces, the performance benefit of the virtual DOM is negligible, and the initial download cost is significant. Lighter options like Preact (about 3 kilobytes) or Alpine JS (about 7 kilobytes) shed the virtual DOM while keeping a similar API. Ferdinandi notes that the 27-kilobyte difference between React and Preact translates to noticeable latency on older devices or slower connections. He argues that for typical apps, the convenience of a framework can be retained—along with future-proofing—by starting with a smaller tool, since porting to a larger one later is easier than rewriting from scratch.

He frames the choice as over-provisioning. "We always go for the multi-tool, the Swiss Army knife," he says, "when sometimes, all you really need is a pair of scissors."

The Condemning Cost of Complex Tooling

Ferdinandi brushes off the argument that bundlers maximizing performance alongside frameworks.

"Even with a bundler, you still need that React core," he says. "Even with the bundling, that's still going to be bigger than using something like Preact."

He extends this to larger subject, taking issue with how tools like module bundlers often lead to a fragile "house of cards" of dependencies. Instead of just improving performance, development teams often rely on additional JavaScript to mitigate performance hits introduced by their earlier JavaScript choices.

Beyond build complexity, he highlights how toolchains act as gatekeepers, shutting out other valuable contributors. He points to WordPress, which shifted its new editor to React. In 2018, its lead accessibility consultant, Rian Rietveld, resigned, saying her team couldn't work on the project. Lacking React experience, they couldn't fix accessibility bugs directly and were forced to file tickets instead. A resulting audit a year later documented over 90 accessibility issues. This illustrates his point that a choice to optimize for the experience of JavaScript-developers can have profound impact on the experience of both other teammates and end users, which truly was illustrated by veteran accessibility expert losing her ability to contribute.

He further notes that the argument that frameworks enforce disciplined conventions from project to project often mirrors reality. "There are React-y approaches," he says, "but not a strict one right way." Rather than being bound by universal conventions, developers ironically often still search for one "correct" answer among a dozen different tutorials.

While acknowledging that some newer approaches like coupling CSS to JavaScript components have merits when scoping styles that won't be orphaned when you delete something, he says it feels like "throwing engineering at people problems." The same result can often be achieved with third-party linters or thoughtfully authored CSS, making him reject a "if it's good enough for Facebook, it's good enough for us" approach.

Polyfills Versus Portable Dependencies

Drew compares approaches like CSS-in-JS to polyfills—temporary solutions to wait for a native platform feature. Chris agrees but identifies a crucial difference: polyfills are designed to be ripped out without rewriting code. Sophisticated frameworks and libraries often act more like roadblocks that are difficult to remove when the native platform matures.

He favors solutions--even build tools that style or extend without fundamentally rewriting code—that can be removed easily later on, noting technologies like React or Vue may be paving cow paths. His concern lies more with tools built around this giant ecosystem than the platform hacks.

Rethinking Single-Page Apps

Ferdinandi advises that claims of raw performance boosts with single-page apps (SPAs) are overstated. SPAs replace typical URL-driven page loads with one HTML file and heavy JavaScript, which needs to recreate core browser features that ordinarily are automatic—intercepting link navigation, managing focus for assistive technology, or handling the back button—and usually does so with even more code.

This strategy introduces heavier initial downloads and slower interaction timing, plus a risk: the very mechanisms you apply as fixes can fail. He reminds audiences of how a Cloudflare outage in July—or one in the weeks preceding the recording—forced failures of CDN-hosted JavaScript. He recounts BuzzFeed engineer Ian Feather sharing how around 1% of their scripts failed there, millions of requests a month.

Whereas some advocate JavaScript mainly because it keeps an app functional offline, he notes that with service workers and progressive web apps (PWAs), webpages can be pre-fetched to work offline without the cost or fragility of a single-page approach. For sites like a course portal he runs, he finds using basic HTML accessible via CDNs feels just as immediate and loads "as fast if not faster." The approach resembles simple Flash-era web design for Drew that demands boilerplate reimplementation just to feel normal again.

HTML and CSS: The Stable Core

Compared with JavaScript, HTML and CSS are resilient. Ferdinandi notes a misspoken HTML tag simply gets treated as a generic div, and bad CSS merely gets skipped over. A small JavaScript typo, failed variable name, or misplaced semicolon can crash an entire app.

Errors can come beyond a codebase itself, including aggressive firewalls or ad blockers. He used to work for a security-conscious firm with strict JavaScript whitelisting. Without the script running, hamburger-menus were invisible, leaving sites otherwise navigably hopeless in all JS-disabled browser environments.

"We built a web that should be faster than ever in 2020 with 5G," he says. "Yet somehow, we have websites that are slower and less performant than they were five or 10 years ago."

Embracing the Platform

While he argues we should be more thoughtful with choices, Ferdinandi insists old doesn’t mean obsolete

He sees the platform recently improving in ways that reduce the layer build ups needed for common UI. Modern browsers support query selectors, template literals and smooth scroll behaviors, so needing tiny libraries to reimplement simple input expansion or accordions is perplexing.

His small solutions fit a wider pattern: starting with multi-page generation. Using static-site tools and content delivery networks can speed delivery while increasing lean architecture. When frameworks are necessary, he suggests examining options carefully, including precompilers like Svelte, converting everything into tiny Vanilla JavaScript bundles instead of long terms in web pages.

Ultimately, says Ferdinandi, it encourages everyone to check that modern choices aren’t limiting whom we can serve. "The things we build today," he warns, "don’t always work for everyone–not only in hard-hit countries, but also local pockets of slower connection in the U.S. or London." The point of the web in the first place is universally opened advantages for everyone.