Second-Generation Tools Aim To Keep Developer Convenience, Drop The Cost To Users
Chris Ferdinandi rejoins the podcast roughly 15 months after his first appearance, where the conversation centered on whether modern best practices—particularly heavy client-side JavaScript—were doing more harm than good to the web. That earlier episode became one of the most shared in the show's history. Since then, the technology landscape has shifted, but not always in the ways one might expect.
Ferdinandi notes that while web technology changes rapidly, developer habits move slower, creating longer arcs where approaches pile up before swinging in another direction. His two central concerns from the previous discussion remain: tools that prioritize developer convenience at the user's expense, and the questionable assumption that these tools genuinely improve the developer experience for everyone. On the latter point, he acknowledges that frameworks can benefit team environments, but for solo developers, they often create more friction than they solve.
The most notable development in the past year, he says, is the emergence of what he calls a "second generation" of tools that retain the benefits of client-side frameworks while stripping away the punishing effects on end users. This manifests in two major trends.
Microframeworks And The Shift Toward Compilers
The first trend is the rise of microframeworks. Where React, Vue, and Angular dominated as large, all-encompassing libraries, smaller alternatives are now coming into their own. Ferdinandi cites Preact, a three-kilobyte React alternative that uses the same API, ships considerably less code, and runs faster on updates. He also points to Alpine JS, which was inspired by Vue and in turn prompted Vue's creator, Evan You, to release Petite Vue, a 5.5-kilobyte subset of Vue optimized for progressive enhancement. These are still client-side libraries, but with the intent of shipping less code, reducing abstractions, and placing less of the performance burden on the user.
The second, more compelling trend is the shift from libraries to compilers. This movement was kicked off by Rich Harris with Svelte, which takes the concept of state-based reactivity but, instead of running in real time in the browser, compiles authored code into plain HTML and vanilla JavaScript via a build tool. The result is that the same developer convenience of state-based UI comes with far fewer client-side abstractions. Newer tools like Astro build on this idea, allowing developers to mix components from Vue, React, Svelte, or vanilla JavaScript and compile everything into lightweight vanilla output.
Ferdinandi sees this as a positive direction: rendering HTML in the browser as little as possible, favoring more static HTML and less JavaScript in the final output.
A Natural Pendulum Swing, Not A Marketing Push
Asked whether this is the ecosystem responding to quiet dissatisfaction with heavy frameworks, Ferdinandi agrees it's a natural swing. Performance-minded developers have been vocal, but he suspects vocal minorities are driving much of the narrative. The more persistent issue, he believes, is that the development process itself has become over-complicated.
He draws a parallel to jQuery: the web saw a swell of JavaScript usage, the platform eventually absorbed those conventions into native APIs, and then a slow decline followed. Libraries, he argues, have served an important role in paving the way for native features. They've done damage, but they've also shown what the platform could eventually do.
On whether the industry is just stacking bricks into a wobbly tower, Ferdinandi gives a more measured answer than he might have five years ago. "I've started to talk in fewer absolutes." A key drawback of frameworks is the dependency treadmill: a site authored in pure HTML, CSS, and JavaScript can sit untouched for five years and still work, whereas framework-based projects require constant upkeep.
Yet there's a notable counterpoint. WebAIM's annual automated accessibility survey consistently finds that sites using UI rendering libraries have more accessibility issues than those that don't—except this year, sites using React actually had fewer issues. He attributes that to a strong accessibility push in the React community. Complex components like tabs, disclosure widgets, and sliders are genuinely hard to build accessibly with vanilla JavaScript alone. Libraries can fill that gap well, but his ideal endgame is native browser components that handle these behaviors out of the box. The <details> and <summary> elements are a model for this: accessible by default, progressively enhanced without JavaScript, stylable with CSS, and exposing a toggle event for extending behavior.
Build Steps: Red Flag Or Necessary Evil?
Modern browsers are capable enough that HTML, CSS, and JavaScript could theoretically be deployed as-is. Ferdinandi's take: not having a build step is the gold standard, but it's not always realistic. His own site has grown to several thousand pages, making a static site generator necessary. What matters is the direction of the build step—tools that push runtime work onto the developer and ship less to the browser are good. A build process for a one- or two-page marketing site is a red flag; using one to produce a smaller, more efficient end-user experience for a complex application is not. Astro is compelling precisely because its build step serves the user, offloading computation to build time rather than page request time.
On frameworks enforcing uniform working practices in large teams, Ferdinandi concedes this is a real benefit he previously downplayed. Frameworks offer guidelines, but not necessarily strict rules—searching "how to do X with React" yields half a dozen different approaches. He counterpoints that framework-based projects still go off the rails without strong internal standards. The emerging smaller libraries and compilers offer some of that structure without the same user cost.
There's a flip side too: a heavy JavaScript toolset can gate keep developers who specialize in HTML, CSS, or accessibility and don't have JavaScript as a core competency. Framework conventions can make a codebase consistent across contributors, but leaning on browser-native features opens up the development process to a wider range of skills.
The Pressure To Always Adopt The Latest
Ferdinandi argues that understanding platform fundamentals makes it easier to evaluate and adapt to new technologies. He learned JavaScript through jQuery, then backtracked to vanilla—a path made possible when ES5 took many of its cues from jQuery. State-based libraries haven't yet reached that same level of one-for-one mapping to platform features, but they're headed in that direction.
The industry pressure to constantly embrace the newest tools, he notes, often comes from conference stages and big tech companies, but the majority of the web runs on older, stable technology. "A lot of really important applications run on Python or PHP, or as a backend with just some sprinkling of lightweight HTML, CSS, and JavaScript on top." jQuery still underpins a surprising amount of critical infrastructure. These jobs may not be the most exciting, but they often come with better work-life balance and steady pay.
The related fallacy is pre-engineering every small project as if it were serving a Facebook-sized audience. Big companies using old, reliable technology because they've "got far too much momentum" demonstrates that enterprise-grade approaches from large businesses aren't automatically the right starting point for everyone. "You're pre-engineering for a problem that you don't have to the detriment of some problems that you do." Assuming that whatever Google, Facebook, or Twitter does is good practice ignores the company-specific trade-offs (and occasional executive whims) behind those decisions. "If it's good enough for Google" is the modern version of "no one got fired for hiring IBM," and it's not always a sound rationale.
Jamstack: Either An Improvement Or A Different House Of Cards
Jamstack, Ferdinandi says, is a broad term covering everything from huge client-side single-page apps to flat HTML files served from a CDN. Both technically qualify, but their performance characteristics couldn't be more different. The appeal is having HTML already built and served, ideally from edge CDNs, cutting out the expensive server-side processing that traditional CMS-driven sites like stock WordPress perform on every request. A Jamstack approach can bring load times down dramatically.
It's not inherently better than server-side rendering, but in many cases—with a static site generator, for instance—it dramatically improves performance. However, he observes an amusing pattern: the industry keeps reinventing PHP. When Next.js launched with features like server-side rendering, he thought, "That's like PHP, but a decade later." Even the JIT Jamstack experiments by Zach Leatherman with Eleventy recreate PHP patterns in Node. The underlying tower of cards remains, with only the location and responsibility shifting.
Industrialization And The Need For Balance
Ferdinandi draws a farming analogy: hand-milling wheat is wildly inefficient, but factory farming has its downsides as well. The web development equivalent is that tools allow more efficient, higher-quality output, but can also generate "a bunch of garbage" and ship it fast. The line between artisan work and industrial overload isn't clearly drawn. He's no longer as purist as he once was—he acknowledges both good and bad in commercialization—but remains bothered that the average web has barely improved its load times despite the platform being four to five times faster over the decade. "We could have a really fast resilient web right now if we wanted one, but we don't." Shiny new things often ship without adding real user value.
He doesn't believe we're asking the web to do too much. The problem isn't ambition; it's that standards processes move more slowly than developer demand, and browsers can struggle to keep pace. That creates gaps that libraries fill, and then a slow trickle as the platform catches up. Apple's slower investment in web technologies remains a frustration, especially for progressive web apps, which continue to trail native apps on iOS.
What's on the Horizon
Ferdinandi highlights several platform improvements in the works: a native API for smooth page transitions between views, native HTML sanitization for security, and ongoing potential for native DOM diffing as a performance baseline. The bigger trend remains the shift toward pre-compiled output and static generation.
"I see us emerging from the dark ages slowly," he concludes. In seven to ten years, developers might ask why everyone still starts projects with React or Vue, much as they ask why anyone still uses jQuery today—while a new generation of libraries inevitably emerges for new problems.
One Twitter observation resonated with both speakers: "Every time I update something, everything gets broken." Ferdinandi says that pain never fully goes away, even in pre-build-tool eras—jQuery plugin version mismatches had the same effect. It's just more pronounced now with command-line errors that "spit out all these terrible errors that don't make sense." His ongoing solution remains minimizing dependencies.
[Placeholder
refers to the guest's GitHub profile link, which has been rendered as the first item in the episode's show notes. The remaining show notes and further reading links follow.]
Show Notes
Recent articles mentioned in the episode's weekly update include Sam Poder's guide to Next.js wildcard subdomains, Dan Shappir's Wix performance case study, John C Barstow's dyslexia-friendly mode tutorial, Nirmalya Ghosh's advice on maintaining large Next.js apps, and Jhey Tompkins' 3D CSS Flippy Snaps tutorial with React and GreenSock.
Ferdinandi has recently been going deep on service workers, finding them valuable for delivering single-page-app-like performance in multipage apps without complex JavaScript routing or in-memory caching. He's also studied serverless to gain server-side benefits without the management overhead, and has put together courses on both topics, available at vanillajsguides.com.
His book is at leanweb.dev, and his developer tips newsletter—now over 12,000 subscribers strong—can be found at gomakethings.com. He's on Twitter at @chrisferdinandi, and his podcast is available wherever you typically listen.
For further reading, Tech Report readers may enjoy this selection of continuing-education and career pieces: advice for developers just starting out, reflections after selling a startup, practical SVG coding recipes, and a framework for understanding what AI really means.
