Drew McLellan's conversation with Chris Ferdinandi on the Smashing Podcast covers the idea Ferdinandi outlined in an article on his Go Make Things site: the web as a place permanently in flux, where today's tooling is often just a way station to whatever the platform absorbs next.
The cyclical nature of web tooling
Ferdinandi frames the industry's habits as cyclical: techniques get learned, unlearned and relearned in slightly different packaging. McLellan reaches for a 1980s hi-fi analogy — silver separates giving way to black, then back again — but Ferdinandi treats the pattern as larger than aesthetics. The useful part is recognizing that libraries tend to be experiments in how to do something, and that the platform later folds the best of those experiments in.
He describes jQuery as the clearest case of paving the cow paths, a debt he says the methods he relies on in the browser still owe to it. In the IE6–8 era, even collecting elements by class was laborious — you could read an attribute value, not a class list, and had to dissect it yourself. jQuery exposed the CSS selector API in JavaScript and made targeting trivial, and that approach became the default across libraries. Browsers answered with querySelector and querySelectorAll, the classList API, and methods for moving elements such as prepend, before, after and remove. Sizzle, jQuery's selector engine, then adopted the native methods where a selector could be resolved natively. Seeing that cycle, Ferdinandi says, made him less angry about the damage modern frameworks sometimes do.
Compiler-first tools and the "what next" question
After the lean-web swing that produced Petite Vue, Alpine.js and Preact, Ferdinandi sees growth in a different direction: backend compilers such as Svelte, SvelteKit and Astro, where developers author with state-based UI in a JavaScript-style approach and the build step emits mostly HTML plus only the JavaScript needed. The output resembles traditional DOM manipulation even though the input looks like something written for React or Vue.
Whether those tools are the future or a transition is the open question from his article. He compares them against two historical precedents: React, which became entrenched for the industry, and Umbrella JS or Shoestring from Filament Labs, which were popular briefly before browsers caught up and they vanished. His own view has shifted. Preact and Solid now look more transitional to him; Astro and Svelte look likely to be the next wave, at least until browsers close more of the gap.
The gap he keeps returning to is a native DOM diffing method as simple to use as innerHTML — pass in an HTML string and have everything inside an element match it without destroying the rest of the DOM. Until that exists, he expects tooling to persist. He also notes related work in progress: a View Transitions API that works in Chrome Canary and nowhere else, and an API in the works for sanitizing HTML strings that has not shipped anywhere yet. Much of what gets built now is fetching data and updating the UI in response, which DOM manipulation can do but far more painfully. State-based UI earns its appeal there; his objection is that it is also applied where it is inappropriate, making things harder to maintain.
API consistency, and why developers still reach for libraries
Consistency is the other thing Ferdinandi wishes the platform handled better. jQuery's API is uniform in how methods are authored and behave, and he contrasts that with native JavaScript: querySelector and querySelectorAll arguably should be one shorter method returning an array rather than a NodeList, since arrays offer more iteration and manipulation options; classList.add and classList.remove arguably should be callable directly on the element as addClass and removeClass. Those rough edges, death by a thousand cuts, push developers toward tools with smoothed-over APIs and good documentation — even where the native method already does the job. MDN fills the gap, but not perfectly.
McLellan notes that framework method names tend to be guessable: if documentation lists remove, you can assume add does the opposite. Native naming has not always followed that logic. The conversation turns to SmooshGate, where MooTools had an array method of the same name attached to Array.prototype — Ferdinandi recalls it as flat — and implementing it as intended would have broken sites using MooTools. McLellan calls the prospect laughable in hindsight, but points to the underlying rule that keeps it real: once something is deployed on the web, it should keep working, and browsers continue supporting deprecated features anyway. Ferdinandi cites marquee, deprecated long ago and still functional in every major browser for legacy reasons, which he calls part of the core ethos he loves.
What is landing in the platform, and what's still missing
McLellan brings up the Popover API and its top layer, which removes the need to fight z-index to keep something on top and bakes in accessible dismissal — subtleties that are easy to get wrong in a JavaScript implementation. Built-in behavior means the platform moves more slowly than a framework, weighing robustness, performance, accessibility and backward compatibility, but arrives at a better answer with oddly named methods. He also points to Rachel Andrew's episode on Google Baseline, the initiative for indicating which features are supported in place of a browser support matrix, and to her monthly roundups on web.dev of what is now stable — a changelog for a very large framework, mostly because that framework is the native web platform.
On what he is personally waiting for, Ferdinandi sets page transitions aside; he never understood the excitement, even though he knows it drives many developers' preference for SPAs. DOM diffing remains the big one. His answer for most anticipated API, though, is Temporal — still at stage three, so not imminent. Two things plague the Date object for him: time zones, because specifying a time zone or determining the one a date was created in is hard, and relative time, because deriving months from two dates means doing math and making assumptions once you pass days, since months vary in length. Temporal is slated to give first-class time zone support and specific methods for relative time between temporal objects, including one that spares you the "seven days becomes weeks, four weeks becomes months" logic. He notes the spec lives at tc39.es/proposaltemporal, is far more readable than typical W3C material, and borrows from Moment.js and date-fns — another instance of libraries paving the cow paths. McLellan adds localization: native date objects can be represented as localized strings, which libraries that output a fixed phrase like "two weeks ago" cannot translate.
Paving cow paths implies a cow path must exist first, so McLellan asks whether the approach leaves the platform permanently behind frameworks. Ferdinandi mostly agrees, and offers the Toast API Google tried to ship a few years back as a case where it was done quickly, without cross-browser consensus and before the path existed — it met resistance. He still uses libraries constantly, though usually for media work such as expanding photo galleries with slide navigation, where the details are not worth managing himself.
The pattern he wants broken
The cycle Ferdinandi would like to end is the one where a small tool does one thing well, accumulates features, grows into a black hole that swallows the industry, and then spawns smaller alternatives. He compares it to reaching for a Swiss Army knife when a toothpick, a spoon or scissors would do. McLellan connects this to the Unix philosophy of small tools with a common interface, and Ferdinandi allows that he had not considered it before but thinks the tendency may come from small libraries by the same author working well together, while libraries from different authors are harder to connect. He wishes for a mechanism that rewarded composability, and recalls jQuery's extend method or plugin hook, which let people attach to the jQuery prototype non-destructively — a lightweight core to bolt things onto, ideally from the platform, since a third-party interface would never be agreed upon.
Does he consider frameworks essential to the ecosystem? More than he would like to admit, yes — but he wants them to do one thing well and stay a manageable size. Preact stays around three kilobytes minified and Gzipped with a very React-like API, fewer internal abstractions, and dynamic updates that happen orders of magnitude faster than React's. He is fair about why: Preact is newer and benefits from modern JavaScript methods that did not exist when React was created, so matching it would likely take a substantial rewrite.
Migration advice and the accessibility debt
For a React developer building client-side SPAs who wants to try the platform-native approach, Ferdinandi offers two routes. The first is swapping React for Preact, plus the compatibility shim that smooths the difference, for an immediate size and performance gain with no other changes. The second, which he considers more interesting and future-proof, is Astro: author in React, let the compiler emit mostly HTML with a little JavaScript, strip React proper, and ship only the interactivity you need. He cites Jason Lengstorf of Netlify's developer relations team, who took a Next.js app, kept 90% of the code, made small changes for how Astro hooks in, ran the compiler and ended up with the same site and roughly the same code but 90% less shipped JavaScript.
His worry is that Astro becomes a band-aid, letting teams keep their existing habits and temporarily reduce the damage rather than addressing the systemic issue. He points to Svelte and Astro both working toward multi-page apps that progressively enhance themselves into single-page apps through hydration — which, he notes, lands you back at an SPA. He references a talk by Svelte and SvelteKit creator Rich Harris arguing that SPAs are better for users because JavaScript is not fetched and rerun on every page load, and acknowledges SvelteKit's neat approach of intercepting ordinary hyperlinks and checking whether they point to the current page or an external site. What those arguments omit, in his view, is the accessibility work SPAs break and developers must add back: letting a screen reader user know the UI changed without being obnoxious (an ARIA live attribute on the whole page is not an option), whether to shift focus to the H1 and what to do when there is none, whether to announce page load through a visually hidden element, and whether to return keyboard users to the top rather than stranding them mid-page. The right answer is contextual and hard for a library to implement generally, and assuming developers will always do the right thing is optimistic. He is excited about these tools and also sees them repeating old mistakes in a new form.
His outlook nonetheless is less bleak than a few years ago. The shift toward mostly HTML with sprinkled JavaScript and progressive enhancement is a good thing. Astro and SvelteKit fall back to a multi-page app with server-side HTML if the enhancing JavaScript fails to load — closer to the old "isomorphic apps" promise than the industry has come before. He still personally prefers plain multi-page apps, suspecting he is in the minority. McLellan closes the loop on progressive enhancement as a broad solution. Asked what he is learning, Ferdinandi says he is finally digging into ESBuild after years of cobbling together Rollup, a separate NPM Sass compiler and his own build tooling; Rollup v3 broke much of his setup, so he is still on Rollup 2, and ESBuild's ability to compile CSS as well as JavaScript and concatenate messy CSS imports into a single file has him questioning whether to drop Sass for native CSS and convert his Sass variables to CSS variables.
