DEV Community: Jonas Pfalzgraf

[Boost]

Jonas Pfalzgraf — Sat, 06 Jun 2026 14:35:18 +0000

Jonas Pfalzgraf

May 28

bQuery.js Grows Up: From Tiny jQuery Tribute to a Full-Stack Framework — and a Brand New Home at bquery.js.org 🎉

#webdev #javascript #typescript #opensource

7 min read

[Boost]

Jonas Pfalzgraf — Fri, 29 May 2026 09:21:52 +0000

Jonas Pfalzgraf

May 28

bQuery.js Grows Up: From Tiny jQuery Tribute to a Full-Stack Framework — and a Brand New Home at bquery.js.org 🎉

#webdev #javascript #typescript #opensource

7 min read

bQuery.js Grows Up: From Tiny jQuery Tribute to a Full-Stack Framework — and a Brand New Home at bquery.js.org 🎉

Jonas Pfalzgraf — Thu, 28 May 2026 19:41:00 +0000

Hi everyone! 👋

bQuery.js started last autumn with a question I couldn't stop chewing on: why was jQuery actually invented?

Strip away two decades of memes and "jQuery is dead" hot takes, and the answer is pretty simple. jQuery existed to make developer life easier under the conditions of its time — inconsistent browsers, a painful DOM API, no fetch, no querySelector, no module system worth speaking of. It papered over the platform because the platform needed papering.

So I started asking the modern version of that question: if you sat down today and tried to do for 2025+ what jQuery did for 2006, what would you actually build?

Not "jQuery, but updated". Not "jQuery, but TypeScript". An honest answer to: what are today's pain points, and what would a library look like that fixes them without adding new ones?

That question is where bQuery comes from. A few months later, it's not really a library anymore — it's a full-stack framework. And to celebrate that, the docs have officially moved into their own home:

🥂 bquery.js.org — your new bookmark for everything bQuery.

Let me tell you how we got here.

📖 Chapter 1 — Three Non-Negotiables

When I started sketching this thing last autumn, three principles were locked in from day one. Everything else had to bend around them.

1. Zero mandatory build step. You should be able to drop a single <script type="module"> into a plain HTML file and write something useful in 12 lines. No node_modules. No bundler config. No vibes-based tsconfig.json you cargo-culted from a tutorial. The platform is good now — the library shouldn't gatekeep you behind a toolchain.

2. Single import, with or without CDN. One entry point. You either install from npm/bun/pnpm, or you point at unpkg/jsDelivr. Either way, the API is identical. No "CDN edition" vs. "module edition" mind games.

3. Real tree-shaking. Importing bQuery shouldn't drag in the whole framework if you only wanted $. Every module is its own explicit entry point. You pay for exactly what you import — nothing more.

Those three rules made the design decisions almost automatic. They're also the reason it grew the way it did: when the API is honest about cost, you can keep adding without bloating anyone's bundle.

The first version looked exactly like you'd expect:

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

$('#button').on('click', () => {
  $$('.card').addClass('hovered');
});

That's it. A typed, chainable, modern DOM helper. Zero build step required. Zero runtime dependencies. Roughly the energy of "jQuery, but it understands what unknown means".

It scratched the itch. People used it. The story could have ended there.

It didn't.

🌱 Chapter 2 — "Hm, this could use signals"

The first time the project stopped being a library was the day I added signals.

Once you have reactive primitives, suddenly $('#counter').text(...) isn't just a one-shot DOM write — it's an expression of state. And once you have that, you want components. And once you have components, you want a router. And once you have a router, you want SSR. And once you have SSR…

You see where this is going.

Crucially: none of that broke the three rules. Tree-shaking meant new modules didn't tax the people who only wanted $. The single-import contract held. The CDN entry still worked. Every release tried to keep the same jQuery-ish hand feel, but the surface kept growing:

Signals & effects for reactive state
Components built on the native Web Components API — no virtual DOM, no shipping a runtime renderer
Views & directives (bq-on, bq-html-safe, bq-memo, bq-cloak…) for declarative templates without JSX
Forms with validation, dirty/touched state, the whole thing
Router with guards, lazy routes, navigation results, and a proper useNavigation() composable
i18n with locale negotiation, RTL detection, relative time, and list formatting
A11y helpers — live regions, focus management, prefersReducedMotion, forced colors, scroll-lock, the lot
HTTP / fetch composables that plug straight into signals — polling, pagination, REST helpers, WebSocket and SSE
Drag & drop, including sortables, grid snapping, keyboard handling, viewport bounds
SSR with streaming, boundaries, edge handlers, response caching
Server — yes, a proper server runtime with middleware, cookies, SSE, streaming responses, app.listen()
Devtools, testing utilities, plugin system, media composables…

That's not a library. That's a framework. It took me a while to admit it out loud.

🛠️ Chapter 3 — The Three Rules, Still Holding

Here's the part I'm proudest of: bQuery grew into a framework without breaking the original promises.

You can still drop a single <script type="module"> into a plain HTML file and write 12 lines of code. You can also build a server-rendered app with streaming SSR, a typed router, signal-driven data fetching, and Web Components — using the same API surface. Same single import. Same tree-shaking. Same "no build step required, but works great if you want one".

// Minimal — just the DOM helpers
import { $, $$ } from '@bquery/bquery/core';

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

// Whole kitchen sink
import {
  $, signal, component, registerDefaultComponents, defineBqueryConfig,
} from '@bquery/bquery';

Explicit entry points. TypeScript-first. Truly tree-shakeable. Same vocabulary across the whole framework.

The CDN entry isn't a marketing afterthought — it's a core feature, in the same way the build-based install is. The moment you force people into a toolchain, you've already lost the "I just want to make a thing" crowd. And that crowd is sacred.

<script type="module">
  import { $, signal } from 'https://unpkg.com/@bquery/bquery@1/dist/full.es.mjs';

  const count = signal(0);
  $('#btn').on('click', () => count.value++);
  effect(() => $('#out').text(`Count: ${count.value}`));
</script>

That's a reactive counter. No bundler. No node_modules. No vibes-based config file. Just the platform.

🔒 Quick Aside: Security That Isn't Optional

If you remember the jQuery era, you also remember .html(userInput) shipping XSS into production. Hard pass.

bQuery sanitizes DOM writes by default and ships first-class helpers for Trusted Types and CSP. There's a bq-html-safe directive for templates that need to render markup explicitly. The defaults are the safe ones — you have to opt in to the dangerous thing, not opt out. That's the way it should have been all along.

🎉 Chapter 4 — Welcome to bquery.js.org

Okay. The actual reason for this post.

The docs used to live wherever I could shove them — README, GitHub Pages under a long URL, scattered Markdown files. That worked when the surface was "here are 8 functions and a chain API". It does not work when the surface is a full framework with 20+ modules, hundreds of composables, SSR, a server runtime, and a plugin system.

So I did the obvious thing. The docs got their own home:

👉 bquery.js.org

What you'll find there:

A proper getting started path — from "drop a <script> tag" to "scaffold a full SSR app"
Module-by-module reference with every signal, composable, directive, and helper
A searchable API reference generated straight from the source
Migration notes if you've been riding the 1.x train
A changelog that doesn't try to hide breaking changes in a footnote

The domain change is also a small but real symbolic thing. bquery.js.org is on the js.org registry — a community-run home for JavaScript projects. It feels right. It's where bQuery belongs now that it's stopped pretending to be small.

📦 Where We Are Today (v1.14.1)

For the people who like a quick state-of-the-union:

Area	What's in it
Core	`$`, `$$`, chainable DOM API, sane defaults
Reactive	Signals, computed, effects, stores
Components	Web Components-based, no VDOM runtime
Views	Directives, `bq-on` modifier system, memoization
Router	Guards, lazy routes, `useNavigation`, dynamic routes
Forms	Validation, dirty/touched, field-level signals
HTTP	Fetch composables, polling, pagination, REST, WebSocket, SSE
i18n	Locale negotiation, RTL, relative time, list & display name formatting
A11y	Live regions, focus-visible, forced-colors, reduced-motion, scroll-lock
Drag & Drop	Sortables, grids, keyboard, viewport bounds
Media	25+ reactive composables for preferences, page state, observers, pointer/scroll, clipboard
SSR	Streaming, boundaries, edge handlers, response caching
Server	HTTP runtime, middleware, cookies, SSE, streaming responses
Plugin system	Hook bus, DI container, namespaced directives, lifecycle
Devtools	Timeline ring buffer, signal/store diffs, traces, snapshots, browser bridge
Testing	Auto cleanup, `userEvent`, shadow-DOM-aware queries, module mocks, a11y helpers

All of that, and the 1.x API surface is still backwards compatible going back to 1.0. I'm a bit smug about that one ^^ .

🤔 But Is It Still… jQuery-y?

Yes. That's the whole point.

You can absolutely write a 2026 app using nothing but $('#thing').addClass(...).on('click', ...). The framework parts are opt-in. If you want to write tiny scripts, write tiny scripts. If you want to ship an SSR app with reactive forms and a typed server, that's the same install. Same imports. Same API conventions.

The whole thesis goes back to that original question — what would jQuery look like if it were designed today, for today's pain points? The platform is genuinely good now. We shouldn't have to choose between "ergonomic" and "uses what the browser already gives you". And we shouldn't have to choose between "powerful framework" and "drop a script tag and it works". bQuery is the bet that you can have all of it, in one import.

🙌 Contribute, Star, Yell at Me

bQuery is open source under the same spirit as everything else I publish. If you want to help:

⭐ Star the GitHub repo — it does more than you'd think
🐛 Open issues when things break
✨ PRs are welcome, especially for the parts you actually use
📝 Docs improvements over at bquery.js.org are very welcome — even a typo fix is a typo someone else won't trip over

If you'd previously written off "jQuery-style" as a museum piece, this might be a good moment to look again. The vibes are familiar. The internals are not.

🎯 TL;DR

bQuery.js started last autumn with one question: what would jQuery look like if you designed it today, for today's pain points?
Three rules locked in from day one: zero mandatory build step, single import (CDN or npm), real tree-shaking
It has since grown into a full-stack framework — signals, components, SSR, routing, a server runtime, forms, i18n, a11y, devtools, testing utilities — without breaking any of those rules
🎉 New docs home: bquery.js.org — go bookmark it
Latest release is v1.14.1, backwards compatible all the way back to 1.0

The jQuery for the modern web platform is no longer just jQuery for the modern web platform.

Cheers, and see you on bquery.js.org. 🥂

— Josun

[Boost]

Jonas Pfalzgraf — Tue, 14 Apr 2026 09:29:44 +0000

Jonas Pfalzgraf

Apr 6

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

#webdev #javascript #beginners #programming

7 min read

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

Jonas Pfalzgraf — Mon, 06 Apr 2026 12:06:46 +0000

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.

You get:

jQuery-like DOM ergonomics
signals-based reactivity
async composables
typed Web Components
modular architecture
platform-first design
progressively adoptable APIs

In short:

If vanilla JavaScript had a glow-up, learned modern reactivity, embraced Web Components, and started making better life decisions, it would probably look a lot like bQuery.

Peace out,

— Josun

Meet bQuery: a TypeScript-first DOM library with jQuery-style chaining, reactive APIs, zero runtime deps, and modern web features out of the box. #TypeScript #WebDev bquery.flausch-code.de

Jonas Pfalzgraf — Mon, 06 Apr 2026 11:38:47 +0000

Jonas Pfalzgraf

Mar 29

bQuery.js 🥂 The jQuery for the Modern Web Platform

#webdev #typescript #javascript #beginners

10 min read

[Boost]

Jonas Pfalzgraf — Wed, 01 Apr 2026 13:04:43 +0000

Jonas Pfalzgraf

Mar 29

bQuery.js 🥂 The jQuery for the Modern Web Platform

#webdev #typescript #javascript #beginners

10 min read

[Boost]

Jonas Pfalzgraf — Mon, 30 Mar 2026 23:21:50 +0000

Jonas Pfalzgraf

Mar 29

bQuery.js 🥂 The jQuery for the Modern Web Platform

#webdev #typescript #javascript #beginners

10 min read

bQuery.js 🥂 The jQuery for the Modern Web Platform

Jonas Pfalzgraf — Sun, 29 Mar 2026 17:04:45 +0000

A deep-dive into the modular, zero-build frontend framework that bridges the gap between vanilla JavaScript and full-blown frameworks

Introduction

Remember jQuery? That legendary library that made DOM manipulation actually enjoyable back in the day? Well, times have changed, browsers became smarter, the web platform grew up, and build toolchains ballooned into something that requires a PhD to configure properly.

But here's the thing: sometimes you just want to grab an element, wire up some reactive state, and get on with your life. No Vite config, no node_modules rabbit hole, no framework-specific mental model to internalize. Just... JavaScript. On the web. Like the good ol' days, but modern.

That's exactly where bQuery.js comes in.

bQuery (v1.7.0 as of this writing) describes itself as "the jQuery for the modern web platform" and it earns that title. It takes the directness and ergonomics of jQuery and layers on signals-based reactivity, async data composables, native Web Components, motion, forms, i18n, accessibility primitives, drag-and-drop, SSR, and a whole lot more. All of it modular. All of it progressively adoptable.

Let's break it down.

What Is bQuery?
Getting Started Zero Build, No Excuses
The Core API Good Old DOM Manipulation
Reactive Primitives Signals All the Way Down
Async Data & Fetching
Building Web Components with bQuery
@bquery/ui The Default Component Library
The Broader Ecosystem at a Glance
When Should You Reach for bQuery?
Conclusion

1. What Is bQuery?

bQuery is a modular JavaScript/TypeScript library published under @bquery/bquery on npm. Its philosophy can be summed up in three bullet points:

Zero build required works via CDN or ES modules straight in the browser; Vite is optional
Secure by default sanitized DOM operations and Trusted Types compatibility out of the box
Progressive import only what you need, add complexity only where you need it

The package is split into focused submodules so you never pay for what you don't use:

Module	What it does
`core`	Selectors, DOM manipulation, events, utilities
`reactive`	Signals, computed, effects, async composables
`component`	Typed Web Components with Shadow DOM control
`motion`	Transitions, FLIP, springs, parallax, typewriter
`security`	Sanitization, Trusted Types, CSP helpers
`platform`	Storage, cookies, cache, page meta, announcer
`router`	SPA routing with guards and declarative links
`store`	Signal-based global state with persistence
`forms`	Reactive form state and validators
`i18n`	Locale, translations, pluralization, Intl formatting
`a11y`	Focus traps, skip links, live regions, media audits
`dnd`	Draggable, drop zones, sortable lists
`media`	Viewport, network, battery, clipboard wrappers
`plugin`	Custom directive and component registration
`devtools`	Signal/store/component inspection at runtime
`testing`	Component mounts, mock signals, async assertions
`ssr`	Server-side rendering with hydration

That's a lot of ground covered and yet the entry point stays clean because you only import what you actually touch.

2. Getting Started Zero Build, No Excuses

The fastest way to try bQuery is dropping a <script type="module"> into an HTML file:

<!DOCTYPE html>
<html>
  <head>
    <title>bQuery Demo</title>
  </head>
  <body>
    <button id="counter">Count: 0</button>

    <script type="module">
      import { $, signal, effect } from 'https://unpkg.com/@bquery/bquery@1/dist/full.es.mjs';

      const count = signal(0);

      effect(() => {
        $('#counter').text(`Count: ${count.value}`);
      });

      $('#counter').on('click', () => {
        count.value++;
      });
    </script>
  </body>
</html>

No build step. No config. Reactive state, DOM manipulation, and event handling in ~10 lines. If that doesn't put a smile on your face, I don't know what will.

For project-based setups you install it the usual way:

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

And then import from the main entry point or directly from individual submodules:

// Everything from one place
import { $, signal, effect, component } from '@bquery/bquery';

// Or surgically pick submodules
import { $, $$ } from '@bquery/bquery/core';
import { signal, computed, effect, useFetch } from '@bquery/bquery/reactive';
import { component, html, registerDefaultComponents } from '@bquery/bquery/component';

3. The Core API Good Old DOM Manipulation

The core module is the jQuery-familiar part of bQuery. You get $ for single elements and $$ for collections. Both return wrapper objects with a chainable API.

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

// Single element throws if not found
$('#app')
  .addClass('loaded')
  .css({ color: 'rebeccapurple', fontSize: '1.2rem' })
  .text('Hello, bQuery!');

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

The single-element wrapper (BQueryElement) covers:

Class/attribute helpers: addClass, removeClass, toggleClass, attr, removeAttr, data, prop
Content: text, html (sanitized by default!), htmlUnsafe, append, prepend, before, after
Visibility: show, hide, toggle, css
Events: on, once, off, trigger, delegate
Traversal: find, closest, parent, children, siblings, next, prev
DOM manipulation: wrap, unwrap, replaceWith, detach, scrollTo
Form helpers: serialize, serializeString, val
Dimensions: rect, offset, outerWidth, outerHeight, position

Notice that html() is sanitized by default. That's the "secure by default" principle in practice you have to explicitly call htmlUnsafe() to bypass it. A small thing that prevents a whole class of XSS bugs.

The core module also ships a solid utility belt:

import { debounce, throttle, merge, uid, utils } from '@bquery/bquery/core';

const save = debounce(() => console.log('saved!'), 300);
save.cancel(); // cancelable

const id = uid('component'); // "component-xyz123"

const merged = merge({ a: 1 }, { b: 2 }); // { a: 1, b: 2 }

Utilities include clone, pick, omit, slugify, truncate, chunk, flatten, compact, unique, randomInt, clamp, and a full suite of type guards (isString, isElement, isPromise, etc.). It's the kind of utility layer that means you actually don't need lodash.

4. Reactive Primitives Signals All the Way Down

This is where bQuery steps firmly into modern territory. The reactive module gives you fine-grained reactivity through signals the same primitive that's now baked into Angular, Solid, and Preact signals.

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

const firstName = signal('John');
const lastName = signal('Doe');

// Computed values are lazy and cached
const fullName = computed(() => `${firstName.value} ${lastName.value}`);

// Effects run immediately, re-run on dependency change
effect(() => {
  document.title = fullName.value;
});

// Batch multiple updates into a single notification pass
batch(() => {
  firstName.value = 'Jane';
  lastName.value = 'Smith';
});

// Watch with old/new value comparison
const stop = watch(firstName, (newVal, oldVal) => {
  console.log(`Changed: ${oldVal} â†’ ${newVal}`);
});

stop(); // unsubscribe

A few things worth highlighting:

signal.peek() reads the value without creating a reactive dependency. Useful when you need to read inside an effect without it re-subscribing.

signal.update(fn) updates based on the current value handy for immutable patterns.

signal.dispose() removes all subscribers and prevents memory leaks. Important for long-lived apps.

readonly(signal) creates a read-only view. Great for exposing reactive state from a store without allowing external mutation.

untrack(() => ...) reads signals inside an effect without tracking them as dependencies.

persistedSignal syncs a signal to localStorage automatically, with graceful fallbacks for SSR and Safari private mode:

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

const theme = persistedSignal('theme', 'light');
theme.value = 'dark'; // Saved to localStorage automatically

linkedSignal creates a writable computed you provide both a getter and a setter, so writes can fan out to multiple underlying signals:

import { linkedSignal, signal } from '@bquery/bquery/reactive';

const first = signal('Ada');
const last = signal('Lovelace');

const fullName = linkedSignal(
  () => `${first.value} ${last.value}`,
  (next) => {
    const [nextFirst, nextLast] = next.split(' ');
    first.value = nextFirst ?? '';
    last.value = nextLast ?? '';
  }
);

fullName.value = 'Grace Hopper'; // Fans out to first and last

Errors inside effects are caught and logged rather than crashing the reactive system subsequent updates keep working. That's a nice resilience property you don't always get for free.

5. Async Data & Fetching

Managing loading states, errors, and async lifecycles is boilerplate-heavy in vanilla JS. bQuery abstracts all of that into two composables.

useAsyncData wraps any async function in a signal-based lifecycle:

import { signal, useAsyncData } from '@bquery/bquery/reactive';

const userId = signal(1);
const user = useAsyncData(
  () => fetch(`/api/users/${userId.value}`).then(r => r.json()),
  {
    watch: [userId],        // re-run when userId changes
    defaultValue: null,
    onError: (err) => console.error('Failed:', err),
  }
);

// Reactive state you can bind directly to the DOM
console.log(user.status.value);  // 'idle' | 'pending' | 'success' | 'error'
console.log(user.pending.value); // boolean
console.log(user.data.value);    // the resolved data
console.log(user.error.value);   // Error | null

await user.refresh(); // manually trigger
user.clear();         // reset everything
user.dispose();       // stop watchers

useFetch builds on top of that and adds HTTP niceties base URLs, query params, custom headers, automatic JSON serialization, and pluggable response parsers (json, text, blob, arrayBuffer, formData, response):

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

const users = useFetch('/users', {
  baseUrl: 'https://api.example.com',
  query: { page: 1, include: 'profile' },
  headers: { authorization: 'Bearer my-token' },
});

For shared defaults across multiple requests, createUseFetch acts as a factory:

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

const useApi = createUseFetch({
  baseUrl: 'https://api.example.com',
  headers: { 'x-client': 'my-app' },
});

const profile = useApi('/profile');
const posts = useApi('/posts', { query: { page: 2 } });

This pattern is really clean for larger apps where you want a pre-configured fetch instance rather than repeating base URLs everywhere.

6. Building Web Components with bQuery

The component module is where bQuery really shines for component-driven architectures. It wraps the native Custom Elements API with typed props, optional internal state, scoped reactivity, and a sanitized render function.

import { component, html, bool } from '@bquery/bquery/component';

component('user-card', {
  props: {
    username: { type: String, required: true },
    avatar: { type: String, default: '/default-avatar.png' },
    active: { type: Boolean, default: false },
  },
  state: { clicks: 0 },
  styles: `
    .card { display: grid; gap: 0.5rem; padding: 1rem; border-radius: 8px; }
    .active { border: 2px solid #4f46e5; }
  `,
  connected() {
    console.log('user-card mounted');
  },
  disconnected() {
    console.log('user-card removed');
  },
  render({ props, state, emit }) {
    return html`
      <button
        class="card ${props.active ? 'active' : ''}"
        ${bool('disabled', !props.active)}
        @click=${() => {
          this.setState('clicks', state.clicks + 1);
          emit('card-clicked', { username: props.username });
        }}
      >
        <img src="${props.avatar}" alt="${props.username}" />
        <strong>${props.username}</strong>
        <span>Clicked ${state.clicks} times</span>
      </button>
    `;
  },
});

<!-- Usage -->
<user-card username="Jonas" active></user-card>

A few things to appreciate here:

Props are typed and coerced automatically. Strings stay strings, numbers get Number() called on them, booleans understand 'true', '', '1', 'false', '0'. Objects get JSON.parsed. You can also add a validator function to enforce invariants at runtime.

The render output is sanitized before being written to the Shadow DOM. You get security by default with an explicit opt-in mechanism (safeHtml, trusted) when you need to pass sanitized fragments through.

Shadow DOM mode is configurable. Open shadow root by default, but you can go closed or render directly into light DOM:

component('inline-banner', {
  shadow: false, // renders in light DOM
  render: () => html`<p class="banner">No shadow needed here</p>`,
});

Lifecycle hooks cover everything you need: beforeMount, connected, beforeUpdate (return false to cancel a re-render), updated, disconnected, onError, onAdopted, and onAttributeChanged.

Scoped reactive helpers (useSignal, useComputed, useEffect) create component-local reactive resources that are cleaned up automatically on disconnect no manual cleanup needed:

component('live-timer', {
  state: { seconds: 0 },
  connected() {
    const tick = useSignal(0);
    const interval = setInterval(() => tick.value++, 1000);

    useEffect(() => {
      this.setState('seconds', tick.value);
    });

    this.disconnected = () => clearInterval(interval);
  },
  render({ state }) {
    return html`<p>Elapsed: ${state.seconds}s</p>`;
  },
});

External signals can drive re-renders via the signals option, keeping component updates predictable:

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

const theme = signal<'light' | 'dark'>('light');
const themeClass = computed(() => `theme-${theme.value}`);

component('theme-badge', {
  props: {},
  signals: { themeClass },
  render({ signals }) {
    return html`<span class="${signals.themeClass.value}">Current theme</span>`;
  },
});

7. `@bquery/ui` The Default Component Library

bQuery ships a companion component library that's registered through registerDefaultComponents(). It's a small, zero-dependency set of native UI primitives no external CSS framework required.

import { defineBqueryConfig } from '@bquery/bquery/platform';
import { registerDefaultComponents } from '@bquery/bquery/component';

// Configure a custom prefix (default is 'ui')
defineBqueryConfig({
  components: { prefix: 'ui' },
  fetch: { baseUrl: 'https://api.example.com' },
  transitions: { skipOnReducedMotion: true },
});

const tags = registerDefaultComponents();

console.log(tags);
// {
//   button: 'ui-button',
//   card: 'ui-card',
//   input: 'ui-input',
//   textarea: 'ui-textarea',
//   checkbox: 'ui-checkbox'
// }

The available primitives:

ui-button pill-shaped button with variant, size, type, and disabled props
ui-card container with optional title, footer, and elevated props
ui-input labeled text input that emits input events with { value }
ui-textarea labeled textarea, same event contract as ui-input
ui-checkbox labeled checkbox that emits change events with { checked }

These components use regular HTML slots and bubble custom events, so they play nicely with forms, routers, and shadow DOM boundaries. You can compose them directly in your markup:

<ui-card title="Create Account">
  <ui-input label="Name"></ui-input>
  <ui-input label="Email"></ui-input>
  <ui-checkbox label="Accept terms"></ui-checkbox>
  <ui-button variant="primary" type="submit">Sign Up</ui-button>
</ui-card>

And wire them up reactively:

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

const name = signal('');
const email = signal('');

document.querySelector('ui-input[label="Name"]')
  ?.addEventListener('input', (e) => {
    name.value = (e as CustomEvent<{ value: string }>).detail.value;
  });

The prefix system via defineBqueryConfig is a nice touch for teams with strict naming conventions, or for avoiding collisions when integrating bQuery components into an existing design system.

8. The Broader Ecosystem at a Glance

bQuery v1.7.0 covers a surprising amount of ground beyond what we've walked through. Here's a quick tour of the other modules:

Router full SPA routing with constrained params, guards, redirects, and declarative <bq-link> elements.

Store signal-based global state with persistence, migrations, and action lifecycle hooks. Think a lightweight Pinia, but framework-agnostic.

View declarative bq-* attribute directives (bq-text, bq-show, bq-class, etc.) for template-style binding without a full component.

Motion transitions, FLIP animations, springs, parallax, typewriter effects, and scroll-linked animations. Respects prefers-reduced-motion by default when configured.

i18n reactive locale state, nested translation keys, pluralization rules, and Intl-based date/number/relative-time formatting.

a11y focus traps, skip navigation links, live region announcers, and audit helpers that flag missing ARIA attributes at runtime.

DnD make any element draggable, define drop zones, build sortable lists without reaching for a third-party library.

Testing renderComponent, fireEvent, waitFor utilities that mirror what you'd expect from Testing Library.

SSR renderToString for server-side HTML generation and hydrateMount for seamlessly picking up where the server left off.

Storybook helpers storyHtml() and when() for writing safe Storybook stories with boolean attribute shorthand (?disabled=${true}).

9. When Should You Reach for bQuery?

bQuery isn't trying to replace React, Vue, or Svelte for large-scale applications with complex component trees and heavy state management. It's solving a different problem.

Reach for bQuery when:

You want reactivity and component primitives without a build pipeline prototypes, experiments, browser extensions, internal tools
You're writing vanilla JS/TS and want jQuery's ergonomics plus modern signal-based reactivity
You need native Web Components with typed props and a sane lifecycle, but don't want to set up Lit or Stencil
You're building progressively enhanced pages where a CDN import is all you need
You want to ship accessible, secure-by-default UI without bolting on extra libraries for sanitization, focus management, and ARIA
You're working on a small-to-medium project where a full SPA framework would be overkill

It's also genuinely useful as a companion in larger apps you could use bQuery's reactive core alongside an existing codebase for specific interactive islands without committing to a full rewrite.

10. Conclusion

bQuery v1.7.0 is one of those rare libraries that manages to feel both nostalgic and completely modern at the same time. It channels the simplicity of jQuery while embracing everything the web platform has become signals, Web Components, Trusted Types, fetch, Shadow DOM, the whole lot.

The zero-build path alone makes it worth knowing about. Being able to drop a single CDN import into an HTML file and immediately have signals, reactive DOM manipulation, typed components, and async data composables is genuinely impressive.

If you've been eyeing signals-based reactivity but felt the existing frameworks were too opinionated or too heavyweight for your use case, bQuery is absolutely worth exploring.

Give it a spin:

📒¦ npm: @bquery/bquery
📚 – Docs: bquery.js.org

Thanks for reading! If you have questions or feedback, drop them in the comments. And if you're using bQuery in a project, I'd love to hear about it.

QRify v1.3: The Privacy-First QR Code Generator Got Even Better! 🔐

Jonas Pfalzgraf — Sat, 06 Dec 2025 15:29:55 +0000

Hi everyone! 👋

Remember my rant about shady QR code generator pages? You know, the ones that want your subscription, your login, your firstborn child, and probably your soul just to generate a simple QR code?

Well, I didn't just complain about it — I built something. And now it's even better.

🎉 Introducing: QRify v1.3

QRify started as a quick weekend project born out of frustration. But you know how it goes — you start with "just a simple QR code generator" and suddenly you're knee-deep in i18n configuration files at 2 AM, translating "Download" into 27 languages.

No regrets though. It was worth it.

🔗 Check It Out

Live demo: qr.flausch-code.de/
Code repo: GitHub - JosunLP/qr-code-generator

✨ Key Features

Let me break down what QRify can do for you:

🎨 Multiple QR Code Types

Not just boring text QR codes. QRify supports:

Text — The classic. Type anything, get a QR code.
URL — Scannable links, no fuss.
vCard — Full business cards! Name, phone, email, address, company, website — the whole package.
WiFi — Share your network credentials without awkwardly spelling out your password.
Email — Pre-composed emails with recipient, subject, and body.

📥 Export Formats Galore

Choose your poison:

Vector	Raster
SVG	PNG
	JPEG
	GIF
	TIFF
	WebP

SVG is my personal favorite — it scales infinitely without getting pixelated. Perfect for print.

🔒 Privacy-First (For Real)

This is the big one. QRify runs 100% client-side. Your data never leaves your browser. Ever.

❌ No tracking
❌ No analytics
❌ No login required
❌ No subscription
❌ No server-side processing
✅ Just pure, unadulterated QR code generation

I didn't build this to harvest your data. I built it because I needed a tool that respects privacy.

🌐 27 Languages

Yeah, you read that right. Twenty-seven.

QRify auto-detects your browser language and switches automatically. Or you can pick manually from the dropdown. We've got everything from English to Arabic, Japanese to Ukrainian, and a bunch more in between.

Here's the full list:

English, German, French, Spanish, Italian, Portuguese, Dutch, Polish, Russian, Swedish, Chinese, Japanese, Korean, Turkish, Arabic, Hindi, Czech, Greek, Hungarian, Romanian, Ukrainian, Vietnamese, Thai, Indonesian, Danish, Norwegian, Finnish

Did I translate all of these myself? Let's just say I had some... assistance. 😅 But hey, if you spot a weird translation, PRs are welcome!

📱 Progressive Web App (PWA)

QRify is installable. On your phone. On your desktop. Works offline after the first load. Gets automatic updates.

It's basically an app without the App Store drama.

🛠️ The Tech Stack

For my fellow devs who care about the nerdy details:

Technology	Purpose
Vue 3	Frontend framework (Composition API, baby!)
TypeScript	Because `any` is not a type
Vite	Build tool & dev server (fast as heck)
Tailwind CSS 4	Utility-first styling
vue-i18n	Internationalization
qrcode	The actual QR code magic
vite-plugin-pwa	PWA support
Bun	Runtime & package manager

I went with Vue 3 because, well, I'm a Vue person. You probably figured that out by now if you've read my other articles. The Composition API makes the component logic so much cleaner compared to the old Options API days.

Tailwind CSS 4 is the new hotness, and combined with Vite's speed, the development experience is chef's kiss.

🚀 Getting Started

Want to run it locally or contribute? Here's how:

# Clone the repo
git clone https://github.com/JosunLP/qr-code-generator.git
cd qr-code-generator

# Install dependencies (I recommend Bun, but npm works too)
bun install

# Start the dev server
bun run dev

That's it. You're up and running at http://localhost:5173.

🏗️ What's Next?

I've got some ideas brewing:

More QR code types (SMS, geo-location, calendar events?)
Custom styling options (colors, logos in the center?)
Batch generation
History/favorites (stored locally, of course)

But honestly, I'm open to suggestions. What would make QRify more useful for you?

🙌 Contribution

This is open source, and I genuinely appreciate contributions. Whether it's:

🐛 Bug fixes
✨ New features
🌍 Translation improvements
📝 Documentation

Just open a PR or an issue, and let's make it happen.

The repo: github.com/JosunLP/qr-code-generator

If you find it useful, maybe drop a ⭐ on GitHub? It helps more than you'd think!

🎯 TL;DR

QRify is a free, open-source QR code generator
Supports text, URL, vCard, WiFi, and email QR codes
Exports to SVG, PNG, JPEG, GIF, TIFF, and WebP
27 languages with auto-detection
100% client-side — no tracking, no data collection
PWA — install it, use it offline
Built with Vue 3, TypeScript, Tailwind CSS 4, and Vite

Stop using shady QR code generators that want your data. Use QRify instead.

Peace out,
— Josun

Tetris for Logistics: solving the 3D Bin Packing Problem with Rust 🦀

Jonas Pfalzgraf — Fri, 05 Dec 2025 09:47:08 +0000

Hi everyone! 👋

You know what’s frustrating? Opening a huge delivery box just to find a tiny item rattling around inside, surrounded by a mountain of bubble wrap. It’s inefficient, it’s bad for the environment, and honestly, it just feels wrong.

Or maybe you’ve moved house recently and played "Real Life Tetris" trying to fit everything into the moving truck?

I decided to tackle this problem the way I love most: with code. 💻

📦 Introducing: sort-it-now

I built sort-it-now, a 3D packing optimizer written in Rust. The goal is simple but powerful: calculate the most efficient way to pack a set of items into a box (or container) and visualize the result.

It’s basically an algorithm that plays Tetris for you, but in 3D and with much higher stakes (okay, maybe just better efficiency).

🛠️ The Tech Stack

I chose Rust 🦀 for this project because:

Performance: When you are calculating 3D space and iterating through thousands of possibilities, speed matters.
Safety: Rust’s memory safety guarantees help prevent silly bugs when dealing with complex data structures.
It’s awesome: Let's be honest, writing Rust just feels good.

✨ Key Features

Intelligent Optimization: It calculates the best fit for your items.
3D Visualization: It’s not just a console output saying "It fits." You get an interactive visualization to see how it fits.
Open Source: Because sharing is caring!

🚀 Why I built this

I love projects that bridge the gap between abstract algorithms and real-world visual feedback. sort-it-now was a playground for me to dive deeper into Rust while solving a classic optimization problem (the Bin Packing Problem). Plus, visualizing the output makes the math feel "real."

🔗 Check it out

The project is hosted on GitHub. I’d love for you to check it out, give it a spin, or maybe even drop a star if you find it cool! ⭐

👉 GitHub Repo: JosunLP/sort-it-now

🙌 Contribution

I'm always open to feedback. If you have ideas on how to make the packing algorithm even smarter, or if you want to improve the visualization, feel free to open an issue or a pull request.

Let's stop shipping air and start sorting it now!

Peace out,
— Josun

I Supercharged My UserScript Template: Now with ESLint, Prettier, and Full Mobile Support! 🚀

Jonas Pfalzgraf — Fri, 11 Jul 2025 23:31:30 +0000

Hey, dev community!

I'm super excited to share the latest, and biggest, updates to my UserScript Project Template on GitHub. I've spent the last few days giving it a major overhaul to modernize the entire development workflow, boost code quality, and—the part I'm most thrilled about—make it fully mobile-ready!

Let's dive into what's new.

✨ Part 1: A Modern Development Experience

My first goal was to bring the entire development setup up to modern standards. A clean, automated environment is key to writing good code, and this template now has everything you need.

Code Quality with ESLint & Prettier
Say goodbye to inconsistent code styles! The project now comes pre-configured with ESLint and Prettier to enforce a clean and error-free codebase. I've added .eslintrc.js and .prettierrc.json files with solid defaults, full TypeScript support, and custom rules to get you started.

Beefed-up Scripts & Dependencies
The package.json has been revamped with a bunch of new scripts to make life easier:

npm run lint: Check your code with ESLint.
npm run format: Format the entire codebase with Prettier.
npm run type-check: Run the TypeScript compiler to check for type errors.
npm run clean: Clean up build artifacts.

All the necessary dev dependencies for ESLint, Prettier, and TypeScript are, of course, included.

Modular Architecture & New Utilities
The project structure got a significant refactor to be more modular and maintainable:

The main application class in src/index.ts now features a modular architecture, a built-in event system, and examples for using persistent storage and custom styles.
New DOM utilities in src/utils/dom.ts make it a breeze to manipulate elements, inject styles, and check for visibility.
A new ExampleModule in src/modules/example.ts showcases the event-driven architecture and how to use the new utilities.

📱 Part 2: The Main Event – Full Mobile Support!

This is the biggest game-changer. UserScripts are no longer just a desktop thing, and this template now fully embraces the mobile web.

The New MobileModule for Touch Gestures
At the core of this update is the new MobileModule (src/modules/mobile.ts). It implements a robust gesture detection system for:

Tap
Swipe
Pinch (zoom in/out)

It also handles orientation changes and provides mobile-friendly UI elements right out of the box.

Automatic Detection & Adaptation
The main app in src/index.ts now automatically detects if it's running on a mobile device. If it is, it initializes the MobileModule, loads mobile-specific styles, and listens for mobile events like gestures. This makes your script responsive and touch-optimized without any extra work.

Updated Docs & Metadata
To reflect all these new capabilities, I've expanded the README.md and updated the project's metadata (header.config.json, package.json). The documentation now includes details on the mobile utilities, supported browsers, and features like responsive design and safe area handling.

Wrapping Up

These changes make the template a powerful starting point for any UserScript project. You get a modern development environment with top-tier tooling, a clean and scalable architecture, and the versatility to build scripts that work beautifully on both desktop and mobile.

I'm really proud of how this turned out and I hope you find it useful!

Feel free to check out the project on GitHub, give it a try, and let me know what you think. I appreciate every star and contribution!

Check out the repo here: https://github.com/JosunLP/UserScriptProjectTemplate

Happy coding! 🎉

DEV Community: Jonas Pfalzgraf

[Boost]

bQuery.js Grows Up: From Tiny jQuery Tribute to a Full-Stack Framework — and a Brand New Home at bquery.js.org 🎉

[Boost]

bQuery.js Grows Up: From Tiny jQuery Tribute to a Full-Stack Framework — and a Brand New Home at bquery.js.org 🎉

bQuery.js Grows Up: From Tiny jQuery Tribute to a Full-Stack Framework — and a Brand New Home at bquery.js.org 🎉

📖 Chapter 1 — Three Non-Negotiables

🌱 Chapter 2 — "Hm, this could use signals"

🛠️ Chapter 3 — The Three Rules, Still Holding

🔒 Quick Aside: Security That Isn't Optional

🎉 Chapter 4 — Welcome to bquery.js.org

📦 Where We Are Today (v1.14.1)

🤔 But Is It Still… jQuery-y?

🙌 Contribute, Star, Yell at Me

🎯 TL;DR

[Boost]

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

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

🎉 What is bQuery again?

🤔 Why this matters in 2026

🚀 Getting started

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

⚡ Signals, because modern state should not be miserable

🌐 Async data without writing the same boilerplate forever

🧩 Web Components that don’t feel like punishment

🛠️ Why I like the philosophy behind bQuery

1. Platform-first

2. Progressive

3. Modular

4. Modern

5. Pragmatic

📦 Ecosystem breadth: more than just selectors

🆕 Why write about 1.9.0 specifically?

🧪 Who should use bQuery?

😅 Who is it not for?

💡 My honest takeaway

🔗 Check it out

🎯 TL;DR

Meet bQuery: a TypeScript-first DOM library with jQuery-style chaining, reactive APIs, zero runtime deps, and modern web features out of the box. #TypeScript #WebDev bquery.flausch-code.de

bQuery.js 🥂 The jQuery for the Modern Web Platform

[Boost]

bQuery.js 🥂 The jQuery for the Modern Web Platform

[Boost]

bQuery.js 🥂 The jQuery for the Modern Web Platform

bQuery.js 🥂 The jQuery for the Modern Web Platform

Introduction

Table of Contents

1. What Is bQuery?

2. Getting Started Zero Build, No Excuses

3. The Core API Good Old DOM Manipulation

4. Reactive Primitives Signals All the Way Down

5. Async Data & Fetching

6. Building Web Components with bQuery

7. @bquery/ui The Default Component Library

8. The Broader Ecosystem at a Glance

9. When Should You Reach for bQuery?

10. Conclusion

QRify v1.3: The Privacy-First QR Code Generator Got Even Better! 🔐

🎉 Introducing: QRify v1.3

🔗 Check It Out

✨ Key Features

🎨 Multiple QR Code Types

📥 Export Formats Galore

🔒 Privacy-First (For Real)

🌐 27 Languages

📱 Progressive Web App (PWA)

🛠️ The Tech Stack

🚀 Getting Started

🏗️ What's Next?

🙌 Contribution

🎯 TL;DR

Tetris for Logistics: solving the 3D Bin Packing Problem with Rust 🦀

📦 Introducing: sort-it-now

🛠️ The Tech Stack

✨ Key Features

🚀 Why I built this

🔗 Check it out

🙌 Contribution

I Supercharged My UserScript Template: Now with ESLint, Prettier, and Full Mobile Support! 🚀

✨ Part 1: A Modern Development Experience

7. `@bquery/ui` The Default Component Library