The browser has grown up. Have we?

jQuery did not become dominant because developers were lazy. It solved real problems. Browsers were fragmented. There was no consistent way to select elements from the DOM. Event handling varied. AJAX required wrestling with verbose XMLHttpRequest code and awkward callback patterns. jQuery unified those concerns behind a clean, approachable interface: the dollar sign selector, the on method, simple get and post helpers, animations like fadeIn and slideUp.

It was a necessary abstraction at the time.

Over the years, though, the platform evolved. Browsers standardized. APIs matured. ES6 modernized the language. CSS grew far more capable. Many of the problems jQuery once addressed were absorbed directly into the browser.
The platform changed.

We may be living through a similar moment with modern frameworks. React and other tools solve meaningful problems. They help teams move quickly and provide structure, especially for developers early in their careers. In many cases, they are exactly the right choice.

But over time, thoughtful decisions can quietly become defaults. A subtle assumption can creep in: if something feels modern or interactive, it probably requires a framework.

The shift is not dramatic. It is behavioral. Instead of beginning with the problem, we sometimes begin with the stack. If an interaction feels dynamic or app-like, we assume it needs something larger.

Frameworks offer guardrails and shared patterns, and that consistency is valuable. But when the tool becomes the starting point for every conversation, it can narrow the range of options we consider. We stop asking what the browser already provides. We begin to treat complexity as the baseline for modern work.

This is not bad architecture.It is often just unexamined architecture.

It shows up in small ways: adding a dependency before exploring a native API, reaching for a heavy client-side solution when progressive enhancement might be enough, and introducing new tooling because that is what modern projects tend to do. Each decision is understandable on its own. Over time, though, they expand the surface area of a project: more dependencies, more upgrades, more maintenance. Fewer dependencies can mean fewer upgrades to manage, fewer compatibility conflicts, and a smaller maintenance surface over time.

While we have been refining our build pipelines and debating frameworks, the browser has continued to evolve. Quietly and steadily. Modern JavaScript is not what it was 10 or even five years ago. Today’s browsers ship with stable, well-documented APIs that address many of the use cases we once handled with libraries.

Need to know when something enters the viewport? There is Intersection Observer.

Need to react to changes in the DOM without polling? Mutation Observer is built in.

Need to respond to screen size changes? MatchMedia handles that cleanly.

Need to persist data between sessions? Local storage is there.

Need to integrate with a device’s native share dialog? There is an API for that.

CSS has evolved as well. Layout systems, transitions, scroll behaviors, and positioning features eliminate entire categories of JavaScript we once considered unavoidable.

And the language itself has matured. Modules, promises, async and await, richer array methods, cleaner syntax. These are no longer experimental features. They are part of the platform.

None of this is particularly flashy. It is simply what the browser now provides.

The important point is not that every project should avoid frameworks. It is that many of the problems we once solved with external libraries now have first-class support in the browser itself. So, what does that mean in practice?

Add one small pause to your workflow. Before installing a dependency, check the platform. Search MDN. Look up “browser API for…” and see what comes back. You might discover that Intersection Observer replaces the scroll library you were about to add. Or that CSS handles the animation without JavaScript at all.

It means reframing how you evaluate tradeoffs. When a feature request comes in, write down the requirement in plain language before you write down the stack. What actually needs to happen? A modal opens. Content animates on scroll. State persists between visits. Once the behavior is clear, ask whether the browser can already do it.

It means keeping a short list of native capabilities in your mental toolkit: MatchMedia. Local storage. Native form validation. ResizeObserver. The goal is not to memorize every API. It is important to remember that vanilla JavaScript is an option.

It also means normalizing this conversation on your team. When someone suggests a new library, ask a simple question: is there a native way to do this? Not as a challenge. As due diligence.

None of this requires abandoning modern tooling. It simply widens your decision tree. And it costs almost nothing but attention.

In our session, “Elevating Drupal Experiences with Vanilla JavaScript,” we’ll share how we’ve used modern browser capabilities to build rich, interactive experiences within Drupal — not by rejecting frameworks, but by pairing Drupal’s strengths with what the browser already does well.
We’ll walk through:

• Where native APIs replaced heavier dependencies
• Where progressive enhancement simplified complexity
• Where we had to rethink our own assumptions

More than anything, we hope it sparks a conversation.

If you’re going to DrupalCon Chicago 2026, please make sure to attend the session with Mari and Andrés.

Where: Hilton Chicago, 720 S. Michigan Ave., Chicago, IL 60605, Salon A-2 (LL)

When: Tuesday, March 24, 2026, 4:10–5:00pm

For session details and tickets, click here.