DEV Community: Jonas Pfalzgraf

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

Comments

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

Comments

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

Comments

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.flausch-code.de

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! 🎉

What I used to use and what I use now. Developer Development in a nutshell!

Jonas Pfalzgraf — Mon, 16 Jun 2025 22:25:04 +0000

The world of frontend development is a constantly spinning carousel. As soon as you've mastered one framework, the next "Next Big Thing" is already on the horizon, promising to make everything better, faster, and easier. Looking back on my own journey, I see not just a list of technologies, but a personal development—a story of pragmatism, curiosity, initial aversion, and unexpected affection.

This article is my personal retrospective. Not an ultimate "This is the best framework" sermon, but an honest reflection on the tools that have shaped my path as a developer.

In the beginning there was... SharePoint? And an Angular fork

My journey didn't start in the shiny greenfield project heaven. It began in the pragmatic world of SharePoint on-prem. Anyone who has ever had to develop here knows: it's a discipline of its own. Our tool of choice was not ordinary Angular, but a fork called SPAngular.

It was specifically optimized to integrate into the complex and sometimes stubborn architecture of SharePoint. Hand on heart: the developer experience was... functional. It was often cumbersome and far from the elegance of modern frameworks. But it got the job done. It allowed us to bring reactive UIs into an environment that wasn't really made for it.

A typical "Component" back then, simplified, might have looked like this:

// Imagine a lot of SharePoint-specific boilerplate here
var spAngularModule = angular.module("mySharePointApp", []);

spAngularModule.controller("MyWebPartController", [
  "$scope",
  "spListService",
  function ($scope, spListService) {
    $scope.items = [];
    $scope.title = "My Documents";

    function fetchDocs() {
      // Complex call to a SharePoint service
      spListService.getListItems("Document Library").then(function (data) {
        $scope.items = data;
      });
    }

    fetchDocs();
  },
]);

Looking back, it was the perfect, albeit tough, start. It taught me to work within strict boundaries and to find solutions for real business problems, even when the tools weren't ideal.

A breath of fresh air: Vue and the magic of Quasar

After the SharePoint era, switching to Vue.js felt like a liberation. Suddenly, everything was so... logical. Single-File Components (.vue files), the separation of template, script, and style in one file, immediately felt right.

Together with the Quasar Framework, it was a real power duo. Need a complex, responsive data table? q-table. A standardized dialog? q-dialog. Productivity skyrocketed. I could focus on the logic while Quasar took care of the heavy lifting in UI building.

A simple example that shows the clarity of Vue:

<template>
  <div class="q-pa-md">
    <q-btn :label="`Clicks: ${count}`" @click="increment" color="primary" />
  </div>
</template>

<script setup>
  import { ref } from "vue";

  const count = ref(0);

  function increment() {
    count.value++;
  }
</script>

<style scoped>
  .q-pa-md {
    border: 1px solid #ccc;
    border-radius: 4px;
  }
</style>

Vue showed me how much fun development can be when the framework doesn't get in your way but supports you. It was intuitive and powerful at the same time.

The great love: Svelte and syntactic sugar

And then came Svelte. Svelte wasn't just another framework, it was a revelation. The idea of not using a virtual DOM and instead generating highly optimized, pure JavaScript code at build time immediately convinced me.

But what really blew me away was the syntax. It no longer felt like learning a framework. It felt like just writing HTML, CSS, and JavaScript.

Reactivity? Just declare a variable with let.

<script>
  let count = 0;

  function handleClick() {
    count += 1;
  }

  // Derived value? No problem!
  $: doubled = count * 2;
</script>

<main>
  <button on:click={handleClick}>
    Clicked: {count} {count === 1 ? 'time' : 'times'}
  </button>

  <p>{count} * 2 = {doubled}</p>
</main>

<style>
  main {
    text-align: center;
    padding: 1em;
  }
</style>

This code is so incredibly elegant and readable. No this.setState(), no .value, no boilerplate. It's just there and it works. For me, this is the pinnacle of syntactic sugar.

But there's a catch. As much as I love Svelte, reality catches up with you. The ecosystem is smaller. You don't find a ready-made library for every problem. SvelteKit, the associated meta-framework, is fantastic, but it requires compromises. Sometimes you have to build things yourself for which there are already established solutions in other ecosystems.

From foe to friend: My deep dive into React

I admit it openly: I didn't like React at first. JSX felt to me like an unclean mix of HTML and JS. Hooks like useState seemed cumbersome compared to the magic of Svelte. Why should I write [count, setCount] when let count is enough?

But then came a project that required React with TypeScript. So I had to dive deep—and my opinion changed fundamentally.

I began to understand the genius behind function components and hooks. The unidirectional data flow architecture makes applications extremely predictable and well testable once they reach a certain complexity.

import React, { useState, useEffect } from "react";

function Counter() {
  const [count, setCount] = useState(0);

  // A side effect that runs every time 'count' changes
  useEffect(() => {
    document.title = `You clicked ${count} times`;
  }, [count]);

  return (
    <div>
      <p>You clicked {count} times</p>
      <button onClick={() => setCount(count + 1)}>Click me</button>
    </div>
  );
}

But the real game-changer for me was something else: AI support. Tools like GitHub Copilot seem to think in React. I describe a component in a comment, and Copilot spits out almost finished, idiomatic React code. Need a complex hook? The suggestions are usually spot on. This productivity boost is simply undeniable in professional everyday life. The huge ecosystem does the rest.

Conclusion: Pragmatism wins, but the heart beats for Svelte

So where am I today? I currently develop my private projects mainly with React. The reason is pure pragmatism. The combination of the gigantic ecosystem, the maturity of the framework, and the phenomenal tooling and AI support simply makes me incredibly productive.

Every framework on my journey has taught me valuable lessons:

SPAngular taught me to solve problems under difficult conditions.
Vue showed me the joy of a good developer experience.
React taught me the power of structure, predictability, and a superior ecosystem.
Svelte showed me how elegant and beautiful code can be.

My wish for the future? Broader acceptance for Svelte. I dream of a world where the Svelte ecosystem is so rich that choosing Svelte is not just a matter of the heart, but also of pragmatic reason.

Until then, for me: The best tool is the one with which you can best get the job done. And sometimes that's not the one you fell in love with at first sight.

Peace out,

— Josun

Shady QR Code Generator Pages? Ugh!

Jonas Pfalzgraf — Thu, 09 Jan 2025 09:14:52 +0000

You know what I really, REALLY hate? Shady QR Code generator pages. There are so many of them out there on the internet—one more dubious than the next. Practically all of them want:

A subscription from you
Your login details
Your money

And if that’s not enough, they love generating tracking links instead of just giving you a simple QR code. They pretend to be oh-so-helpful, but really, it’s all about collecting your data and milking you for profit.

They’re Just Math (Not Magic)

I got so fed up with it. QR codes aren’t a magical enigma—there’s no sorcery or witchcraft involved. Yes, it’s some level of math, but definitely not the kind that requires the sacrifice of your data. Even better: in the year 2025, we don’t need to send people’s data to a server just to generate a QR code. I mean, we can generate these things live, on the fly, while you’re typing your content!

Introducing: Qrify

After two evenings of coding, I created my own thing: Qrify. Currently, it has the basic features you need, and guess what? It runs 100% in your browser, no tracking or sneaky stuff. I wanted something straightforward that doesn’t shake you down for a subscription or a login.

Oh, and if you notice the language is a bit…odd in places—yes, it’s a crude mashup of German and English right now. Today is 09.01.2025, so the internationalization (i18n) part is still pending. But hey, deal with it for now. More updates will come in time.

Update: It's localized now ^^

Check It Out

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

If you also hate shady QR code generators, or just want a quick, no-BS tool, I hope Qrify helps you out.

That’s all. If you’re as tired as I am of shady QR code sites, well, now you’ve got a free, open-source alternative. Enjoy the new freedom from dubious data-hungry websites!

Peace out,

— Josun

Societal Critique: The Struggle of Neurodivergent Employees in Neurotypical Work Environments

Jonas Pfalzgraf — Fri, 06 Sep 2024 12:17:43 +0000

In the modern workplace, there is a silent and often invisible crisis affecting many companies and their employees: the disregard for the needs of neurodivergent employees. Particularly impacted are people with Attention Deficit Hyperactivity Disorder (ADHD) and those who have both ADHD and Autism Spectrum Disorder (AuDHD). These employees are typically forced to conform to the standards of their neurotypical colleagues, leading to significant personal and professional challenges.

The Invisible Burden of Neurodivergent Employees

Neurodivergent individuals bring unique skills and perspectives to the workplace. However, instead of fostering these qualities, they are typically expected to fit into a standardized work environment. This expectation forces neurodivergent employees to constantly push beyond their limits to meet demands. The result is not only a significant strain on their mental health but also a waste of their potential.

ADHD and AuDHD: Strengths and Challenges

People with ADHD and AuDHD frequently possess extraordinary abilities such as creative problem-solving, hyperfocus in areas of interest, and high resilience under pressure. Simultaneously, they struggle with difficulties like sensory overload, organizational challenges, and increased sensitivity to social rejection. Employers' ignorance of these challenges leads to an environment that systematically disadvantages neurodivergent employees.

The Economic Consequences of Ignorance

A company that does not support neurodivergent employees loses not only human potential but also economic advantages. Studies have shown that diversity in the workplace leads to higher innovation and productivity. However, by marginalizing neurodivergent employees, companies miss the opportunity to leverage these creative and often revolutionary thinkers.

Concrete Improvement Suggestions

Flexibility in Work Hours and Locations: Many neurodivergent people work more effectively in flexible environments. Options for remote work and flexible hours can help meet individual needs and increase productivity.
Adjustment of Communication Methods: Clear, written instructions and regular check-ins can reduce misunderstandings and support neurodivergent employees. Visual aids and structured task lists are also helpful.
Awareness and Training: Companies should offer training to raise awareness of neurodivergent needs. Managers and colleagues must understand that neurodivergent people are different, but not less capable.
Mentoring Programs: An experienced mentor who understands the challenges and strengths of neurodivergent employees can provide valuable support and guidance.
Quiet Workspaces and Retreat Areas: A quiet workplace without distracting stimuli can significantly enhance the productivity and well-being of neurodivergent employees.

The Path to a More Inclusive Society

Handling neurodivergent employees is not only a matter of social justice, but also an economic necessity. Companies that recognize and nurture the uniqueness and potential of these employees benefit from their creativity and innovation. Simultaneously, the mental health and well-being of neurodivergent people are strengthened, leading to a more positive and productive work environment.

Society as a whole must learn not to view neurodivergent people as “problematic” or “deficient,” but to appreciate their unique skills and perspectives. This requires rethinking and reevaluating what we consider to be “normal” working methods. Only then can we create a truly inclusive and fair working world.

At a time when diversity and inclusion are gaining importance, it is time to include neurodivergent people in this movement. It is not only morally right but also economically wise. Because a workplace that has room for everyone is a workplace that prospers.

Conclusion

The challenges faced by neurodivergent employees are real and profound, but they are not insurmountable. With conscious efforts and an open, inclusive attitude, companies can create an environment where every employee – regardless of their neurological differences – can thrive. Only then can we shape a future that truly includes everyone and unlocks the full potential of each individual.

Migrating TypeScript Projects from Webpack to Vite

Jonas Pfalzgraf — Fri, 07 Jun 2024 14:00:51 +0000

So, you're a seasoned developer, juggling TypeScript like a boss, and you've been using Webpack for ages. Webpack is your trusty steed, your old reliable, but let's face it—sometimes it feels like you're configuring a spaceship just to build a to-do app. Enter Vite, the new kid on the block that's fast, lean, and incredibly straightforward. If you’re considering jumping ship from Webpack to Vite, this guide is for you.

Why Migrate to Vite?

The Pros

Blazing Fast Hot Module Replacement (HMR): Vite's HMR is lightning quick. No more waiting around for Webpack to recompile the entire universe.
Simplicity: Vite’s configuration is straightforward and minimal. You'll spend less time configuring and more time coding.
Modern Features: Out of the box support for TypeScript, ES modules, and more.
Optimized Builds: Vite uses Rollup under the hood for production builds, which is known for its tree-shaking and optimization capabilities.

The Cons

Ecosystem Maturity: Webpack has been around longer, and its ecosystem is more mature. Some plugins and integrations might be missing or less stable in Vite.
Learning Curve: While simpler, Vite has its quirks and differences that you'll need to get used to.

The Hurdles

Compatibility Issues

Moving from Webpack to Vite isn't always smooth sailing. Here are a few potential bumps in the road:

Plugins: Not all Webpack plugins have Vite equivalents. You might need to find alternatives or write custom plugins.
Configuration Differences: Vite’s config file (vite.config.ts) is different from Webpack’s (webpack.config.js). Expect to rewrite parts of your configuration.
Loader Mismatches: Vite handles module loading differently. You might need to tweak or replace some of your current loaders.

Dependencies and Peer Dependencies

Ensure all your dependencies are compatible with Vite. Some older packages might rely heavily on Webpack-specific features.

TypeScript Configuration

Vite’s TypeScript integration is different from Webpack’s ts-loader. Adjustments in your tsconfig.json and project structure might be necessary.

The Migration Guide

Alright, let’s roll up our sleeves and get to work. Here’s a step-by-step guide to migrating a TypeScript project from Webpack to Vite. We’ll use a React project as an example, but the principles apply to Vue, Svelte, or vanilla TypeScript projects as well.

Step 1: Install Vite

First, let's install Vite and its dependencies.

npm install vite @vitejs/plugin-react @vitejs/plugin-typescript

Step 2: Set Up Vite Configuration

Create a vite.config.ts file at the root of your project.

import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';
import tsconfigPaths from 'vite-tsconfig-paths';

export default defineConfig({
  plugins: [react(), tsconfigPaths()],
  server: {
    port: 3000
  },
  build: {
    outDir: 'dist'
  }
});

Step 3: Update tsconfig.json

Make sure your tsconfig.json aligns with Vite’s expectations.

{
  "compilerOptions": {
    "target": "ESNext",
    "module": "ESNext",
    "moduleResolution": "Node",
    "strict": true,
    "jsx": "react-jsx",
    "baseUrl": ".",
    "paths": {
      "@/*": ["src/*"]
    }
  },
  "include": ["src"]
}

Step 4: Update npm Scripts

Replace your Webpack scripts with Vite scripts in package.json.

"scripts": {
  "dev": "vite",
  "build": "vite build",
  "serve": "vite preview"
}

Step 5: Adjust Project Structure

Ensure your project follows Vite’s expectations, which are simpler but sometimes different from Webpack’s.

Public Directory: Move static assets to a public directory.
Entry Point: Ensure your entry point is index.html in the root or src directory.

Example index.html:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Vite + React</title>
</head>
<body>
  <div id="root"></div>
  <script type="module" src="/src/main.tsx"></script>
</body>
</html>

Step 6: Update Import Paths

Vite uses native ES module imports, so adjust any dynamic imports or path aliases to match Vite’s requirements.

import React from 'react';
import ReactDOM from 'react-dom';
import App from './App';
import './index.css';

ReactDOM.render(
  <React.StrictMode>
    <App />
  </React.StrictMode>,
  document.getElementById('root')
);

Step 7: Handle Environment Variables

Vite uses .env files for environment variables. Ensure your variables are prefixed with VITE_ to be accessible in your code.

Example .env:

VITE_API_URL=https://api.example.com

In your code:

const apiUrl = import.meta.env.VITE_API_URL;

Step 8: Test the Migration

Run the dev server and make sure everything works.

npm run dev

Fix any issues that arise. Most commonly, these will be path issues or missing plugins.

Step 9: Build for Production

Once the dev server is running smoothly, try building your project.

npm run build

Deploy your production build and test it thoroughly.

Framework-Specific Considerations

React

Vite’s @vitejs/plugin-react handles React fast refresh and other optimizations out of the box. Ensure your JSX pragma is set correctly in tsconfig.json.

Vue

For Vue projects, use @vitejs/plugin-vue.

npm install @vitejs/plugin-vue

Update vite.config.ts:

import vue from '@vitejs/plugin-vue';

export default defineConfig({
  plugins: [vue()],
});

Svelte

For Svelte projects, use @sveltejs/vite-plugin-svelte.

npm install @sveltejs/vite-plugin-svelte

Update vite.config.ts:

import { svelte } from '@sveltejs/vite-plugin-svelte';

export default defineConfig({
  plugins: [svelte()],
});

Conclusion

Migrating from Webpack to Vite can seem daunting, but the benefits of a faster, simpler build process make it worthwhile. Vite’s modern approach to development aligns perfectly with the rapid pace of modern web development. Sure, there might be a few bumps along the road, but with this guide, you’re well-equipped to tackle the migration head-on.

So, take a deep breath, roll up your sleeves, and get ready to enjoy the speed and simplicity of Vite. Happy coding!

(Parts of this text were created with AI ^^)

DEV Community: Jonas Pfalzgraf

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

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

Wrapping Up

What I used to use and what I use now. Developer Development in a nutshell!

In the beginning there was... SharePoint? And an Angular fork

A breath of fresh air: Vue and the magic of Quasar

The great love: Svelte and syntactic sugar

From foe to friend: My deep dive into React

Conclusion: Pragmatism wins, but the heart beats for Svelte

Shady QR Code Generator Pages? Ugh!

They’re Just Math (Not Magic)

Introducing: Qrify

Check It Out

Societal Critique: The Struggle of Neurodivergent Employees in Neurotypical Work Environments

The Invisible Burden of Neurodivergent Employees

ADHD and AuDHD: Strengths and Challenges

The Economic Consequences of Ignorance

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