DEV Community: Oleksandr Viktor

Fresh BenchmarkDotNet numbers for WJb on .NET 10:

Oleksandr Viktor — Sun, 19 Jul 2026 08:30:10 +0000

WJb Core benchmark results:

CreateOnly: 64.9 ns
ExecuteOnly: 8.9 ns
CreateAndExecute: 75.1 ns

At this point, the profiler spends more time blinking than WJb spends executing.

Good luck catching up. 🚀

https://www.nuget.org/packages?q=WJb

WJb Ecosystem vs Hangfire vs Quartz.NET

Oleksandr Viktor — Sun, 19 Jul 2026 06:30:24 +0000

Why I Would Choose WJb

The .NET ecosystem already has two well-known background processing solutions: Hangfire and Quartz.NET. Both are mature, battle-tested, and widely adopted.

However, the WJb Ecosystem takes a fundamentally different approach.

Instead of focusing solely on scheduling jobs, WJb focuses on building a lightweight, high-performance, and extensible execution platform with a clean separation between execution, storage, hosting, and monitoring.

For many modern .NET applications, this architectural approach can be more valuable than simply having another scheduler.

Quick Summary

Scenario	Recommended Choice
Need a proven solution with a huge ecosystem	Hangfire
Need advanced scheduling and complex cron support	Quartz.NET
Need a lightweight, modern, extensible execution engine	WJb

My personal choice for most new .NET projects would be WJb.

Feature Comparison

Feature	WJb Ecosystem	Hangfire	Quartz.NET
Background Jobs	✅	✅	✅
Delayed Jobs	✅	✅	✅
Recurring Jobs	✅	✅	✅
SQL Storage	✅ WJb.Sql	✅	✅
Monitoring UI	✅ WJb.UI.Blazor	✅ Dashboard	❌ Built separately
Dependency Injection	✅	✅	✅
Extensibility	✅	⚠️	✅
Lightweight Design	✅	❌	❌
Modern .NET Focus	✅	⚠️	⚠️
Learning Curve	✅ Low	✅ Medium	❌ High
Infrastructure Overhead	✅ Low	⚠️ Medium	❌ High

Architectural Comparison

WJb

The WJb ecosystem is built around clear separation of concerns.

WJb
├── Execution
├── Storage
├── Hosting
├── Monitoring UI
└── Extensions

Every layer can evolve independently.

The core engine remains small, understandable, and easy to debug.

Hangfire

Hangfire is built around serialized method execution.

Method Call
    ↓
Serialization
    ↓
Storage
    ↓
State Machine
    ↓
Execution

This model provides excellent convenience but introduces additional infrastructure and internal complexity.

Quartz.NET

Quartz is primarily an enterprise scheduling platform.

Scheduler
    ↓
Trigger
    ↓
Calendar
    ↓
Job Store
    ↓
Job Execution

It is extremely powerful for scheduling scenarios but can feel heavy for many business applications.

What Makes WJb Different

The biggest difference is philosophy.

Hangfire and Quartz were originally designed to answer:

When should work execute?

WJb focuses on:

How should work be executed?

This leads to a cleaner and more flexible architecture.

Why I Prefer WJb Over Hangfire

1. Cleaner Architecture

Hangfire revolves around storing and replaying method invocations.

BackgroundJob.Enqueue(() => SendEmail(id));

This is convenient but tightly couples execution to method serialization.

WJb uses a more explicit execution model.

The result is greater transparency and easier customization.

2. Less Framework Magic

Hangfire contains many internal concepts:

Jobs
Queues
States
Retries
Commands
Continuations
State Machines

While powerful, they require developers to understand Hangfire internals.

WJb exposes a much simpler mental model.

3. Better Separation of Concerns

One of WJb's strongest design decisions is explicit separation between:

Execution
Storage
Hosting
Monitoring

Benefits include:

Easier testing
Easier maintenance
Better extensibility
Lower coupling
Cleaner abstractions

4. Modern Blazor-Based UI

WJb.UI.Blazor provides a modern approach to monitoring and administration.

Advantages include:

Component-based architecture
Easy customization
Native Blazor integration
Rich administration experiences
Consistent .NET development stack

Compared to traditional dashboards, this approach feels more future-oriented.

5. Complete Control

One of the biggest advantages of WJb is visibility.

The framework does not try to hide execution details behind multiple abstraction layers.

Developers maintain control over how jobs are executed, stored, monitored, and extended.

Why I Prefer WJb Over Quartz.NET

1. Lower Complexity

Quartz introduces many concepts:

IScheduler
IJob
ITrigger
Calendar
Listener
JobStore
Misfire Policies

These features are useful but increase complexity significantly.

Most applications never utilize the full capabilities of Quartz.

2. Faster Onboarding

Typical onboarding experience:

Quartz.NET

1-3 days

WJb

1-2 hours

A simpler architecture allows new developers to become productive much faster.

3. Focus on Business Execution

Quartz focuses on scheduling.

WJb focuses on execution.

In many business systems, execution pipelines are more important than complex scheduling rules.

The Ecosystem Advantage

The most interesting aspect is not the core package alone.

It is the ecosystem.

WJb
├── WJb.Sql
├── WJb.UI.Blazor
└── WJb.Pro

This modular structure resembles successful .NET ecosystems such as:

Serilog
MassTransit
Entity Framework

A lightweight core combined with optional modules typically scales much better than a monolithic framework.

Areas Where Hangfire Still Wins

To be fair, Hangfire remains stronger in several areas.

Maturity

Hangfire has:

Many years of production usage
Large community adoption
Extensive documentation
Numerous tutorials
Large ecosystem support

This significantly reduces adoption risk.

Third-Party Integrations

Hangfire offers a very large collection of storage providers and integrations:

SQL Server
PostgreSQL
Redis
MongoDB
Azure Services

Its ecosystem is currently much larger.

Industry Recognition

Most architects and developers immediately recognize:

Hangfire

WJb is still building that brand recognition.

Why I Would Personally Choose WJb Today

Ignoring popularity and focusing purely on architecture, I would choose WJb because of:

Simplicity

Less infrastructure.

Less complexity.

Less maintenance.

Modern Design

WJb feels designed specifically for modern .NET.

Not adapted to it.

Architectural Clarity

The framework makes execution behavior visible and understandable.

Debugging and troubleshooting become significantly easier.

Blazor Administration

WJb.UI.Blazor provides an administration experience that aligns naturally with modern .NET applications.

Growth Potential

WJb currently has many characteristics historically shared by successful infrastructure projects:

Focused
Lightweight
Modern
Fast
Extensible

These qualities often matter more in the long run than initial popularity.

Final Verdict

Hangfire is an excellent background job processor.

Quartz.NET is an excellent scheduler.

WJb Ecosystem is a modern execution platform designed around simplicity, extensibility, and architectural clarity.

If I were starting a new .NET project today and evaluating technology primarily from an engineering perspective, I would most likely choose WJb.

Because in many modern systems:

Simplicity beats complexity.

And WJb achieves that simplicity without sacrificing extensibility.

🚀 New WJb Demo: Workflow Monitoring in Action

Oleksandr Viktor — Sat, 18 Jul 2026 18:09:39 +0000

🚀 New WJb Demo: Workflow Monitoring in Action

Want to see what a complete workflow looks like in WJb?

The new WJb.Demo.Monitor sample demonstrates an end-to-end job pipeline with a live monitoring UI.

✅ Import Customers

✅ Generate Report

✅ Send Email

✅ Monitor execution in real time

Run a single action:

await wjb.EnqueueAsync(
    ImportCustomersAction.Key,
    new ImportCustomersInput
    {
        Source = "CRM"
    });

WJb automatically chains the workflow:

import-customers
        ↓
generate-report
        ↓
send-email

Every step becomes visible in the monitoring dashboard.

What the sample demonstrates

Typed action inputs
Constructor dependency injection
Workflow chaining via IAction.NextAsync(...)
Progress reporting
Background job execution
Real-time monitoring UI
Job payload inspection
Action discovery
Service discovery

Monitor Features

The built-in Blazor monitor provides:

Job status tracking
Progress visualization
Execution history
Payload inspection
Registered actions
Registered services

Why it is interesting

The entire workflow is composed of small focused actions:

import-customers
generate-report
send-email

No workflow designer.

No XML.

No complex configuration.

Just C# actions connected through explicit workflow transitions.

Sample

🔗 https://github.com/UkrGuru/WJb.Demo/tree/main/samples/WJb.Demo.Monitor

The sample includes:

Workflow execution
Action chaining
Progress reporting
Live monitoring
Payload inspection
Actions explorer
Services explorer

Perfect for understanding how WJb workflows behave in a real application.

🚀 WJb Monitor is coming together.

Oleksandr Viktor — Wed, 15 Jul 2026 16:14:01 +0000

Over the last few days I focused on completing the monitoring UI for WJb.

Current state:

✅ Jobs monitoring
✅ Job details and payload viewer
✅ Actions management
✅ Services management
✅ SQL Store integration
✅ Real job execution testing
✅ Retry and progress tracking
✅ Responsive Blazor UI

A few screenshots are attached, including an animated walkthrough of the application.

One pleasant surprise during development: I completely removed the dependency on Bootstrap Icons. Navigation now uses lightweight SVG icons, while action buttons use simple Unicode symbols. The result is cleaner than expected and has zero external dependencies.

The original plan also included a dashboard page, but after using the application in practice I decided to postpone it. The current feature set already delivers real value, and I'd rather gather experience from actual usage before adding metrics and analytics.

The goal remains unchanged:

🎯 WJb v1.0 Release

Everything is progressing according to plan, and the first stable release is getting very close.

dotnet #csharp #blazor #opensource #softwaredevelopment #jobs #scheduler #microsoft #sqlserver #webdevelopment

🚀 New workflow samples added to WJb Demo (Blazor WASM)

Oleksandr Viktor — Tue, 30 Jun 2026 08:35:11 +0000

🚀 New workflow samples added to WJb Demo (Blazor WASM)

I've just expanded the WJb demo application with two new workflow-focused samples:

✅ Retry Workflow

Automatic retries with JobOptions
Retry delay configuration
Workflow continuation after successful retry
Demonstrates retry inheritance across chained actions

✅ Order Workflow

Multi-step business workflow
CreateOrder → ReserveStock → ChargePayment → SendConfirmation
Progress reporting across workflow steps
Action chaining via ActionResults.Next(...)
Payload propagation between actions

These samples were added while building a new WorkflowTests suite, which also helped uncover and fix several workflow engine issues, including:

Dead-letter infinite loop scenarios
Missing retry policy inheritance for chained actions

The result is a much stronger demonstration of how WJb can be used for real workflow orchestration rather than just background jobs.

🔗 Demo source:
https://github.com/UkrGuru/WJb.Demo/tree/main/samples/WJb.Demo.Wasm

dotnet #csharp #blazor #opensource #workflow #backgroundjobs #aspnetcore #softwarearchitecture #testing #wasm #wjb #ukrguru

📦 WJb.Demo (WASM)

Oleksandr Viktor — Mon, 29 Jun 2026 14:27:52 +0000

📦 WJb.Demo (WASM)

Lightweight demo application showcasing WJb background job engine running in a Blazor WebAssembly (WASM) environment.

🚀 Overview

WJb.Demo (WASM) demonstrates how to:

Execute background jobs in a client-side environment
Track job lifecycle and progress in real time
Use clean, decoupled job actions
Chain and configure actions
Handle success, failure, and cancellation scenarios

🧩 Features

✅ Job dashboard with live updates
✅ Multiple action types:
- Hello Action
- Configured Action
- Progress Action
- Chained Actions
✅ Progress tracking (0–100%)
✅ Status handling:
- Completed
- Failed
✅ Message output per job
✅ Job cleanup support

🖥️ UI Overview

The demo UI includes:

Sidebar navigation
- Dashboard
- Action samples
Active Jobs table
- ID
- Status
- Progress bar
- Message
- Remove action

Example states:

Completed jobs with full progress
Failed jobs with partial progress
Informational messages for each job

⚙️ How It Works

WJb separates concerns into:

Execution – runs actions
Storage – tracks job state
Hosting – coordinates lifecycle

In this demo:

Jobs are triggered from UI
Execution happens in WASM runtime
Progress updates are reflected immediately

▶️ Run Locally

git clone https://github.com/UkrGuru/WJb.Demo
cd WJb.Demo
dotnet run

Then open:

https://localhost:7268

🧪 Example Scenarios

Run simple job (Hello Action)
Execute configured job (SMTP simulation)
Track progress over time
Trigger chained jobs
Observe failure handling

📌 Notes

This is a demo application intended for showcasing WJb capabilities.
Behavior and APIs may evolve.
Some features may be simplified for demonstration purposes.

⚡ WJb QuickStart

Oleksandr Viktor — Fri, 26 Jun 2026 18:51:56 +0000

⚡ WJb Quick Start

This is the fastest way to understand how WJb works.

🧠 What you will see

send-email → log → done

A simple job workflow where:

one job is enqueued
the action performs work
the action explicitly schedules the next step
the workflow completes

👉 No hidden behavior. No magic.

🚀 Run

dotnet run

✅ Code

using WJb;

Console.OutputEncoding = System.Text.Encoding.UTF8;

Console.WriteLine("=== WJb Quick Start ===\n");

Console.WriteLine($"""
Workflow:
{Actions.SendEmail} → {Actions.Log} → done

""");

var store = new InMemoryStore();

// Configure actions and services
var wjb = WJbBuilder.Create(store, cfg =>
{
    cfg.AddAction<SendEmailAction>(Actions.SendEmail);
    cfg.AddAction<LogAction>(Actions.Log);

    cfg.AddService(new SmtpSettings
    {
        Host = "smtp.local"
    });
});

// Enqueue first job
Console.WriteLine($"[App] Enqueue: {Actions.SendEmail}");

await wjb.EnqueueAsync(
    Actions.SendEmail,
    new EmailInput
    {
        To = "user@test.com"
    });

// Execute all pending jobs
Console.WriteLine("[App] Start execution...\n");

await wjb.ExecuteLoopAsync();

Console.WriteLine("\n=== Completed ===");

public static class Actions
{
    public const string SendEmail = "send-email";
    public const string Log = "log";
}

// Action: SendEmailAction
public sealed class SendEmailAction(SmtpSettings smtp)
    : JobAction<EmailInput>
{
    private readonly SmtpSettings _smtp = smtp;

    public override Task<ActionResult> ExecuteAsync(
        EmailInput input,
        CancellationToken ct)
    {
        Console.WriteLine(
            $"[Action] {Actions.SendEmail} → {input.To} via {_smtp.Host}");

        return Task.FromResult(
            ActionResults.Next(
                new JobCommand(
                    Actions.Log,
                    new LogInput
                    {
                        Message = $"Email sent to {input.To}"
                    })));
    }
}

// Action: LogAction
public sealed class LogAction : JobAction<LogInput>
{
    public override Task<ActionResult> ExecuteAsync(
        LogInput input,
        CancellationToken ct)
    {
        Console.WriteLine(
            $"[Action] {Actions.Log} → {input.Message}");

        return Task.FromResult(ActionResults.None());
    }
}

// Input: EmailInput
public sealed class EmailInput
{
    public string? To { get; set; }
}

// Input: LogInput
public sealed class LogInput
{
    public string? Message { get; set; }
}

// Service: SmtpSettings
public sealed class SmtpSettings
{
    public string Host { get; set; } = default!;
}

✅ Output

=== WJb Quick Start ===

Workflow:
send-email → log → done

[App] Enqueue: send-email
[App] Start execution...

[Action] send-email → user@test.com via smtp.local
[Action] log → Email sent to user@test.com

=== Completed ===

💡 What this demonstrates

Actions contain business logic
Actions can use dependency injection
Services are resolved automatically
Each action explicitly defines the next step
Workflows are deterministic and visible
Jobs can be executed through a store-backed runtime

👉 You always know what happens and why.

🔥 Key idea

return ActionResults.Next(
    new JobCommand(
        Actions.Log,
        new LogInput
        {
            Message = $"Email sent to {input.To}"
        }));

👉 The workflow is defined in code, not hidden in the framework.

⚡ Learn more

➡️ https://www.nuget.org/packages/WJb

➡️ https://github.com/UkrGuru/WJb.Demo

🎁 Support WJb

If you like this idea:

👉 https://ko-fi.com/ukrguru

Early supporters (before August 1, 2026):

👉 🎁 FREE Solo License

Most .NET background job systems are wrong.

Oleksandr Viktor — Fri, 26 Jun 2026 18:33:36 +0000

Most .NET background job systems are wrong.

They look simple:

BackgroundJob.Enqueue(() => DoWork());

But what actually happens?

Job → retry → pipeline → continuation → retry → ???

At some point:

❌ you don’t know why it ran
❌ you don’t know what triggered the next step
❌ you can’t explain the execution flow

This becomes a problem when background jobs contain business logic.

So I built WJb.

Not a framework.

An explicit job execution engine.

Where everything looks like this:

Job → Action → ActionResult → Next Job

And every workflow step is defined in code:

return ActionResults.Next(
new JobCommand(
LogAction.Key,
new LogInput
{
Message = "Done"
}));

No magic.
No hidden pipelines.
No implicit orchestration.

You always know:

✅ why a job runs
✅ what happens next
✅ how the flow evolves

Try it in 30 seconds:

👉 https://github.com/UkrGuru/WJb.Demo/tree/main/quickstart

NuGet:

👉 https://www.nuget.org/packages?q=WJb

If this idea resonates, I'd love your feedback.

🚀 Running Background Jobs in Blazor WASM with WJb (No Backend Required)

Oleksandr Viktor — Mon, 01 Jun 2026 11:55:42 +0000

🚀 Running Background Jobs in Blazor WASM with WJb (No Backend Required)

Background processing usually implies servers, queues, workers… and complexity.

But what if you could run job processing entirely in the browser — with tracking, retries, and cancellation — using a clean API?

That’s exactly what WJb enables.

In this article, I’ll show a simple but powerful demo of WJb running inside Blazor WebAssembly, where jobs are:

✅ Queued with one click
✅ Tracked in real-time
✅ Cancelled or retried from the UI

🧠 What is WJb?

WJb is a lightweight job engine designed for simplicity:

Minimal API surface
Clear job lifecycle (Queued → Processing → Completed/Failed/Cancelled)
Built-in progress tracking
Retry & cancellation support
Works even in WASM (no server required)

🎯 The Demo

The UI is extremely simple:

A Run Demo Job button
A table showing:
- Job ID
- Status
- Progress
- Message
- Attempts
- Actions (Cancel / Retry)

Here’s the core Razor page:

@page "/"

@using WJb.Abstractions
@using WJb.Core
@using WJb.Demo.Wasm.Actions

@inject IJobEngine Engine

▶️ Starting a Job

Enqueueing a job is just one line:

private void Start()
{
    Engine.Enqueue<DemoAction, DemoPayload>(
        new DemoPayload
        {
            DelayMs = 5000,
            Text = "Done ✅"
        });
}

That’s it.

No queue setup.

No worker service.

No background host.

Just enqueue and go.

🔄 Real-Time UI Updates

WJb exposes a simple event:

protected override void OnInitialized()
{
    Engine.Changed += HandleChanged;
    tasks = Engine.GetAll().ToList();
}

private void HandleChanged()
{
    InvokeAsync(() =>
    {
        tasks = Engine.GetAll().ToList();
        StateHasChanged();
    });
}

Whenever a job updates (progress/status), the UI refreshes automatically.

📊 Job State Rendering

Each job comes with a state object:

t.State.Status
t.State.Progress
t.State.Message
t.State.Attempts

Rendering status is clean and expressive:

<span class="badge @(t.State.Status switch
{
    JobStatus.Processing => "bg-primary",
    JobStatus.Completed => "bg-success",
    JobStatus.Failed => "bg-danger",
    JobStatus.Cancelled => "bg-danger",
    _ => "bg-secondary"
})">

And progress is just a Bootstrap bar:

<div class="progress-bar"
     style="width:@t.State.Progress%">
    <small>@t.State.Progress%</small>
</div>

✋ Cancel & Retry

WJb supports job control out of the box:

private void Retry(string id) => Engine.Retry(id);
private void Cancel(string id) => Engine.Cancel(id);

UI logic:

@if (t.State.Status is JobStatus.Queued or JobStatus.Processing)
{
    <button @onclick="() => Cancel(t.JobId)">❌</button>
}
else if (t.State.Status is JobStatus.Failed or JobStatus.Cancelled)
{
    <button @onclick="() => Retry(t.JobId)">🔄</button>
}

🧩 The Interesting Part: It Runs in WASM

This is where things get fun.

All of this works:

✅ Without ASP.NET backend
✅ Without queues like RabbitMQ
✅ Without hosted services

The job engine runs inside the browser runtime.

This makes it perfect for:

Client-side automation
Long-running UI tasks
Offline-first applications
Interactive demos and tooling

💡 Why This Matters

Most job systems are:

Heavy
Infrastructure-dependent
Hard to integrate into UI

WJb flips that:

Traditional Jobs	WJb
Requires backend	Works in WASM
Worker services	In-process engine
Complex setup	Simple API
Limited UI integration	Built for UI

🔥 Key Takeaways

WJb gives you background jobs without infrastructure
Blazor WASM can handle real-time job processing
The API is intentionally minimal:
- Enqueue
- Retry
- Cancel
- GetAll
UI integration is trivial via Engine.Changed

🚀 Final Thoughts

This demo is small, but the idea is powerful:

Background processing doesn’t have to mean backend complexity.

With WJb, you can build responsive, controllable job workflows in the browser.

WJb: Explicit Background Jobs for .NET (Near v1.0)

Oleksandr Viktor — Tue, 28 Apr 2026 10:23:29 +0000

WJb: Explicit Background Jobs for .NET (Near v1.0)

Background processing in .NET often starts simple — and quietly becomes complex.

Retries appear where you did not expect them.

Execution happens “somewhere in the background”.

Workflows grow implicit behavior few people fully understand.

WJb was created as a response to that drift.

As the project approaches v1.0, this article explains what WJb is, what it deliberately is not, and why its design looks different from most background job frameworks.

The Problem WJb Tries to Solve

Many background job frameworks optimize for convenience:

automatic retries
implicit pipelines
hidden orchestration
dynamic runtime behavior

These features are useful — until background execution becomes core business logic.

At that point, questions become difficult to answer:

Why did this job run?
Why did it retry?
What state did it operate on?
What decides the next step?

WJb takes a different stance:

If background jobs are part of your domain, their behavior must be explicit and predictable.

Core Design Principles

WJb is built around a small number of firm rules.

1. Queue‑First, Always

Nothing executes immediately.

Every unit of work:

is serialized into a job payload
enters a queue explicitly
is processed later by a worker

This establishes a hard boundary between intent and execution.

request work → enqueue → execute later

No method call ever causes hidden execution.

2. Explicit Execution Model

WJb does not provide:

automatic retries
implicit continuation
background pipelines
workflow engines

If a job continues, it does so because code explicitly enqueued the next job.

await jobs.EnqueueJobAsync(nextJob);

Routing belongs to actions, not infrastructure.

3. Immutable Snapshots

Execution in WJb operates on immutable snapshots:

action registries are built deterministically
snapshots are replaced atomically
readers never observe partial state

This model avoids synchronization complexity and makes reasoning about concurrency trivial.

4. Actions Own Their Lifecycle

In WJb:

infrastructure executes
domain code decides

Actions:

read metadata
perform work
optionally enqueue the next job

Infrastructure never orchestrates workflows or interprets intent.

A Minimal Example

var job = await jobs.CompactAsync(
    "hello",
    new { name = "World" });

await jobs.EnqueueJobAsync(job);

That is all it takes to enqueue work.

Execution happens:

when the host starts
when the processor consumes the queue
with no hidden steps

Workflow Example (Explicit by Design)

fib-start → fib-build

The continuation is not implicit.

The first action decides explicitly:

await jobs.EnqueueJobAsync(nextJob);

No framework magic.

No pipeline inference.

No hidden guarantees.

Performance Without Tricks

Despite its explicit design, WJb is fast — very fast.

Recent baseline benchmarks (Free edition):

~830k jobs/sec single‑thread enqueue
~1.9M jobs/sec multi‑thread enqueue (20 threads)
✅ strict FIFO within priority
✅ strict priority precedence

These numbers come without unsafe code, without custom schedulers, and without sacrificing correctness.

Performance is a natural outcome of the architecture — not a special optimization step.

What WJb Intentionally Does Not Do

WJb is not trying to replace everything.

It deliberately avoids:

delivery guarantees
persistent storage by default
retries or backoff strategies
distributed coordination
dynamic workflow engines

These concerns belong either:

to hosting infrastructure
or to explicit domain code

WJb’s job is to remain transparent and predictable.

Free Edition Today, v1.0 Tomorrow

As of v0.29, the Free API is frozen.

That means:

public contracts are stable
documented behavior matches runtime behavior
samples and tests reflect real execution

The next step toward v1.0 is real‑world usage, not feature expansion.

v1.0 will not mean “more features”.

It will mean confidence.

Who WJb Is For

WJb is for engineers who:

design long‑living systems
operate production infrastructure
value explicit behavior over automation
want background code to behave like foreground code

If convenience tooling worked for your case — keep using it.

If you ever said “I want to see exactly what happens” — WJb may be for you.

Closing Thoughts

WJb does not try to be clever.

It tries to be honest.

Honest about:

when work runs
why it runs
what state it sees
and what happens next

As the project moves toward v1.0, that principle remains unchanged.

Repository:

👉 https://github.com/UkrGuru/WJb

WJb 0.28.0 Released 🚀

Oleksandr Viktor — Thu, 23 Apr 2026 08:36:03 +0000

WJb 0.28.0 is now available on NuGet.
This release is focused on stability and correctness, especially for long‑running and scheduled workloads:

Improved internal execution reliability
Better cancellation behavior during delays and iterations
Expanded unit test coverage for worker and scheduler logic
No breaking changes

If you’re using WJb for background jobs or scheduled processing, this release strengthens the foundations without requiring code changes.
👉 NuGet: https://www.nuget.org/packages/WJb/0.28.0

Serious question: at this point… who still needs it faster? 🚀

Oleksandr Viktor — Mon, 20 Apr 2026 13:32:27 +0000