DEV Community: Muhammad Sheharyar Butt

Five Characters Too Long: Auditing My Own URL Shortener

Muhammad Sheharyar Butt — Mon, 17 Aug 2026 11:24:39 +0000

I run Shorty, an open-source URL shortener I built and self-host.
It does the usual things — short links, QR codes, click analytics — plus a moderation
console with role-based access, an audit log and abuse triage. The whole thing is
TypeScript: Next.js 16 on the front, Express 5 and Drizzle over MySQL/TiDB on the back.

The README claimed, among other things, that "identical error messages prevent account
enumeration."

I sat down to audit my own code and found out that sentence was false. Here's what a
careful pass over a codebase you wrote yourself actually turns up.

The bug that started it

Here is the entire defect. It is one line, in the admin login handler:

if (!account) {
  // Spend comparable time so a missing account is not detectably faster.
  await verifyPassword(password, '$2b$12$invalidinvalidinvalidinvalidinvalidinvalidinvalidinvalidin');
  throw genericFailure;
}

The intent is textbook. When someone tries to log in with an email that doesn't exist,
you don't want to return instantly — that reveals the address isn't registered. So you
burn the same CPU you would have burned verifying a real password, then return the same
generic error.

The comment is right. The code does not do what the comment says.

A bcrypt hash is exactly 60 characters. That literal is 65. bcryptjs validates the
shape of the hash before it does any work, and bails immediately when it doesn't parse.

So I measured it:

unknown account (malformed hash):    0.04 ms
real account   (genuine hash):     264.73 ms

That's a 6,000x difference, from a single unauthenticated request, with no rate limit
worth speaking of and no lockout on that path. You don't need statistics or timing
analysis. You need a stopwatch. Feed it a list of candidate emails and the ones that come
back slowly are real administrators.

The fix is to stop hand-writing the hash and generate one, then assert the thing that
actually matters:

export function dummyPasswordHash(): string {
  if (dummyHash === undefined) {
    dummyHash = bcrypt.hashSync(generateOpaqueToken(32), BCRYPT_ROUNDS);
    if (dummyHash.length !== 60) {
      throw new Error(`bcrypt returned a ${dummyHash.length}-character hash; the login timing guard is broken`);
    }
  }
  return dummyHash;
}

After: 0.98x. Indistinguishable.

There's a second-order lesson in the lazy initialisation. Deriving a cost-12 hash takes
~250 ms, and the module is imported by the redirect path too — so computing it at import
time would have added a quarter second to every cold start on a serverless deploy, in
order to protect a login endpoint. Security fixes have a blast radius.

The one I'm most annoyed about

Same login handler, a few lines down:

if (account.lockedUntil && account.lockedUntil.getTime() > Date.now()) {
  throw new AppError(423, 'ACCOUNT_LOCKED', `Too many failed attempts. Try again in ${minutes} minutes.`);
}

Account lockout is a good control. But look at what it returns: a 423 with a countdown,
where every other failure returns a generic 401.

I built a careful anti-enumeration story on one path and then handed the answer away on
another. Five failed logins against any address, and the status code tells you whether
that address belongs to a real admin. The locked branch also returned before doing any
bcrypt work, so it was fast as well as differently-shaped.

It now returns the same 401, after the same bcrypt spend, and writes the audit entry that
path was silently missing. Legitimate admins lose the "try again in 12 minutes" message.
That's the trade, and it's the right one.

When your defence has a formatting dependency

The link-safety guard refuses destinations that point at private networks. It handled
IPv4-mapped IPv6 addresses — the trick where you smuggle 127.0.0.1 inside a v6 literal:

const mapped = normalised.match(/::ffff:(\d+\.\d+\.\d+\.\d+)$/);
if (mapped?.[1]) return isPrivateIpv4(mapped[1]);

Reasonable. Except the check runs on a hostname that has already been through the WHATWG
URL parser, and that parser rewrites the address:

new URL('https://[::ffff:127.0.0.1]/').hostname
// '[::ffff:7f00:1]'

The dotted quad becomes hex. The regex requires dots. It never matched a single real
request.

So [::ffff:a9fe:a9fe] — the cloud metadata endpoint, 169.254.169.254, wearing an IPv6
hat — sailed straight through. Along with five other forms.

The fix was to stop parsing addresses by hand:

const PRIVATE_RANGES = new BlockList();
PRIVATE_RANGES.addSubnet('127.0.0.0', 8, 'ipv4');
PRIVATE_RANGES.addSubnet('169.254.0.0', 16, 'ipv4');
// ...

// 'ipv6' is deliberate even for an IPv4-mapped address: BlockList maps it
// back onto the IPv4 entries above, which is what closes the bypass.
if (ipVersion === 6) return PRIVATE_RANGES.check(host, 'ipv6');

Node's built-in net.BlockList resolves IPv4-mapped addresses against the IPv4 rules
natively. Six bypasses closed, and — verified — nothing legitimate over-blocked.

The pattern worth taking away: my check ran on a different string than the one I wrote it
against. Anywhere a value passes through a normaliser between validation and use, that's
where the bug lives.

Controls that report success while doing nothing

Three findings shared a shape, and it's the shape I now look for first.

"Revoke sessions" didn't revoke sessions. The emergency force-sign-out button
incremented a tokenVersion column, which kills outstanding access tokens. But the refresh
endpoint never compared sessions against that version — so a stolen refresh token could be
exchanged straight back for a fresh access token carrying the new version. The button
returned {revoked: true}, wrote a satisfying audit entry, and changed nothing an attacker
would notice. For up to seven days.

Blocking a domain didn't block existing links. The blocklist had exactly one reader:
the create-link path. Block evil.com and every link already pointing there kept
redirecting, indefinitely, while the console displayed the domain as blocked. The
moderation control worked perfectly for the case where nobody had attacked you yet.

Rate limiting three routes that had none. In Express, router.use() only runs for
requests that reach it in stack order:

adminRouter.post('/auth/password', requireAdmin, asyncHandler(changePassword));
// ... more routes ...
adminRouter.use(requireAdmin, adminApiLimiter);   // never runs for anything above

/auth/password runs two bcrypt operations per call — roughly 600 ms of single-threaded
CPU — and any token holder, down to the lowest role, could loop it with a wrong password
and stall the process that also serves every public redirect.

A control that fails loudly gets fixed. A control that succeeds quietly while doing nothing
can sit there for a year.

The rest, briefly

The login rate limiter was keyed on attacker-controlled input (ip:email). Vary the email, get unlimited fresh buckets. It also never trimmed the email while the database lookup did — so "admin@x.com" and "admin@x.com " were separate budgets hitting the same row, which is enough to hold any known admin in a permanent lockout.
A legacy compatibility endpoint bypassed every per-action limiter, allowing ~80x the intended abuse-report rate. Enough for a handful of hosts to auto-block arbitrary links with no human involved.
/health echoed raw driver errors to anonymous callers — database hostname, port, and Access denied for user 'x'@'y'.
The admin console had no CSRF protection. The session cookies were SameSite=Lax, which I had filed as "handled". Lax is a same-site control, and site means registrable domain — which my API subdomain shares with the web app. Any page on any sibling subdomain could drive every admin write with the operator's cookies attached.
The blocklist failed open. A database error returned an empty list, so on a cold serverless process whose first round-trip timed out, every blocked domain was accepted — and permanently minted, because nothing re-checked existing links.

Ten findings. None of them were exotic. All of them were in code I wrote, reviewed, and
shipped.

What I actually changed about how I work

Every security claim in a README is a test that doesn't exist yet. I wrote "prevents
account enumeration" and then never wrote the assertion. The claim had been false since the
day it was committed. There are now 27 tests, and every bypass above is pinned as a
regression case — because the SSRF guard in particular fails silently. A hole in it looks
exactly like a working shortener right up until someone points a link at your metadata
endpoint.

Comments describe intent, not behaviour. // Spend comparable time was accurate about
what I meant and wrong about what ran. When reviewing, read the code as if the comment
isn't there — then check whether they agree.

Prefer the boring standard-library primitive. My hand-rolled IP range checks had a
subtle formatting dependency. net.BlockList has been correct for years and handles a
case I didn't know existed.

Check whether your control has ever fired. "Does this code run?" caught three findings.
For any security control, trace one real request through it and confirm the guard is on the
path. Middleware ordering, cache population, retroactive application — these are where
things quietly do nothing.

Audit the seams. Nearly every finding lived at a boundary: between a parser and a
validator, between route registration and middleware, between two subdomains that a browser
considers the same site. The code inside each module was fine. The bugs were in the joins.

Closing

Everything above is fixed and shipped in
v3.0.1. The full
changelog has the
per-file detail, and the code is on GitHub if
you want to check my work — genuinely, please do.

Two things I'd suggest if you're about to do this to your own project. Run your git history
through a secret scanner before anything else; rotating a credential is cheap, and finding
out later that it's been public for two years is not. And write the audit down as you go,
findings and non-findings both. Half the value turned out to be the list of things I
checked and didn't find, because that's the list I don't have to check again.

The most uncomfortable part wasn't any individual bug. It was that I'd written a security
section in the README describing the system I intended to build, and never gone back to
verify I'd built it.

🚀 Introducing SysPeek v2.0.0 - A Modern System Information Viewer for Windows, macOS, and Linux (New Release!)

Muhammad Sheharyar Butt — Sat, 15 Aug 2026 21:16:08 +0000

Introducing SysPeek v2.0.0: A Modern Cross-Platform System Monitor Built with Electron & React

A complete architectural rewrite featuring Electron 43, React 19, TypeScript, Vite, automatic updates, live monitoring, and a secure Electron architecture.

Introduction

I'm excited to announce the release of SysPeek v2.0.0.

While previous versions focused on providing an intuitive hardware information viewer, version 2 represents a complete rebuild of the application from the ground up.

This release modernizes every layer of the project—from the build system and security model to the user interface and update mechanism—creating a faster, more maintainable, and production-ready desktop application.

Built with Electron, React, TypeScript, and Vite, SysPeek now delivers real-time system monitoring, detailed hardware information, automatic updates, and a hardened Electron architecture designed for modern desktop development.

What is SysPeek?

SysPeek is a modern desktop application that allows you to inspect your computer's hardware and monitor live system performance from a single interface.

Rather than relying on multiple utilities, SysPeek combines hardware inspection, performance monitoring, system diagnostics, and productivity tools into one lightweight application.

Whether you're a developer, IT administrator, technician, or simply curious about your hardware, SysPeek provides detailed insights in a clean and responsive interface.

What's New in Version 2?

Version 2 isn't simply an update—it's a complete architectural redesign.

Every major subsystem has been rebuilt to improve performance, maintainability, scalability, and security.

Major Improvements

Complete migration to electron-vite
Fully rewritten using TypeScript
Electron 43
React 19
Ant Design 6
Vite 7
Automatic application updates
Secure IPC communication layer
Context isolation and sandbox enabled
Live history charts
System tray integration
Theme customization
Report exporting
Notification system
Better application startup performance

Modern Technology Stack

SysPeek is powered by modern desktop technologies.

Layer	Technology
Desktop Framework	Electron 43
Frontend	React 19
Language	TypeScript 6
Build Tool	Vite 7 + electron-vite
UI Framework	Ant Design 6
Charts	uPlot
Hardware Information	systeminformation
Updates	electron-updater
Packaging	electron-builder

This stack enables fast development while delivering native desktop performance.

Live Performance Dashboard

SysPeek now features a completely redesigned Task Manager-inspired dashboard.

Monitor your system in real time with:

Live CPU utilization
Memory usage
Disk I/O
Network throughput
System uptime
Per-core processor load
Historical performance charts

Everything updates continuously without overwhelming system resources.

Comprehensive Hardware Information

Beyond performance monitoring, SysPeek provides detailed hardware inspection across every major component.

Available Pages

System
CPU
Memory
Graphics
Display
Storage
Operating System
Network
WiFi
Battery
Audio
Bluetooth
USB Devices
Printers

Each section presents hardware specifications in a structured and easy-to-read format.

Process Explorer

Version 2 introduces a significantly improved process manager.

Features include:

Running process list
Search
Sorting
CPU usage
Memory consumption

Making it easier to identify resource-intensive applications.

Live History Charts

Instead of displaying only current values, SysPeek now records live history.

Track:

CPU activity
Memory usage
Network traffic
Disk utilization

using smooth real-time charts powered by uPlot.

System Tray Integration

SysPeek continues monitoring even when minimized.

The new system tray includes:

Live CPU usage
Memory usage
Quick actions
Restore application
Exit application

Desktop Notifications

Stay informed when your system exceeds configured limits.

SysPeek can notify you when:

CPU usage becomes too high
CPU temperature exceeds thresholds
Memory usage becomes critical
Disk utilization reaches configured limits

Thresholds are fully customizable.

Settings & Customization

The new Settings panel allows you to personalize the application.

Available options include:

Dark & Light themes
Accent colors
Refresh intervals
Launch at startup
Tray behavior
Notification thresholds

Export System Reports

Need to share your hardware information?

SysPeek can export a complete machine report as JSON, making it useful for troubleshooting, diagnostics, or technical support.

Automatic Updates

One of the biggest additions in version 2 is seamless application updates.

SysPeek now includes:

GitHub Releases integration
Background update downloads
Restart & Install workflow
Multi-platform release pipeline

Keeping the application up-to-date is now effortless.

Security First

Desktop applications often overlook security.

SysPeek follows Electron's recommended security practices.

Security Features

Context Isolation enabled
Sandbox enabled
Node Integration disabled
Secure preload bridge
Typed IPC communication
Strict Content Security Policy
Whitelisted API exposure

System information is collected only in the Electron main process, while the React interface communicates through a carefully controlled IPC bridge.

Cross-Platform Support

SysPeek supports all major desktop operating systems.

Available Platforms

Windows
macOS
Linux

Production installers are available for each platform.

Development Experience

The migration to electron-vite dramatically improves development speed.

Benefits include:

Instant hot reload
Faster builds
Type-safe IPC
Better project organization
Shared TypeScript models
Cleaner architecture

The project is now significantly easier to maintain and extend.

Getting Started

Clone the repository and install dependencies.

git clone https://github.com/shehari007/SysPeek-hwinfo-react-electron-app.git

cd SysPeek-hwinfo-react-electron-app

npm install

npm run dev

The development server launches Electron with hot reload for both the renderer and the main process.

Build Production Installers

Generate installers for your platform using:

Windows

npm run build:win

Linux

npm run build:linux

macOS

npm run build:mac

Source Code

SysPeek is completely open source and licensed under the MIT License.

GitHub Repository

https://github.com/shehari007/SysPeek-hwinfo-react-electron-app

Latest Releases

https://github.com/shehari007/SysPeek-hwinfo-react-electron-app/releases

Why I Built SysPeek

Most system information tools are either outdated, overly technical, or cluttered with interfaces that haven't evolved in years.

I wanted to build something different—a modern desktop application that combines detailed hardware information with real-time monitoring, while following current Electron best practices for security, performance, and maintainability.

SysPeek is the result of that vision.

What's Next?

Future development will focus on expanding SysPeek even further.

Planned features include:

GPU benchmarking
Historical analytics
Plugin architecture
Remote system monitoring
Performance recording
CSV & PDF report export
Multi-language support
Custom dashboard widgets

Final Thoughts

SysPeek v2.0.0 is by far the biggest release since the project began.

From the migration to Electron + Vite and full TypeScript support to automatic updates, secure IPC communication, live monitoring, and a redesigned interface, every part of the application has been modernized.

If you're looking for an open-source, cross-platform system monitor built with modern web technologies, I hope SysPeek becomes a useful addition to your toolkit.

If you enjoy the project, consider giving it a ⭐ on GitHub.

Every star, issue, feature request, and contribution helps shape future releases.

Happy monitoring! 🚀

⚡ViteDash 2.2: I halved my dashboard bundle, right after doubling it

Muhammad Sheharyar Butt — Sat, 15 Aug 2026 21:12:19 +0000

I maintain ViteDash, a free admin dashboard template built with React 19, Vite 8, and Ant Design 6. It has a clean sidebar I am genuinely proud of, twenty something pages, and a light and dark mode that runs entirely through Ant Design's theme algorithm rather than a pile of CSS overrides.

It also shipped a single 1.6 MB JavaScript file and had a dependency it never declared.

Version 2.2 is out. Here is what was broken, what I added, and the one performance lesson that surprised me enough to write about.

🐛 The bug that made the template unusable for some people

@ant-design/icons was imported in 22 files. It was not in package.json.

It worked fine on my machine. It works fine for anyone using npm, because npm flattens node_modules and antd depends on the icons package, so the import resolves through a copy that happens to be sitting at the top level.

It does not work with pnpm. pnpm keeps a strict node_modules where a package can only import what it actually declared. Same story with Yarn PnP. Those users cloned the repo, ran install, ran dev, and got:

Failed to resolve import "@ant-design/icons"

My README told people to use pnpm. I had been shipping a template that a chunk of my audience could not start.

The fix is one line in package.json. The lesson is not. If you maintain anything that other people install, test the install with pnpm at least once. A transitive dependency you never asked for is not a dependency you have.

📦 The bundle: 1.6 MB in one file

The production build was one chunk:

dist/assets/index-BkAqHA3M.js   1,620,471 bytes

Everything. The sign in screen waited on the Kanban board, the invoice drawer, and all twenty something other pages before it painted.

The fix is the boring, correct one. Every route becomes a lazy import:

const Charts = lazy(() => import('@/pages/charts/Charts'));
const Products = lazy(() => import('@/pages/products/Products'));

with a Suspense boundary inside the shell rather than around it, so the sidebar and header stay on screen while the next page downloads:

<MainLayout>
  <ErrorBoundary resetKey={location.pathname}>
    <Suspense fallback={<PageLoader />}>
      <Outlet />
    </Suspense>
  </ErrorBoundary>
</MainLayout>

That part went exactly how you would expect. The next part did not.

⚠️ The chunking advice that made it worse

Search for "Vite bundle too large" and you will find the same answer over and over: split your vendor code by library with manualChunks. Group React here, antd there, charts somewhere else. Long term caching, smaller chunks, everyone wins.

So I wrote it:

manualChunks(id) {
  if (/node_modules\/(recharts|d3-)/.test(id)) return 'charts';
  if (id.includes('node_modules/@ant-design/icons')) return 'icons';
  if (/node_modules\/(antd|rc-|@rc-component)/.test(id)) return 'antd';
  if (/node_modules\/(react|react-dom|scheduler)\//.test(id)) return 'react';
  return 'vendor';
}

It looks tidy. It builds. The chunk list looks like a job well done.

Then I measured what the browser actually downloads before first paint, by reading the modulepreload tags out of the built index.html and adding up the files:

eager raw   : 2,086 kB
eager gzip  : 643 kB

Worse than shipping nothing at all. My route splitting had done its job, and my chunking config had undone it.

Here is why. manualChunks is a hard instruction, not a hint. When you say "every antd module goes in the antd chunk", the bundler obeys, including for the antd components that only the Kanban board imports. And a chunk is eager if any module in it is reachable from the entry. The app shell uses Layout, Menu, and Button, so the antd chunk is eager, so Table, Splitter, Calendar and everything else rides along.

Same story with Recharts. Only the Charts page imports it. Naming it as a chunk pulled it into the entry graph anyway, and 427 kB of chart library was downloading for people who never opened a chart.

I deleted the whole thing and let the bundler decide:

eager raw   : 1,004 kB across 12 files
eager gzip  : 336 kB

Half. From deleting configuration.

Automatic code splitting already knows what it is doing. A module reachable from the entry lands in the entry chunk. A module used by two lazy routes lands in a shared chunk that loads when either one does. A module used by one lazy route lands in that route's chunk. That is the behaviour you want, and manualChunks overrides it with your guess.

There are still good reasons to reach for it. If the analyzer shows one library genuinely duplicated across many chunks, group that library. But group it because you measured, not because a blog post said vendor splitting is good practice. I left this comment in vite.config.js so future me does not repeat it:

The obvious move is to group node_modules by library ("all of antd in one chunk"), and it is a trap. Measured on this app that grouping costs 643 kB gzipped on first load. Letting the bundler decide brings it down to 336 kB.

Final numbers:

	Before 2.2	After 2.2
First load, uncompressed	1,620 kB in one file	1,004 kB across 12 files
First load, gzipped	one chunk, everything	336 kB
Chart library	n/a	only on `/dashboard/charts`
Total JavaScript	1,620 kB	2,183 kB across 83 chunks

The total went up because the template gained charts, three locales, and seven pages. That is fine. What matters is that none of it loads until someone asks for it.

🔐 Roles, because a template without them teaches the wrong habit

Most free dashboard templates give you pages. Then you add your second user type and discover there is nowhere obvious to put that logic.

2.2 has role based access control in three layers.

The navigation tree declares who can see what:

{ to: '/dashboard/roles', labelKey: 'nav.items.roles', roles: [ROLES.ADMIN] },

The router enforces it for anyone who types the URL:

<Route element={<RequireRole roles={[ROLES.ADMIN]} />}>
  <Route path="roles" element={<Roles />} />
</Route>

And there is a Roles and Permissions page showing the matrix, so the concept is visible rather than buried in a config file.

One thing I made sure to write down in both the code and the security policy: none of this is security. It runs on the user's machine. It stops honest people from wandering into the wrong screen, and it stops nobody with the developer tools open. The same rules have to exist on your server. A template that implies otherwise is doing real damage to whoever learns from it.

🔌 A data layer you can actually replace

Every page used to hardcode its data in an array at the top of the file. Nobody ships that, so the template was teaching a pattern that gets deleted on day one.

Now everything that touches data lives in src/services/, and each function returns mock data in the shape a real endpoint would:

export const getProducts = async ({ search, category, page, pageSize }) => {
  await delay(500);
  // filtering, sorting, and paging happen here, the way a backend does them
  return { items, total, page, pageSize };
};

Swapping in a real API changes this file and nothing else:

export const getProducts = (params) => apiClient.get(`/products?${new URLSearchParams(params)}`);

The pages consume it through a small useAsync hook, so loading, error, and empty states are the default rather than something you bolt on later. The hook has one detail worth stealing:

const run = useCallback(async () => {
  const id = requestId.current + 1;
  requestId.current = id;
  // ...
  const result = await asyncFunction();
  if (id === requestId.current) setData(result);
}, [asyncFunction]);

That guard is why searching does not glitch. Without it, a slow response for "sh" can land after a fast one for "shoes" and quietly replace the newer results with the older ones. It is a two line fix for a bug that is miserable to reproduce.

The Products page has a switch that makes the request fail on purpose, so you can see the error path without unplugging your network.

🌍 Three languages, one of them right to left

English, Spanish, and Arabic, with the whole layout mirroring for Arabic.

The good news is that Ant Design does most of the work. Its ConfigProvider takes a direction prop and flips every component. The interesting part is everything that is not a component:

The layout had marginLeft pushing content past the sidebar. That becomes marginInlineStart, which follows the document direction.
The sidebar's box shadow points left. Physical, not logical, so it needs an explicit [dir='rtl'] override.
The active indicator's border radius is 0 3px 3px 0. Also physical. Also needs mirroring.
The mobile drawer's placement prop is physical. It has to be flipped by hand.
Recharts does not mirror at all. It lays axes out in document order, so inheriting RTL puts labels on the wrong side of a plot whose bars did not move. Every chart container is pinned to dir="ltr".

Adding a language is now one JSON file and one row in an array. If it is right to left, you set dir: 'rtl' and everything above already handles it.

📏 The 40px axis, which I still like best

This one is from the previous release, but it is the piece of the template I am fondest of, and it now has a test guarding it.

The sidebar collapses from 248px to 80px. In most dashboards the icons visibly jump sideways when that happens, because Ant Design positions menu icons with two unrelated formulas:

expanded  = itemMarginInline + inlineIndent + iconSize / 2
collapsed = collapsedWidth / 2

Nothing makes those equal. Unless you solve for it:

8 + 24 + 8  ===  80 / 2  ===  40

Every icon centre sits at exactly 40px in both states, so collapsing is pure clipping with no re-layout and no drift. There is now a test that fails if anyone breaks the identity, which felt like the right way to protect a number that looks arbitrary until you know why it is not.

Two traps if you ever tune it. inlineIndent is a Menu prop, not a theme token, because rc-menu writes padding-left as an inline style that beats every class rule. And collapsedIconSize must stay greater than or equal to iconSize, because Ant Design's collapsed rule overrides the icon's font-size but not its min-width.

✨ Everything else

Command palette on Ctrl+K, indexed from the navigation tree and filtered by role, so new pages are searchable with nothing to register
Theme customizer for primary colour, corner radius, and density, all through ConfigProvider tokens
Charts with a useChartTheme hook and a custom tooltip, because Recharts ships a white tooltip with a hardcoded border that looks broken the moment you switch to dark mode
Error boundaries, one global and one per route keyed on the pathname, so a page that throws leaves the shell usable and navigating away recovers
Seven new pages: Charts, Products, Roles, Notifications, Activity Log, Lock Screen, Maintenance
51 tests with Vitest, and npm run check runs lint, format, and tests together
Self hosted Inter instead of a Google Fonts link, which unblocks first paint, works offline, and stops sending visitor IPs to a third party
Deploy configs for Vercel, Netlify, and Docker with nginx

🙅 What I left out on purpose

The most common feedback on a template like this is "add TypeScript". I did not, and I want to say why.

ViteDash is a lot of people's first React project. Plain JSX means every file can be read top to bottom without also knowing generics, utility types, and how to type a component that takes children. I added a jsconfig.json so you still get autocomplete and path aliases in your editor, and left the type layer to whoever wants it.

Same reasoning for TanStack Query, MSW, Storybook, and a state management library. Each one is a good tool and each one is another concept between a beginner and a working dashboard. The useAsync hook is 45 lines and teaches the same lesson with zero dependencies.

Small on purpose is a feature. It is also the thing most likely to get me argued with, and I am fine with that.

🚀 Try it

Demo: vitedash.msyb.dev
Source: github.com/shehari007/vitedash-vite-antd-dashboard-template

npx degit shehari007/vitedash-vite-antd-dashboard-template my-dashboard
cd my-dashboard
npm install
npm run dev

MIT licensed. Issues and pull requests welcome, and beginner questions are explicitly welcome too. That is who it is for.

If you take one thing from this post, make it the boring one: measure what the browser downloads before first paint, not what the build log prints. Those are different numbers, and I had been reading the wrong one for a year.

⚡Building AppBox: 36 Tools, One Tab

Muhammad Sheharyar Butt — Sat, 15 Aug 2026 21:08:54 +0000

36 Tools, One Tab: Building AppBox

I had a bookmarks folder called utils. Thirty-something links to single-purpose
websites: a percentage calculator, a JSON prettifier, a JWT decoder, a cron expression
parser. Every one of them worked. Every one of them also shipped several megabytes of
ads, a cookie banner, three analytics scripts, and a newsletter modal that appeared
exactly when I pasted my token into the box.

That last part is the one that bothered me. I was pasting things I should not have been
pasting into pages I had never read the privacy policy of.

So I deleted the folder and built AppBox 36 utilities in one
app, no ads, no analytics, no account, and every calculation running on your own device.

The constraint that shaped everything

Here is the whole design brief: the app should work with the network cable unplugged.

That sounds like a feature. It is really a filter. Once "must work offline" is
non-negotiable, a lot of decisions stop being decisions:

No analytics, because there is nobody to send events to.
No account system, because there is no server to hold accounts.
No CDN fonts, no third-party embeds, no remote config.
Your data lives in localStorage, on your machine, and never leaves it.

34 of the 36 tools honour this absolutely, because there is genuinely nothing they need a
server for. Converting 40 °C to Fahrenheit is arithmetic. Hashing a string is arithmetic.
Parsing */15 9-17 * * 1-5 into "every 15 minutes, 9am–5pm, weekdays" is a
string-processing problem someone solved decades ago.

The two exceptions are weather and currency. Both use free, key-less APIs, both cache
their last successful response, and both show you how old that cached result is instead
of pretending it is live. On a train, you still get something useful.

One codebase, two very different targets

AppBox ships as a static website and as a native desktop app for Windows, macOS and
Linux. Same UI code, same logic, two builds.

src/                  Next.js 16 App Router — the renderer
├─ app/               one route per tool, ~8 lines each
├─ components/        tools, UI primitives, hand-rolled SVG charts
├─ lib/               domain logic, framework-free and unit-testable
└─ types/             the IPC contract, shared by preload and renderer

electron/             compiled by Vite → dist-electron/
├─ main.ts            window, app:// protocol, IPC, hardening
├─ preload.ts         the only bridge into the renderer
└─ menu.ts            native menu, generated from the registry

out/                  next build → Vercel  AND  → Electron over app://

People sometimes ask why there are two bundlers in one repo. They do different jobs and
never overlap. Next.js builds the interface, and its output: 'export' mode emits
real HTML per route — which is what gives each tool its own <title>, meta description,
canonical URL and JSON-LD. The previous version of this project was a single
client-rendered page, and it simply could not have that. Vite compiles the Electron
main and preload processes from TypeScript. It never touches the UI.

A registry as the single source of truth

src/lib/tools.ts holds every tool's slug, name, description, category, keywords and
icon. Reading from that one array: the sidebar, the home grid, the command palette, the
native desktop menu, sitemap.xml, the PWA shortcuts, and every route's metadata.

Adding a tool is one registry entry plus one eight-line route file. Navigation, search,
the desktop menu, the sitemap and the SEO tags all pick it up on their own. There is no
checklist of six files you must remember to touch — which matters, because the version of
me who adds tool number 37 will not remember the checklist.

Four decisions I would defend in code review

1. No charting library

The finance and health tools needed charts. Recharts would have added roughly 100 KB to
routes whose entire selling point is loading instantly.

AppBox needs four chart shapes. Four. So components/charts/ is about 500 lines of
inline SVG, and that is the end of it. The series colours are a fixed, colourblind-checked
three-slot palette, deliberately kept independent of the per-tool accent colour — so
"the green line" always means the same thing whether you are looking at a loan
amortisation schedule or a calorie breakdown.

2. No mathjs

The scientific calculator needs to evaluate expressions. mathjs does that beautifully,
in about 500 KB.

lib/expression.ts is a tokeniser plus a shunting-yard evaluator — a few hundred lines —
handling degree/radian trig, postfix factorial and implicit multiplication. The size win
is nice. The real win is error messages: because I own the parser, a malformed expression
produces something specific enough to show the user, instead of a generic library throw.

3. MD5, written by hand

Web Crypto deliberately excludes MD5, and it is right to. But verifying a downloaded ISO
against a published checksum is exactly the legacy case people still hit, and telling
them "use a different algorithm" does not help when the checksum on the vendor's page is
MD5.

So it is implemented from scratch and fuzz-checked against Node's crypto across 139
inputs. Not glamorous. Correct.

4. Rendered Markdown gets sanitised

marked passes raw HTML straight through by default. Both the Markdown preview tool and
the Notes tool run their output through DOMPurify before it reaches the DOM. In an app
with no server, XSS is still absolutely a real problem — the attacker just has to get you
to paste something.

The Tailwind v4 bug that cost me an evening

Every category has its own accent colour. A tool sets one data-accent attribute and
everything inside inherits that palette through CSS custom properties, so no tool
component ever names a colour directly.

This needs @theme inline in Tailwind v4. With a plain @theme, the substitution is
frozen at :root — so every tool dutifully renders in exactly the same colour and you
spend an hour convinced your data attributes are not applying. They were. One keyword.

Hardening the desktop build

The Electron renderer runs with contextIsolation: true, nodeIntegration: false and
sandbox: true. It reaches the host only through the narrow, typed surface in
electron/preload.ts.

The packaged app is served from a registered app:// scheme rather than file://. That
gives it a stable origin, which means localStorage, history.pushState and fetch
behave exactly the way they do on the web — so the desktop build is not quietly a
different application with different bugs.

One deployment gotcha, in case you hit it

Vercel's Next.js preset understands output: 'export' on its own. vercel.json only adds
what the framework does not: cache headers and a CSP matching the desktop one.

Do not set outputDirectory to out. It reads as "look for the Next build in
out/", and the deploy fails with a missing routes-manifest.json — that file lives in
.next/, which is exactly where the preset was already looking.

Any static host works too:

npm run build
npx serve out

What I would tell past me

Pick the constraint first. "Works offline" did more architectural work than any framework
choice I made, because it answered a dozen questions before I got around to asking them.

And put the registry in early. Every project accumulates a mental list of files you must
update in lockstep, and every one of those lists eventually gets something wrong. Turning
that list into one array is not clever. It is just the thing that lets a side project
survive being ignored for three months.

Try it

Live: appbox.msyb.dev
Source: github.com/shehari007/appbox-multi-toolkit
Desktop builds: Windows (NSIS), macOS (DMG), Linux (AppImage + .deb)

MIT licensed. Issues and pull requests welcome — and if you add a tool, the sidebar,
search, menu and sitemap will find it without you asking.

🍬 Candy Logger v2.1.0 - The Correctness Release

Muhammad Sheharyar Butt — Sat, 15 Aug 2026 21:06:00 +0000

Candy Logger v2.1.0 is now available.

This release focuses on making Candy Logger correct, secure, reliable, and production-ready.

Version 2.1.0 improves serialization, security, console interception, persistence, UI behavior, accessibility, mobile support, and the underlying architecture. It also introduces a cleaner core API that allows Candy Logger to be used without rendering the UI.

What Is Candy Logger?

Candy Logger is a lightweight JavaScript and TypeScript logging library that provides a visual debugging experience directly inside your application.

Instead of relying entirely on:

console.log()
console.warn()
console.error()

Candy Logger provides a structured logging interface with:

🔎 Search and filtering
🏷️ Tags
📊 Log levels and counters
📌 Pinned entries
🧩 Structured object inspection
📦 JSON export
🎨 Themes
📱 Mobile support
♿ Accessibility features
🔌 Custom sinks
💾 Persistent logs
🛡️ CSP-safe UI
⚡ Dynamic UI loading

The goal is simple:

Make application logging easier to understand without turning your project into a heavy logging framework.

Why Version 2.1.0?

The previous versions of Candy Logger focused primarily on building the logging experience.

Version 2.1.0 focuses on what happens when real applications start sending real-world JavaScript values and runtime conditions to the logger.

Circular objects.

Errors.

Maps.

Sets.

DOM nodes.

BigInts.

Symbols.

Strict Content Security Policies.

React StrictMode.

Hot Module Replacement.

Corrupted localStorage.

Touch devices.

Large log volumes.

These edge cases expose whether a developer tool is actually robust.

That's why version 2.1.0 is a correctness release.

What's New in 2.1.0

Safer Object Serialization

Logging should never break the application being debugged.

Previously, circular objects could cause a TypeError to escape into the calling code.

For example:

const circularObject = {};

circularObject.self = circularObject;

console.log(circularObject);

Candy Logger 2.1.0 safely handles circular references instead of allowing them to crash the logging operation.

Better Error Serialization

JavaScript Error objects contain valuable debugging information that isn't always enumerable.

Previously:

console.error(new Error("Something went wrong"));

could effectively render as:

{}

Version 2.1.0 properly serializes:

message
stack
cause
Custom Error properties

For example:

const error = new Error("Database connection failed", {
  cause: new Error("Connection timeout")
});

error.code = "DB_CONNECTION_FAILED";

console.error(error);

Candy Logger can now display the information developers actually need when diagnosing failures.

More JavaScript Types

The serializer has been expanded to safely handle a much wider range of JavaScript values.

Candy Logger 2.1.0 supports serialization of:

Map
Set
Date
RegExp
BigInt
Symbol
Functions
DOM nodes
Circular objects
Error objects

This means developers don't have to manually convert everything into plain JSON before logging it.

Security and XSS Protection

Security is one of the most important parts of this release.

Version 2.1.0 addresses XSS risks involving dynamically rendered values such as:

Object keys
Tag labels
Tag colors
Log levels
Custom action labels

For example:

console.log({
  "<img src=x onerror=alert(1)>": "test"
});

The value is treated as data rather than executable HTML.

This makes the logging interface significantly safer when handling dynamically generated or untrusted values.

Strict CSP Support

Candy Logger 2.1.0 is fully functional under a strict Content Security Policy.

The panel no longer relies on inline handlers such as:

onclick="..."

and no longer depends on:

window.__candy*

global variables.

UI interactions are handled through proper event listeners and encapsulated runtime behavior.

Idempotent Console Override

Modern development environments can execute initialization code more than once.

React StrictMode and Hot Module Replacement are common examples.

Previously, repeatedly calling:

overrideConsole();

could result in stacked panels or duplicated logs.

Version 2.1.0 makes overrideConsole() idempotent.

Calling it multiple times no longer creates additional interception layers.

overrideConsole();
overrideConsole();
overrideConsole();

The console remains correctly overridden.

Safer Console Restoration

restoreConsole() has also been improved.

It can no longer leave the browser's console permanently hijacked after restoration.

overrideConsole();

// Application code

restoreConsole();

The original console behavior is properly restored.

Accurate Log Counters

maxLogs previously caused level counters to drift upward indefinitely.

For example, even after old entries had been evicted, counters could continue increasing.

Version 2.1.0 keeps the counters synchronized with the actual core store.

Pinned Logs

Pinned logs are now exempt from normal log eviction.

If:

maxLogs: 100

is configured, pinned entries remain available even after the limit is reached.

The same behavior applies to:

clear();

Pinned entries are preserved instead of being silently removed from localStorage.

Improved Search

Search now matches text inside collapsed objects.

Previously, searching depended on the rendered DOM, which meant content inside collapsed objects could be missed.

Now the search operates against the underlying serialized data.

For example:

console.log({
  user: {
    profile: {
      email: "developer@example.com"
    }
  }
});

The email can be found even while the object remains collapsed.

Improved JSON Highlighting

JSON rendering has also been improved.

Version 2.1.0 correctly highlights:

Keys
Strings
Values

Apostrophes are also rendered correctly instead of appearing as:

&#039;

Improved Light Theme

The light theme now defines its own level badge colors.

Previously, some level badges had poor contrast, reaching approximately 1.6:1 in certain cases.

Version 2.1.0 improves the contrast and readability of the light theme.

Mobile and Touch Support

Candy Logger now provides a dedicated mobile experience.

On screens below 640px, the panel becomes a full-screen sheet.

Dragging also works with touch through pointer events, with the panel automatically clamped to the visible screen.

Accessibility Improvements

Version 2.1.0 includes an accessibility pass covering:

Accessible names
aria-pressed
Live regions
Focus rings
Reduced-motion support

The goal is to make the debugging interface usable with different input methods and accessibility settings.

New APIs

`destroy()`

Both the logger and panel now support:

destroy();

This removes:

DOM elements
Event listeners
Injected stylesheets

This is useful when loggers are dynamically mounted and unmounted.

`captureConsole()`

captureConsole() allows console output to be routed into an existing logger without replacing the entire logging architecture.

const logger = createLogger();

const dispose = captureConsole(logger);

// console.log()
// console.warn()
// console.error()

dispose();

The function returns a disposer for clean lifecycle management.

`addSink()`

Logs can now be piped into external systems using sinks.

logger.addSink((entry) => {
  // Send entry to your backend
});

This makes integrations with services such as:

Sentry
Custom APIs
Monitoring systems
Analytics platforms
Test spies

much easier.

Core Logger API

Version 2.1.0 introduces a cleaner core API:

createLogger()
attachUI()
detachUI()
showPanel()
hidePanel()
isConsoleOverridden()

This separates the logging core from the visual panel.

The logger can therefore be used without rendering the UI.

Console Format Specifiers

Candy Logger now supports common console formatting specifiers:

%s
%d
%i
%f
%o
%O
%j
%c
%%

For example:

console.log(
  "User %s has %d points",
  "Muhammad",
  100
);

This makes Candy Logger behave more naturally when capturing or replacing native console output.

Better Scrolling

The panel now uses sticky-bottom scrolling.

If you're already at the bottom, new entries keep you at the bottom.

If you've intentionally scrolled upward, new logs don't force you back down.

Instead, Candy Logger displays an:

N new

indicator.

You can then decide when to return to the newest entries.

Exported Serializer Primitives

Developers can now use Candy Logger's serialization utilities independently.

The following primitives are exported:

safeStringify
normalize
serializeError
formatArgs

This makes the serialization system useful outside the panel itself.

New Configuration Options

Version 2.1.0 introduces several configuration options:

retainArgs
persistPins
dimWhenIdle
maxDepth
maxString

These provide more control over memory usage, serialization depth, persistence, and panel behavior.

The panel is now opaque by default.

The previous dimmed behavior can be enabled using:

dimWhenIdle: true

Build Formats

Candy Logger now provides:

ESM
CJS
IIFE

CDN builds are also available through:

unpkg
jsDelivr

This allows Candy Logger to be used directly with a script tag:

<script src="https://unpkg.com/candy-logger"></script>

without requiring a bundler.

Testing

Version 2.1.0 includes 118 tests.

The tests cover important areas including:

Serialization
Console interception
Restoration
Persistence
Log limits
Pinned entries
UI behavior
Edge cases
Configuration behavior

The goal is not just to add functionality, but to make that functionality predictable.

Architecture Improvements

One of the most important changes in 2.1.0 is the separation between the logging core and the visual panel.

Core Store

These methods now read directly from the core store:

getLogs()
getStats()

They work even when no panel is attached.

For example:

const logger = createLogger();

logger.log("Hello");

console.log(logger.getLogs());
console.log(logger.getStats());

Dynamic Panel Loading

The panel is now dynamically imported.

This allows bundlers to remove the panel code from builds where the UI is never enabled.

The architecture is effectively:

Application
    │
    ├── Logger Core
    │
    └── Optional Panel

The visual interface is now an optional presentation layer rather than a mandatory part of the logging core.

Removed Legacy Code

Version 2.1.0 removes unnecessary legacy functionality.

Removed `tableView`

The tableView option has been removed because there was no alternative view.

Removed v1 Terminal UI

The old:

terminal-ui.ts

implementation from v1 has also been removed.

Candy Logger 2.x is now focused entirely on the newer architecture.

Backward Compatibility

Candy Logger 2.1.0 maintains compatibility with the important v2 APIs.

The following continue to work:

overrideConsole()
restoreConsole()
candy
CandyLogger
tagged()
getLogs()
getStats()

All v2.0 options continue to work except:

tableView

The existing:

forceUI

option is also still accepted as an alias for:

enabled

Installation

Upgrade to version 2.1.0 with:

npm install candy-logger@2.1.0

Or install the latest release:

npm install candy-logger

Getting Started

A basic setup remains simple:

import { overrideConsole } from "candy-logger";

overrideConsole({
  enabled: true
});

You can then continue using the native console API:

console.log("Application started");

console.info("User authenticated");

console.warn("Cache is getting full");

console.error(new Error("Something went wrong"));

Candy Logger handles the rest.

What's Next?

Candy Logger 2.1.0 establishes a stronger foundation for future development.

Future improvements can build on:

A separated logging core
Safer serialization
Extensible sinks
Better lifecycle management
Optional UI loading
Improved accessibility
Better mobile behavior
Stronger test coverage

The goal is to keep Candy Logger lightweight while making it increasingly useful as a developer tool.

Final Thoughts

Candy Logger 2.1.0 isn't defined by one huge feature.

Instead, it is a collection of improvements that make the entire library more reliable.

Better serialization.

Better security.

Better console interception.

Better persistence.

Better accessibility.

Better mobile behavior.

Better architecture.

And 118 tests helping make sure those improvements continue working.

That's why I consider 2.1.0 the correctness release.

🍬 Candy Logger — because debugging doesn't have to be boring.

Rebuilding BICO v3.0.0 from scratch: worker threads, GPU shaders, and a contrast formula that got it wrong

Muhammad Sheharyar Butt — Sat, 15 Aug 2026 21:02:57 +0000

Rebuilding BICO from scratch

BICO is a desktop app that
converts and optimises images in bulk. Everything runs on your machine and nothing is uploaded.

Version 2 worked, and I used it. It also had a problem I could not design around: the interface
froze during every batch. Version 3 is a full rewrite, and this is what the rewrite actually
involved, including the two bugs that taught me the most.

Download it ·
Source

The freeze was architectural

In version 2, sharp ran on the renderer thread. Every conversion
competed with the thing drawing the window, so the app stopped repainting for the length of a batch.
No amount of spinners fixes that, because there is no thread left to animate the spinner.

Version 3 moves encoding into a pool of native worker threads sized to the machine, off both the UI
thread and the main process. The window now stays at full frame rate through a run, and the queue
shows per file progress because there is a thread free to report it.

That single change is most of why the app feels different, and it is not a feature anybody sees in a
screenshot.

Putting the GPU to work without pretending

Image codecs are CPU bound. A GPU cannot encode a JPEG for you. What it can do is the parts that
genuinely parallelise: resize, sharpen, blur, colour adjustments, watermark compositing.

BICO runs those as WebGPU compute shaders. Machines with a discrete
and an integrated adapter can drive both at once, each on its own lane. On an NVIDIA card that work
executes on the CUDA cores.

Two decisions matter more than the shaders:

Fallback is silent and automatic. Any device loss, driver reset or unsupported operation moves
that image to the CPU pipeline. A converter that fails because a driver hiccupped is worse than one
that is briefly slower.

The app tells you where each file ran. Every row in the queue carries a GPU or CPU badge, and the
run summary shows the split. If I claim acceleration, you get to check it.

Shipping codecs that libvips does not have

I wanted JPEG XL and JPEG 2000. No prebuilt copy of libvips includes
either, and asking users to compile a custom libvips is not a real answer for a desktop app.

So BICO carries its own WebAssembly builds: @jsquash/jxl
for JPEG XL and ImageMagick compiled to WASM for
JPEG 2000. They cost a few megabytes and behave identically on Windows, macOS and Linux.

I tested ImageMagick for JPEG XL too, since it was already there. It produced larger files at
higher quality settings, which is inverted, so JPEG XL kept its own encoder. Measuring beats
assuming, and it took one afternoon to find out.

The About screen reports what your build actually resolved at startup rather than what the formats
support in theory, and anything unavailable is greyed out in the picker instead of failing mid run.

The contrast formula that got it wrong

Here is my favourite bug.

BICO lets you pick any accent colour, so it has to choose black or white text to sit on top. I did
the responsible thing and used the WCAG 2 contrast ratio, picking whichever scored higher.

On the default blue, #4c8dff, it chose black. It looked awful.

The maths was not wrong, it was just measuring the wrong thing:

black on #4c8dff   6.56 : 1
white on #4c8dff   3.20 : 1

WCAG 2 relative luminance weights green at 0.7152 and blue at 0.0722. A saturated blue therefore
scores as a light colour, and black wins the ratio test on it. Every mainstream design system puts
white on a blue button, and every one of them is right.

APCA, the perceptual model drafted for WCAG 3, gets it right:

white on #4c8dff   Lc 64.2
black on #4c8dff   Lc 45.2

So the foreground is now chosen perceptually. But fixing that surfaced a second, better bug.

Ant Design paints all three button states with one text colour and three different backgrounds,
and its hover shade is lighter while its pressed shade is darker. On the Nord and Dracula themes the
pressed shade landed dark enough that the black text chosen for the resting colour was stranded on a
mid tone.

The fix was to stop letting the shades drift: hover and pressed are now generated in
Oklab, moving lightness while keeping hue and chroma, and
always away from the text colour. Contrast rises as you interact with a button rather than falling.

Then a third thing. The rendered button was not even the colour I was checking. Ant Design's dark
algorithm regenerates the seed against a dark background, so #4c8dff goes in and #447bdc is
painted. I had been judging a colour that never reached the screen, which is what left Nord and
Dracula at a genuinely poor Lc 52 and 45.

I verified the final version across every accent the colour picker can produce: 24,389 colours by
three states, 73,167 measurements, zero states where the text colour disagrees with the
background it is painted on.

Three bugs stacked on one wrong assumption, and the only reason I found the second and third is that
I measured the rendered DOM instead of trusting the theme config.

The installer that installed twice

The other bug worth writing down.

Version 3 changed the application id. Windows keys its uninstall entry on a GUID derived from that
id, so as far as Windows was concerned, version 3 was an unrelated product. Installing it left two
BICOs: two entries in Apps and Features, two Start Menu shortcuts, two program folders, neither
aware of the other.

The tempting fix is a custom uninstall script. The better fix was smaller: electron-builder already
has a tested routine that finds a previous install, runs its uninstaller with retries, handles the
app being open, and only then writes the new files. It just never fired, because it looks up the
current id's GUID.

Pinning the installer's GUID back to the one version 2 registered under makes that existing machinery
do the work. One line of configuration instead of a hundred lines of NSIS I would have had to debug
on a virtual machine.

The lesson I keep relearning: before writing the thing, check whether the tool already does it and
you have simply not given it what it needs.

Making the interface speak three languages

BICO ships in English, Turkish and Arabic, and Arabic flips the whole layout to right to left. Not a
mirrored font, an actual mirror: panels, tables, sliders and drawers all change side.

The part I would recommend to anyone doing this: the dictionaries are typed. Every language is
declared as Record<TranslationKey, string>, so a string added in English fails the build until
Turkish and Arabic supply it. Nothing can quietly fall back.

That caught a real bug months later. The format descriptions were being rendered straight from a
capability table in shared code rather than from the dictionaries, so they stayed English in both
translations and sat outside the contract entirely. The moment I moved those words into the
dictionaries, the build broke with missing 18 properties, which is exactly what should happen.

Cutting the words back out

Late on, I read the settings sidebar as a user rather than as its author, and it was exhausting.
Every slider carried a paragraph explaining why the setting existed.

Higher effort means smaller files and slower encoding. The image itself is unchanged, the encoder
just searches harder for a cheaper way to store it.

That is 149 characters for one slider. It is now:

Higher effort means smaller files and slower encoding.

Across the interface the helper text went from roughly 26,000 characters to 15,800, and the sidebar
average dropped from 117 characters a hint to 69. The facts and the warnings stayed. The reasoning
went, because a hint is read while you are trying to do something else, not studied.

What version 3 is made of

Electron 43, React 19, TypeScript 5.9, Ant Design 6, sharp on libvips 8.18,
built with electron-vite. Node integration is gone from the renderer,
context isolation is on, and every path the interface touches crosses a typed IPC contract compiled
by all four processes.

The interface is set in IBM Plex, bundled rather than fetched, chosen
because its Arabic is a designed companion to the Latin rather than an unrelated fallback face.

Try it

Download: releases for Windows, macOS and Linux
Source and issues: github.com/shehari007/BICO
Me: github.com/shehari007

It is MIT licensed. If you convert images in bulk and something annoys you about it, open an issue.
The bugs above were all found by being annoyed at my own software and then actually measuring why.

🩺 MD Doctor - A Modern Open-Source Markdown Editor Built with Next.js 16 & React 19

Muhammad Sheharyar Butt — Mon, 06 Jul 2026 08:33:41 +0000

I built MD Doctor, a professional Markdown workspace designed for developers, technical writers, students, and anyone who loves writing in Markdown.

Unlike many editors, MD Doctor uses a custom editor built from scratch instead of Monaco, CodeMirror, or TipTap, giving complete control over the editing experience while remaining lightweight and fast.

✨ Features

📝 Custom Markdown editor built from scratch
⚡ Live GitHub-Flavored Markdown preview
📊 Mermaid diagram support
➗ KaTeX mathematical expressions
💻 Syntax-highlighted code blocks
📄 Import Markdown and HTML (HTML is converted to Markdown)
📤 Export to Markdown, standalone HTML, and PDF
🔒 Offline-first with IndexedDB storage
🌍 English, Türkçe, العربية, and اردو with full RTL support
🎨 Built with Next.js 16, React 19, Material UI v9, Motion, and TypeScript

🔗 Links

🌐 Live Demo: https://mddoctor.msyb.dev

📦 GitHub Repository: https://github.com/shehari007/md-doctor-next-js

👤 GitHub Profile: https://github.com/shehari007

If you try it out, I'd love to hear your feedback. Feature requests, bug reports, and pull requests are always welcome!

nextjs #react #typescript #opensource #markdown #webdev #frontend #materialui #javascript #developer

⚡Stop Building Admin Dashboards from Scratch Meet ViteDash

Muhammad Sheharyar Butt — Wed, 01 Jul 2026 11:23:15 +0000

🚀 Just udpated ViteDash a modern, lightweight Admin Dashboard Template built for developers who want to prototype, build, and ship faster.

Instead of starting every project from scratch, ViteDash gives you a clean, responsive foundation with everything needed to kick off your next application.

✨ Built with:

⚛️ React 19
⚡ Vite 8
🎨 Ant Design 6

Features

✅ Fully Responsive Layout
✅ Light & Dark Mode
✅ Authentication Pages (Sign In, Sign Up & Forgot Password)
✅ Dashboard, Analytics, Tables, Forms, Users, Profile & Settings Pages
✅ Reusable Components
✅ Clean & Scalable Project Structure
✅ Minimal Dependencies
✅ TypeScript Ready

Perfect for building:
• Admin Panels
• SaaS Dashboards
• ERP & CRM Systems
• Internal Business Tools
• Management Portals

🌐 Live Demo
https://vitedash.msyb.dev

💻 GitHub
https://github.com/shehari007/vitedash-vite-antd-dashboard-template

If you're looking for a fast starting point for your next React project, give it a try. Feedback, feature requests, and GitHub ⭐️s are always appreciated!

React #Vite #AntDesign #Dashboard #AdminTemplate #OpenSource #TypeScript #Frontend #WebDevelopment #ReactJS #JavaScript #UI #Developer

🚀 Candy Logger v2 is here — a browser logger with a real UI

Muhammad Sheharyar Butt — Sat, 28 Mar 2026 17:20:27 +0000

I just shipped Candy Logger v2 — a major rewrite of my JavaScript/TypeScript logging library.

Candy Logger is now a browser-first logger with a floating UI that makes debugging much easier during development. Instead of just printing plain console messages, v2 gives you a structured table view, tagged logs, color-coded levels, real-time search/filtering, dark/light theme support, JSON export, and draggable/resizable UI controls. It is also zero-dependency. (GitHub)

One important change in this release: v2 is browser-only. I removed the old Node.js / terminal support, so if you still need the legacy terminal experience, v1.x is the version to stay on. This release is focused on giving frontend developers a much better in-browser debugging workflow. (GitHub)

What’s new in v2?

Complete browser-focused rewrite
New table-view logger UI
Custom tagged logging
6 color-coded log levels
Per-row actions like copy, bookmark, and delete
Real-time search and filtering
Dark / light theme toggle
JSON export
Pin, drag, and resize support
Collapsible JSON previews
TypeScript support
Works with React, Vue, Angular, Svelte, and Next.js client-side setups (GitHub)

Quick example

import { overrideConsole } from 'candy-logger';

overrideConsole({ forceUI: true });

console.log('Hello World!');
console.info('User signed in', { userId: 123 });
console.warn('Disk usage > 90%');
console.error('Payment failed', { code: 'CARD_DECLINED' });

That is basically it — once enabled, your browser logs become much more visual and easier to inspect. (GitHub)

Why I made this

A lot of logging tools are either too minimal, terminal-focused, or not pleasant to use when debugging frontend apps. I wanted something lightweight but still practical: something that feels modern, looks clean, and helps organize logs instead of turning them into noise.

Candy Logger v2 is my attempt to make browser debugging more usable and a bit more fun.

Try it

GitHub: shehari007/candy-logger
npm: candy-logger
Version: 2.0.0 (GitHub)

I’d really appreciate feedback, feature ideas, and stars on the repo.
If you try it in one of your projects, let me know what you think.

🚀 Arduino Live System Monitor Using Node.js (jhonny-five)

Muhammad Sheharyar Butt — Fri, 02 Jan 2026 09:09:31 +0000

Arduino Live System Monitor Using Node.js

A small hobby project that connects Node.js with Arduino UNO R3 to display live system statistics on an I2C LCD module.

The entire project is written in pure JavaScript, using Johnny-Five for serial communication and Standard Firmata on the Arduino side.

The goal is to provide a lightweight, hardware-based system monitor that runs independently of any desktop UI.

Features

CPU usage (%)
Memory usage (%)
Download speed (MB/s)
Upload speed (MB/s)
Automatically detects the active network adapter
Live updates via serial communication

Screenshot

Motivation

Most system monitoring tools are software-based and tied to the operating system UI.

This project explores a different approach by moving system metrics to a physical display, controlled entirely through JavaScript.

It also demonstrates:

Using JavaScript for hardware control
Real-time serial communication with Arduino
Practical usage of Johnny-Five beyond basic LEDs and sensors

Tech Stack

Node.js (>= 18, LTS recommended)
Johnny-Five
Arduino UNO R3
Standard Firmata
I2C LCD Module
PCF8574T I2C Controller (configurable)

Requirements

Node.js 18 or higher
Arduino UNO R3 with Standard Firmata flashed https://www.instructables.com/Arduino-Installing-Standard-Firmata/
I2C LCD Module
PCF8574T I2C Controller (Controller address can be changed in index.js)

Possible Improvements

GPU usage support
Temperature and fan speed monitoring
Support for other boards (Mega, Nano, ESP32)
Configurable refresh intervals
Multi-page LCD views

Source Code

Link

Contributions and improvements are welcome.

Running Locally

Connect the Arduino to your PC via USB
Install dependencies and start the app:


bash
npm install && node index.js

🚀 AppBox — An Open, All-in-One Utility Toolbox (React + Electron)

Muhammad Sheharyar Butt — Thu, 18 Dec 2025 13:47:24 +0000

As developers, we constantly rely on small utility tools — calculators, converters, timers, clocks, quick todos, weather checks. Most of them live as separate apps or browser tabs.

AppBox is an attempt to bring all of those everyday utilities into one extensible, open-source application — and more importantly, to make it easy for others to contribute new utilities and grow it into a true all-in-one toolbox.

🔗 Live demo (web preview):

Link

🔗 GitHub repository:

Link

What is AppBox?

AppBox is a modern utility suite built with React, Ant Design, and Electron.

It runs as:

🖥 A desktop app (Windows / macOS / Linux)
🌐 A web app, using the same codebase

The idea is simple:

One app. Many small tools. Easy to extend.

Why AppBox?

Most utility apps try to do everything themselves. AppBox takes a different approach:

Each utility is self-contained
New utilities can be added without touching the core logic
No backend required — everything persists locally
Designed to grow over time with community contributions

AppBox is not “finished” — it is intentionally open-ended.

Current Utilities

🧮 Calculator

Basic and scientific modes
Calculation history
Full keyboard support

🔁 Converters

Length, weight, temperature, speed
Time, storage, area, volume
Instant conversion with unit swapping

✅ Todo List

Add, complete, delete tasks
Filters: all / active / completed
Clear completed or reset all
Local persistence

⏱ Clock & Timer

Digital clock
Stopwatch
Countdown timer

🌍 World Clock

Add and remove cities
Multi-timezone overview
Persisted locally

☁️ Weather

City-based weather lookup
Configurable API key
Saved default city

The Vision: A True All-in-One Toolbox

The real goal of AppBox is not the current feature list — it’s what can be added next.

Examples of future utilities that would fit perfectly:

Password generator
UUID / hash generator
JSON / JWT viewer
Color picker & palette tools
Regex tester
Markdown previewer
Notes or scratchpad
Developer-focused utilities

If it’s a small, useful tool, it belongs in AppBox.

Contributing New Utilities 🚀

Contributions are highly encouraged — especially new utility modules.

You don’t need to refactor the app or understand everything to contribute:

Utilities are UI-driven and isolated
Most contributions can live in their own component/page
State is local and persistence is simple (localStorage)
No backend or database required

If you have ever built:

a small React tool,
a side utility,
or a “weekend project” feature,

…it can probably be added to AppBox.

How to Contribute

Fork the repository
Create a new utility module/page
Register it in the navigation
Submit a pull request

Even small utilities are welcome.

Tech Stack

Frontend: React 19
UI: Ant Design 6
Desktop: Electron
Math utilities: mathjs
Build & packaging: react-scripts, electron-builder

Running the Project

Clone the repo:


bash
git clone https://github.com/shehari007/mini-react-electron-desktop-app.git
cd mini-react-electron-desktop-app
npm install

🚀 Shorty URL — A Modern, Secure URL Shortener Built with React & Express (New Release)

Muhammad Sheharyar Butt — Mon, 15 Dec 2025 07:29:17 +0000

I’m excited to introduce Shorty URL, a modern full-stack URL shortener designed for real-world use. The goal of this project was to go beyond basic link shortening and deliver a secure, analytics-driven, and visually polished experience.

Shorty focuses on performance, security, and usability while maintaining a clean and scalable architecture.

✨ Features

🔗 URL Shortening — Create short, memorable links instantly
📱 QR Code Generation — Download QR codes for any shortened link
📊 Link Analytics — Track clicks, unique visitors, and performance metrics
🌙 Dark Mode — Elegant light and dark themes
🔒 Security Built-In
HTTPS-only URL validation
Rate limiting to prevent abuse
Full input sanitization
📝 Link History — Local storage–based history of created links
🚨 Report System — Report suspicious or malicious URLs
📧 Contact Form — Built-in contact functionality
📱 Responsive Design — Works seamlessly on desktop and mobile

🌐 Live Demo

Frontend: https://shorty.msyb.dev

🛠️ Tech Stack

Frontend
React 19
React Router 7
Ant Design 6
CSS3
Backend
Node.js
Express
MySQL

Security & Infrastructure

Helmet.js for secure HTTP headers
API rate limiting
CORS with origin whitelisting
Input validation and sanitization
SQL injection and XSS protection

Deployment

Vercel with serverless-ready architecture

🧩 Architecture Overview

The project is split into two clear layers:

A React-based frontend responsible for UI, theming, routing, and user interactions

An Express-based backend handling URL generation, redirection, analytics, reporting, and security enforcement

This separation keeps the system scalable, maintainable, and easy to extend.

📡 API Capabilities

URL creation and redirection
Global and per-link analytics
QR code tracking
Contact submissions
Malicious link reporting
Health monitoring

🔒 Security First Approach

Security was a primary focus while building Shorty:

Strict HTTPS validation for all URLs
Rate limiting to mitigate abuse
Sanitized inputs across all endpoints
Parameterized database queries
Hardened HTTP headers and controlled CORS access

🔗 Open Source

The project is fully open source and available on GitHub:
Link

📌 Final Notes

Shorty URL is built as a production-ready URL shortener, not just a demo project. It showcases how modern frontend frameworks and a well-structured Express API can work together to deliver a secure and scalable application.

Feedback, feature suggestions, and contributions are always welcome.
If you find it useful, a star ⭐ would mean a lot.

Thanks for reading.