Jonas Pfalzgraf

Posted on Apr 6

bQuery.js v1.9.0 🥂 Still the jQuery for the Modern Web Platform — but sharper than ever

#webdev #programming #javascript #beginners

A modular, zero-build JavaScript toolkit for people who want modern reactivity, Web Components, and DOM ergonomics without marrying a giant framework

Hi everyone! 👋

A little while ago, I wrote about bQuery.js and called it what it honestly feels like: the jQuery for the modern web platform.

And yes — I still stand by that.

But bQuery didn’t stop there. The ecosystem kept evolving, the APIs matured further, and with @bquery/bquery 1.9.0, the project feels even more like a serious option for people who want modern frontend capabilities without immediately summoning an entire framework stack from the underworld.

Because let’s be honest: sometimes you don’t want to set up a mega toolchain, configure seventeen plugins, and debate hydration strategies for three business days.

Sometimes you just want to:

select DOM elements
react to state changes
fetch some data
build a component
ship your app
and go to sleep at a reasonable hour

That’s where bQuery still shines.

🎉 What is bQuery again?

If you haven’t heard of it yet:

bQuery is a modular JavaScript/TypeScript library published as @bquery/bquery on npm. It aims to combine the directness of classic DOM libraries with modern frontend features like signals, typed Web Components, async composables, forms, i18n, routing, SSR, accessibility helpers, and more. Your earlier article also highlighted its modular architecture and zero-build approach. (dev.to)

So yes, the “jQuery for the modern web platform” label is not just marketing fluff. It’s actually a pretty accurate mental model.

You get:

DOM ergonomics
fine-grained reactivity
progressive enhancement
modular imports
security-conscious APIs
native platform-first thinking

And that combo is still weirdly rare.

🤔 Why this matters in 2026

The frontend world still has a small addiction problem.

Not with caffeine.

Okay, also with caffeine.

But especially with complexity.

There are plenty of cases where React, Vue, Angular, Svelte, Solid, or whatever else absolutely make sense. I use frameworks too. This is not a crusade.

But there’s also a huge space between:

“just use vanilla JS”
and
“spin up an enterprise-grade framework architecture for a settings panel”

That middle ground is where libraries like bQuery are genuinely interesting.

If you’re building things like:

internal tools
progressive web enhancements
browser-based utilities
Web Components
small to mid-sized apps
interactive islands on otherwise static pages
prototypes that accidentally became real products

…then bQuery makes a lot of sense.

🚀 Getting started

You can install it the normal way:

npm install @bquery/bquery

Or with pnpm / bun if you’re living the good life:

pnpm add @bquery/bquery
# or
bun add @bquery/bquery

Your previous article also showed that bQuery can be used directly in the browser via ES modules, without forcing a traditional build step, which is one of its most compelling traits. (dev.to)

That alone is such a refreshing thing.

No “before you begin, initialize six config files.”

Just code.

✨ The familiar part: DOM manipulation that doesn’t feel painful

The easiest way to understand bQuery is to start with the part that feels familiar.

import { $, $$ } from '@bquery/bquery/core';

$('#app')
  .addClass('ready')
  .css({
    color: 'rebeccapurple',
    fontSize: '1.1rem'
  })
  .text('Hello from bQuery!');

$$('.card').each((el) => {
  el.toggleClass('visible');
});

If you ever used jQuery, this feels immediately understandable.

But unlike old-school jQuery, this is not where the story ends.

The core module gives you a chainable, ergonomic API for:

classes and attributes
events
DOM traversal
form helpers
dimensions and positioning
content updates
insertion and replacement utilities

And one detail I particularly like: sanitization-aware HTML handling. In your earlier write-up, you pointed out that html() is sanitized by default and htmlUnsafe() is the explicit opt-out, which is a very sane design choice. (dev.to)

That’s one of those “small” details that actually says a lot about a library’s philosophy.

⚡ Signals, because modern state should not be miserable

This is where bQuery stops being “just a DOM helper” and starts becoming something much more interesting.

import { signal, computed, effect, batch } from '@bquery/bquery/reactive';

const firstName = signal('Jonas');
const lastName = signal('Pfalzgraf');

const fullName = computed(() => `${firstName.value} ${lastName.value}`);

effect(() => {
  document.title = fullName.value;
});

batch(() => {
  firstName.value = 'Josun';
  lastName.value = 'LP';
});

This is the kind of API I really like:

readable
explicit
modern
not overloaded with ceremony

Your March article already covered that bQuery’s reactive layer includes things like signals, computed values, effects, batching, watchers, persisted signals, and linked signals, which makes it much more than a tiny convenience wrapper. (dev.to)

And honestly?

Signals are one of the best things that happened to frontend state management in recent years.

They’re simple enough to understand quickly, but powerful enough to build serious UI logic on top of them.

🌐 Async data without writing the same boilerplate forever

Another area where frontend code often becomes deeply annoying: async state.

Loading states. Error states. Refresh logic. Cleanup. Watching dependencies. Re-running on change.

Fun. So much fun. Absolutely thrilling. Definitely not repetitive at all.

bQuery wraps this into composables like useAsyncData and useFetch, which your earlier article described in detail, including support for lifecycle state like pending/success/error and HTTP niceties like query params and response parsers. (dev.to)

A simple example:

import { useFetch } from '@bquery/bquery/reactive';

const users = useFetch('/users', {
  baseUrl: 'https://api.example.com',
  query: { page: 1 }
});

That kind of API is exactly what I want for smaller apps and tools:

expressive
low-friction
practical
doesn’t force me into a giant framework runtime

🧩 Web Components that don’t feel like punishment

I’ve said it before and I’ll say it again:

The Web Component API is powerful, but raw Web Component authoring can be annoyingly verbose.

That’s another place where bQuery becomes genuinely useful.

Your previous article showed that bQuery’s component layer supports typed props, configurable Shadow DOM usage, sanitized render output, lifecycle hooks, local reactive helpers, and external signals for rerendering. (dev.to)

That means you can build native custom elements without drowning in low-level setup code.

And that’s huge.

Because Web Components are great when you want:

framework-agnostic components
encapsulation
reusability across projects
native browser primitives
long-lived maintainable UI building blocks

But they become a lot more fun when the authoring experience is decent.

🛠️ Why I like the philosophy behind bQuery

There are lots of libraries that can do one or two of these things. That’s not the special part.

What I like about bQuery is the overall mindset:

1. Platform-first

It builds on browser capabilities instead of fighting them.

2. Progressive

You don’t need to buy into everything at once.

3. Modular

Import what you need. Leave the rest alone.

4. Modern

Signals, typed components, async composables, SSR support, i18n, accessibility tools — this is not “nostalgia jQuery”.

5. Pragmatic

It feels built for developers who actually want to get things done.

And that last point matters a lot to me.

Because sometimes frontend tooling feels like it was designed primarily to create conference talks.

bQuery feels more like it was designed to solve real problems.

📦 Ecosystem breadth: more than just selectors

One of the strongest things in your previous bQuery article was how clearly it showed the ecosystem breadth. bQuery is not just core DOM helpers — it spans modules for routing, global store management, forms, i18n, accessibility, drag-and-drop, media helpers, plugins, devtools, testing, and SSR. (dev.to)

That matters because it means the project can scale with your needs.

You can start small:

“I just want cleaner DOM utilities”

And later move into:

reactive state
reusable components
shared stores
localized UI
accessible interactions
server-rendered output

without switching mental models every five minutes.

That’s a pretty compelling story.

🆕 Why write about 1.9.0 specifically?

Because version bumps are only interesting if they reflect maturity.

And that’s the real point here.

For me, 1.9.0 is less about “look, number bigger” and more about this project continuing to feel like a serious, coherent toolkit rather than a random utility collection. The npm package exists as @bquery/bquery, the source is maintained in the bQuery/bQuery GitHub repository, and there’s also an official project site available. (dev.to)

That coherence is what makes a package worth adopting.

A lot of libraries have nice APIs in isolated examples.

Far fewer feel like they have a real philosophy and an ecosystem that fits together.

bQuery increasingly does.

🧪 Who should use bQuery?

I’d especially recommend taking a look if you are:

a developer who likes vanilla JS, but wants better ergonomics
someone building small to medium-sized frontend apps
into Web Components
doing progressive enhancement
tired of framework overhead for simpler projects
looking for a modern, modular toolkit instead of a monolithic solution

I would especially keep it on my radar for:

dashboard tools
admin panels
widgets
browser tools
static sites with interactive islands
component libraries based on native custom elements

😅 Who is it not for?

Let’s be fair.

If your team already has a deeply established framework ecosystem with:

strict conventions
internal tooling
existing component libraries
SSR infra
testing patterns
onboarding optimized around one framework

…then bQuery may not replace that.

And that’s okay.

Not every tool has to replace everything.

Sometimes being the best fit for a certain class of projects is more valuable than pretending to be universal.

💡 My honest takeaway

What I like most about bQuery is that it feels like it respects both:

the web platform
and the developer’s time

That’s a rare combo.

It gives you modern frontend capabilities without acting like the browser is an annoying implementation detail.

And it gives you structure without forcing a whole religion on you.

That alone makes it worth paying attention to.

🔗 Check it out

If you want to explore it yourself:

npm: @bquery/bquery
GitHub: bQuery/bQuery
docs / website: bquery.flausch-code.de

Those are the official package, repository, and project site references you shared for this article request. (dev.to)

🎯 TL;DR

bQuery 1.9.0 continues to be one of the more interesting “modern web without unnecessary drama” libraries out there.