fidzu : Drupal

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.

Before we built our dashboard, someone on our platform team was manually generating reports for each of the 130 sites every quarter. Accessibility problems. Broken links. Duplicate content. All compiled, formatted, and sent out as a PDF.

It was better than nothing. But it had two serious problems.

First, people were unlikely to act on it. A PDF that arrives by email, detached from the website itself, is easy to file away and forget. Second, even the editors who did read it had no way of knowing whether they were improving until the next quarter's report showed up. The feedback loop was three months long.

This is a pattern that's common across organizations: the information that would most help editors do better work exists somewhere, but it's separated from the moment when they're actually ready to act on it. Updates get coordinated in chat threads. Content issues arrive by email. Broken link reports live in spreadsheets.

Editors are expected to carry all of that context across multiple tools and respond when something surfaces. For people whose primary job isn't web publishing, that's a lot to ask.
A dashboard brings that context back into the CMS, the place where the work actually happens.

Editors don't log into a CMS at random. They arrive with a purpose: fixing a typo, publishing a new story, or checking whether a content import ran correctly. Whatever the task, they're already in the right mindset. They're thinking about the website and are ready to make changes.

That makes login the ideal moment to surface what needs attention.

On our dashboard, we highlight the pages with the most accessibility errors. We show a list of broken links. We surface draft content that never got published. These aren't things editors have to go hunting for. They appear right when editors are ready to do something about them.

We also use the dashboard to answer questions editors commonly ask us. One recurring one: how does content get into the site from other university systems? Faculty profiles, events, and course data. All of it comes in through automated imports. Drupal has robust tools for this, but its default interface exposes every option and setting, which is overwhelming for a content editor. So we'd never exposed it to them at all. Editors had no visibility into something that was working fine. They just didn't know it.

The dashboard gave us a place to show a simplified view of those imports: here's when faculty profiles last synced, here's the kinds of courses that are imported to this site. Just enough to answer the question and build confidence. Support requests about content imports dropped significantly after we added that.

Information alone doesn't change much. The problem usually isn't awareness. It's timing.

When a broken link shows up in a quarterly report, the path from seeing it to fixing it is long and uncertain. Someone reads the report, makes a mental note, hopes they remember. Most of the time, they don't. By integrating that same information into the dashboard, the cycle changes:

Quarterly report → read → maybe remember → maybe act later

becomes

Login → see issue → click → fix

The feedback loop collapses from months to minutes. A broken link becomes a clickable item. A page stuck in draft becomes a quick decision. A list of accessibility errors becomes something an editor can start working through today.

One practical note from experience: some data sources introduce delays. Our broken link list comes from Siteimprove via API, which means that when an editor fixes a broken link, it won't disappear from the dashboard immediately. We didn't think about that until after we launched. It's not a dealbreaker, but it's worth designing around. At minimum, set expectations with editors so a fixed link that still appears on the list doesn't feel like a bug.

Dashboards aren't neutral. They're curated.

Every item that appears is there because someone, explicitly or quietly, decided it mattered. Looking at our current dashboard, I can tell you what it says about our priorities: we value accessible content (pages with the most accessibility errors are one of the most prominent blocks), and we value simplicity and iteration over comprehensiveness.

What's not on the dashboard is equally revealing. We don't have traffic metrics or analytics. For this particular higher ed institution, that's a deliberate choice. The focus is on content quality and editor success, not marketing outcomes. For other clients we work with, traffic data would need to be front and center. The dashboard has to reflect what that organization actually cares about.

The conversations that happen while building a dashboard are often more valuable than the dashboard itself. When you ask your team what should appear on it, you surface competing priorities that usually haven't been written down anywhere:

• What are editors most commonly asking us for help with?
• What do we wish editors were doing that they aren't?
• What should be the first thing someone sees when they log in?
• What action should be easiest to take?

Those questions don't always have obvious answers. But asking them is how you build something useful rather than something that just looks like a dashboard.

And don't let perfect be the enemy of good. Our first dashboard was basic: simple tables, in a single column, nothing animated or interactive. If you get a dozen useful things on a dashboard, the organization as a whole is going to be better for it. Start there, then build up.

There's a real risk that a dashboard drifts into feeling like a compliance tool, a place that exists primarily to point out what's wrong. If the only things editors see when they log in are warnings and error counts, the dashboard starts to feel like surveillance.

The same information can be framed very differently. A list of pages with accessibility errors isn't a punishment; it's a prioritized to-do list. A reminder about draft content that was never published helps an editor finish work that might otherwise be abandoned. A note that a component has recently changed gives editors a heads-up to check their pages before finding out something looks broken.

That last one is something we've gotten real value from. Our platform has 130 sites, which means making a breaking change to a component has a wide impact. Before we had the dashboard, that kind of communication was difficult. We still do targeted communications about breaking changes. But now we also use a simple announcements block (it pulls from a Google spreadsheet where each row is an announcement) to reach editors right where they're working. It's low-tech, but it means we can flag an upcoming change and tell editors exactly what to check. That's made us more comfortable shipping improvements we might otherwise have sat on.

The goal isn't to catch mistakes. It's to help editors succeed.

When your platform supports hundreds of editors across dozens of sites, traditional support breaks down fast. You can't train everyone personally. You can't answer every Slack message. And the editors who log in only a few times a year don't have the context that frequent users build up over time.

The platform itself has to take on more of that responsibility.

One thing that helped clarify our thinking: on the back end, your audience is actually more focused than it might seem. On the front end of a university website, you're trying to serve prospective students, current students, faculty, staff, donors, and more. But in the CMS, your primary audience is your content editors. There might be a few other users (stakeholders who log in occasionally to get a lay of the land, or interns assigned to clean up a single page), but by and large, you're designing for a pretty clear group.

For us, that meant focusing our first version on the editors who log in regularly and need to take action. We can add more guidance for infrequent users in later iterations. Starting with the core use case meant we shipped something useful without trying to solve everything at once.

A well-designed dashboard becomes a quiet guide embedded in the platform, helping editors move forward without needing someone from the platform team to step in. At scale, that kind of built-in guidance isn't just helpful. It's essential.

In our session, "A Dashboard that Works: Giving Editors What They Want, But Focusing on What They Need," we'll share the story behind a dashboard built for 500 editors across 130 sites - the decisions we made, the things we got wrong, and how we figured out what actually belongs on a dashboard and what doesn't.

We'll walk through:

• How we identified what editors needed versus what they asked for
• How we balanced editorial priorities with technical realities
• What we'd do differently if we were starting over

Whether you manage one site or one hundred, we hope you leave with something you can use.

If you're going to DrupalCon Chicago 2026, please make sure to attend the session with Dave Hansen-Lange and Albert Hughes.

Where: Hilton Chicago, 720 S Michigan Ave, Chicago, IL 60605, Williford B (3rd Floor)

When: Tuesday, March 24, 2026, 9:00-9:50am

For session details and tickets, click here.