DEV Community: ludy.dev

How I built a static PDF generation pipeline for clean printable templates

ludy.dev — Wed, 03 Jun 2026 09:28:48 +0000

Automating the Generation Script

I wrote a Node.js build script that spins up Playwright, visits the local rendering routes, and prints them to PDF format:

const { chromium } = require('playwright');

async function generatePDF(url, outputPath, format) {
  const browser = await chromium.launch();
  const page = await browser.newPage();
  await page.goto(url, { waitUntil: 'networkidle' });

  await page.pdf({
    path: outputPath,
    format: format, // 'Letter' or 'A4'
    landscape: true,
    printBackground: true,
  });

  await browser.close();
}

This static pipeline outputs clean, minimal vector PDFs directly into my public directory during the build process, ensuring fast static page delivery without on-the-fly PDF generation overhead. Let me know what you think of this approach!

Programmatically Generating Print-Ready Vector PDFs for the Web

ludy.dev — Mon, 01 Jun 2026 09:55:32 +0000

This math ensures that regardless of user browser DPI, the final file looks identical on every machine and prints beautifully.

Zero Server Load

Because the puzzle data structures are lightweight JSON matrices, the rendering layer runs entirely on client-side JS using modern web canvas and PDF synthesis tools. This means hosting costs scale close to $0, allowing the platform to remain completely free and ad-light for parents and teachers.

I would love to hear your thoughts on optimization techniques for programmatic puzzle generation or dynamic PDF layouts!

Under the Hood: Building a zero-signup, client-side home repair cost estimator

ludy.dev — Mon, 01 Jun 2026 09:54:33 +0000

As developers, we often build SaaS projects with complex databases, user auth, and heavy backend logic. But sometimes, the most useful thing you can build is a highly reactive, pure static calculator designed to solve a real-world headache.

After receiving some absurdly high quotes to fix my home's damp crawl space, I decided to analyze contractor pricing algorithms and build a client-side cost estimator.

The Tech Stack

I kept things incredibly lightweight:

Framework: Next.js (Static HTML Export)
Styling: Tailwind CSS for responsive grid layouts
State Management: React Hooks (clean and simple, no heavy state libraries needed)

Because I wanted this to be a fast utility, I avoided any backend databases or user authentication. The mathematical model runs entirely in the user's browser.

The Mathematical Challenge

The hardest part was translating messy, real-world construction logic into predictable JavaScript formulas. Contractor pricing isn't linear. For example:

Material waste: You can't just buy the exact square footage of a 20-mil vapor barrier. You have to account for a 10% overlap on seams and vertical wall runs.
Labor scaling: Small crawl spaces have a higher labor cost per square foot because setting up equipment and maneuvering in tight spaces takes a fixed baseline of time.
Equipment thresholds: A dehumidifier isn't sized linearly; it scales based on total cubic volume (sq ft * height) and local humidity basements.

I mapped out these thresholds using static lookup matrices, ensuring the generated estimates match real-world bids within a 5-10% margin of error.

Bypassing the Lead-Gen Trap

Most online home-improvement calculators are actually lead-generation funnels disguised as tools. They force you to enter your phone number so they can sell your info to local contractors.

I deliberately built this tool to run entirely client-side with zero tracking, zero storage, and zero email gates. The feedback has been awesome, proving that people still appreciate pure utility tools on the web.

Tired of SEO Spam? Building a Static-First Directory for 85+ AI Tools

ludy.dev — Mon, 01 Jun 2026 09:49:50 +0000

We have all been there. You need a simple background remover or want to compare DALL-E 3 pricing against Midjourney, but search results are clogged with heavily optimized SEO spam, aggressive paywalls, and outdated blog posts.

I got tired of clicking through dozens of spammy sites just to find a simple, functional free stock photo resource or a reliable AI image upscaler. So, I did what any developer does: I spent a weekend building my own curated database hub, ImageNav, to solve this tool-fatigue problem once and for all.

Here is how I engineered a lightning-fast, zero-database catalog of 85+ AI image tools that loads in milliseconds and costs nothing to host.

Why Databases for Small Catalogs is an Anti-Pattern

When building directory sites, the knee-jerk reaction is to spin up a PostgreSQL instance or hook up a heavy headless CMS. But for a dataset of ~100 curated tools, this adds unnecessary latency, architectural overhead, and database query costs.

Instead, I opted for a static-first architecture using Next.js and structured JSON files.

Every tool on ImageNav is represented as a typed object in a TypeScript schema. By storing the data locally:

Performance: Pages are compiled statically at build time. Search and filtering happen entirely client-side, making the UX feel instantaneous.
Cost: The site is hosted on Vercel with zero database cold-start issues, completely within the free tier.
Maintainability: Data updates are as simple as editing a local JSON file or merging a quick Git pull request.

High-Performance Client-Side Filtering

To make sorting through 85+ tools seamless, I built a lightweight React Hook that manages multi-select facets (Categories, Pricing Models, and Features).

Instead of pulling in heavy third-party search libraries, I combined a lightweight regex fuzzy search with Native JS array filtering. Since the dataset size is highly optimized, these array operations execute in under 2ms even on low-end mobile devices, keeping the UI highly responsive.

Automating Link & Integrity Checks

One of the biggest issues with curated directories is link rot and outdated pricing. To tackle this, I wrote a Node.js script that runs weekly via GitHub Actions. It sends lightweight HEAD requests to all cataloged URLs to verify status codes and flags any tool that goes offline or changes redirects.

ImageNav is now live at https://imagenav.net. If you are looking for a clean, ad-free way to find your next design or AI generator tool, check it out and let me know what you think of the UX!

Building a 100% Client-Side HEIC to JPG Converter: Zero Servers, Zero Uploads

ludy.dev — Sun, 31 May 2026 17:38:48 +0000

Every time I Airdrop photos from my iPhone to my Windows machine, I run into the same annoying problem: .heic files. They don’t open natively on most Windows photo viewers, and converting them is a massive pain.

When I looked for online converters, I was shocked by how sketchy they were. Most of them required me to upload my private photos to their servers, limited me to 5 files per batch unless I paid, or spammed me with intrusive ads. As a developer, I knew there had to be a better, more secure way to handle this. Why send megabytes of private image data to a remote server when our modern browsers have more than enough computing power to do it locally?

So, I spent my weekend building a 100% client-side, offline-first HEIC to JPG converter: heictojpgfree.net.

The Tech Stack: How it Works Under the Hood

To make this tool lightning-fast and completely private, I designed it to run entirely in the user's browser. Here is the technical breakdown:

WebAssembly (Wasm) + libheif: Browsers don't natively support decoding HEIC/HEIF files yet. To bypass this, I compiled libheif (a popular C++ HEIF decoder) into WebAssembly using Emscripten. This allows the browser to parse the HEIC container and extract the raw image data at near-native speeds.
HTML5 Canvas: Once the Wasm module decodes the raw pixel data, it transfers the byte array to an offscreen HTML5 canvas element. From there, I use canvas.toBlob() to compress and export it as a standard JPEG file.
File System Access API: Users can drag and drop an entire folder of HEIC files. The tool processes them sequentially or concurrently based on the hardware threads available.

The Architectural Challenges

Building this wasn't without its hurdles. During testing, I noticed two major issues:

Memory Leaks: WebAssembly doesn't have automatic garbage collection for C++ pointers. When batch-converting 50+ high-res iPhone photos, the browser tab would frequently crash due to out-of-memory (OOM) errors. I had to strictly manage memory allocation, ensuring every decoded frame and allocation pointer was manually freed immediately after drawing to the canvas.
UI Thread Blocking: Initially, decoding heavy HEIC files on the main thread made the UI completely unresponsive. I resolved this by offloading the Wasm decoding process to Web Workers. This keeps the browser UI running at a buttery-smooth 60fps, even while batch-processing dozens of images.

Give it a Spin

The result is a clean, minimal utility at heictojpgfree.net. No signups, no paywalls, and absolutely no data leaves your machine.

I'd love to hear your thoughts on the performance! How do you handle heavy image processing on the frontend? Drop your feedback or questions in the comments below!

Building a Fast, Ad-Free Gacha Simulator and Pity Tracker: The Tech Stack and Math Behind GachaLab

ludy.dev — Sun, 31 May 2026 17:38:43 +0000

By isolating this state client-side using local storage, users can track their actual in-game pity count securely without needing a heavy database back-end or login flow.

Keeping SEO Clean Without Bloat

A major challenge was indexing highly dynamic content (like daily changing redemption codes). Instead of pulling these via heavy client-side API requests on load, we set up a nightly headless build process that fetches the latest data, updates our static markdown schemas, and redeploys the site automatically. The result? 100/100 Lighthouse performance scores and instant navigation.

I'd love to hear your thoughts on this setup. How do you usually handle dynamic math-heavy features in static site generators? Drop a comment below!

Rendering Custom Tesla Wraps in the Browser: A Deep Dive into Real-Time 3D Canvas Mapping

ludy.dev — Sun, 31 May 2026 17:28:13 +0000

I've always loved messing around with the Toybox Paint Shop inside my Tesla, but trying to visualize how a custom wrap, pattern, or color shift would look on a real Model 3 or Cybertruck using just a flat color picker is incredibly frustrating. I wanted a way to design and preview complex patterns, matte finishes, and multi-tone wraps in real-time, then grab the exact configuration files instantly.

Since nothing clean existed online, I built TeslaPaintShop over a couple of weekends. Here is how I solved the technical challenges of rendering complex automotive wraps dynamically in the browser.

The Core Tech Stack

To keep the application lightweight, fast, and entirely client-side, I went with:

Three.js / WebGL for the 3D rendering pipeline.
Vite + Vanilla JS to avoid framework overhead and keep the bundle size tiny.
HTML5 Canvas API for real-time procedural texture and pattern generation before projecting them onto the 3D model.

Challenge 1: Optimizing 3D Vehicle Meshes for the Web

The biggest hurdle was asset size. Standard CAD models of a Tesla Model Y or Cybertruck are hundreds of megabytes. Downloading those on a mobile connection is a terrible user experience.

I imported the raw models into Blender and aggressively decimated the geometry. I reduced the polygon count by over 85% while preserving sharp feature lines using split-normals. To handle different body panels, I separated the meshes into logical components (hood, doors, roof, trunk) so users could apply distinct materials to individual parts of the car. The final GLB assets are under 1.8MB each!

Challenge 2: Dynamic Wrap & Pattern Mapping

Applying a flat color is easy. Applying a seamless repeating wrap pattern (like carbon fiber, camo, or custom decals) across complex curved car panels is where it gets tricky.

Instead of pre-rendering texture maps, I used dynamic HTML5 canvases as texture sources. When a user tweaks a pattern scale, angle, or metallic finish:

The app draws the pattern procedurally onto a hidden 2D canvas.
It flags the Three.js CanvasTexture with needsUpdate = true.
The WebGL shader recalculates the UV wrapping in real-time.

For the Cybertruck, the flat stainless steel panels were a breeze. But mapping wraps onto the curved wheel arches of the Model 3 required precision UV mapping to avoid ugly texture stretching.

Challenge 3: Generating Toybox Compatible Outputs

The final step was allowing users to export their designs. Since the Tesla custom toybox system reads specific color codes and configuration setups, the app translates the visual material properties (roughness, metalness, and hex colors) into instant, compatible layout files that match the exact parameters expected by the car’s system.

I'd love to get your feedback on the rendering performance! Check it out at teslapaintshop.org and let me know what you think of the WebGL material transitions in the comments.

Bridging the language gap: Under the hood of an AI-powered game UI translator

ludy.dev — Sun, 31 May 2026 17:28:08 +0000

When NetEase relaunched World of Warcraft in China (specifically the Titan Reforged / Project 80 Chrono servers), thousands of English-speaking players jumped in. The problem? Translating Chinese game UI, item tooltips, and GDKP chat logs in real-time is a complete nightmare. Standard OCR tools fail hard because they don't understand game-specific terminology (like "GDKP", "Chrono scaling", or class abbreviations).

So, I built a tailored web portal at titanreforged.com, featuring a custom AI-powered screenshot translator. Here’s how I put the technical pipeline together.

The Challenge: Low-Res MMO Fonts & Slang

Game screenshots are notoriously hard to parse for standard OCR models. The fonts are styled, pixelated, and overlaid on complex, high-contrast backgrounds. Traditional OCR often outputs garbage text or fails entirely.

Worse, standard translators fail at gaming slang. If a Chinese player writes "来个强力糖门", a generic translator translates it literally as "Come strong sugar gate". But in WoW speak, it actually means "Looking for a Warlock (who can create soulwells/healthstones)".

The Architecture: OCR + LLM Pipeline

To solve this, I designed a two-stage processing pipeline using Next.js, HTML5 Canvas, and a serverless backend connecting to a custom-tuned LLM.

Client-Side Canvas Preprocessing:
Before sending anything to the server, the user pastes a screenshot. I use HTML5 Canvas to convert the image to grayscale, increase contrast, and invert colors. This simple step improved OCR recognition accuracy by over 40%.
Vision-to-Text Processing:
The processed image is sent to an edge API route. We run it through a vision model optimized for simplified Chinese characters.
Context-Aware LLM Translation:
Instead of piping raw text directly to a translation API, we pass the OCR output to an LLM with a specialized system prompt. The prompt includes a mapping dictionary of Chinese WoW terminology, dungeon names, and raid slang.

Optimizing for Speed and Cost

Querying LLMs for every single screenshot gets expensive fast. To keep the site fast and free:

Redis Caching: Exact matches of OCR strings bypass the LLM entirely and fetch cached translation mappings.
Debounced Requests: On the frontend, user inputs are strictly debounced to prevent API abuse during rapid pasting.

The result is a clean, instant translator helper that turns Chinese raid listings into readable English in under 800ms. I'm currently looking to open-source the translation mapping dictionary. What do you think about this hybrid OCR setup? Drop your architectural suggestions below!

Building a zero-dependency, sub-100ms weight converter: Why client-side state is all you need

ludy.dev — Sun, 31 May 2026 17:26:22 +0000

This keeps the conversions accurate to 4 decimal places without adding layout shifts or overhead.

Bi-directional Instant State Binding

Instead of having a single "Convert" button, the site calculates as you type. I mapped every input field (kilograms, pounds, stones, ounces, grams) to a single base unit value in grams.

Whenever any input changes, the script calculates the base value in grams and instantly updates all other fields dynamically:

const updateAllFields = (baseGrams, activeInput) => {
  Object.keys(units).forEach(unit => {
    if (unit !== activeInput) {
      inputs[unit].value = roundTo(baseGrams / units[unit].conversionFactor);
    }
  });
}

This unidirectional flow keeps the UI reactive and predictable with less than 60 lines of code.

What are your thoughts on handling dynamic unit conversions? Would you have gone the Vanilla JS route or used a lightweight framework like Alpine? Let me know in the comments!

How I Engineered a Pixel-Perfect Layering Simulator for a Fashion Roguelike

ludy.dev — Sun, 31 May 2026 17:26:13 +0000

Real-time Combo Calculation

The real challenge was the calculation engine. Certain items trigger "Synergy Buffs" (e.g., matching a Kawaii headpiece with Gothic boots). Running O(N^2) checks on every UI click killed the frame rate on older mobile devices.

To solve this, I compiled the game's combo rules into a bitwise matrix lookup table. Each outfit item is assigned a specific bitmask. Checking for combos is simplified to a series of fast bitwise AND operations in the main React render loop, bringing the computation time down to less than 0.1ms.

Keeping It Zero-Server

Since I'm hosting this on a tight indie budget, I wanted the simulator to be completely serverless. The entire state of the Layering Simulator is serialized into a lightweight Base64 string appended to the URL path. This allows users to share their custom builds instantly with just a link, without me needing a database.

Check out the live simulator at dresstheduel.com and let me know if you have any ideas on how to optimize asset pre-loading even further!

Curing SEO Spam: How I built a clean, markdown-driven directory of AI Video Tools and APIs

ludy.dev — Sun, 31 May 2026 17:25:10 +0000

Using standard markdown files for the data model yields major benefits:

Zero Database Latency: All pages are statically generated at build time. The site loads almost instantly because it's just static HTML and CSS served via CDN.
Git-based Workflow: Updating the database is as simple as pushing a new markdown file or merging a PR.
Robust Local Filtering: By compiling the frontmatter metadata into a single JSON index at build time, I can run ultra-fast client-side filtering and sorting without making any API requests.

Tackling the Filtering Engine

The biggest hurdle with static directories is handling complex multi-select filtering (e.g., finding a tool that has an API, offers a free tier, and supports image-to-video generation).

Instead of relying on heavy client-side state libraries, I built a lightweight search index utility that parses the local JSON list on the client side using search parameters. The state is serialized directly into the URL, making every search filter deep-linkable.

What's Next?

The goal is to keep this repository of AI video production software as clean, fast, and structured as possible. I want to build a public GitHub repository where developers can submit pull requests to add new tools or update pricing directly, avoiding the need for a complex admin portal.

Check out the live version at findaivideo.com and let me know your thoughts on this static markdown approach! How do you handle directory structures in your own side projects?

Building a zero-dependency Unicode text engine in the browser (and why clipboard APIs are still a pain)

ludy.dev — Sun, 31 May 2026 15:59:00 +0000

This works perfectly for sequential blocks. However, Unicode has some historical quirks (like the cursive "g" or "h" sometimes pointing to different ranges in the Letterlike Symbols block), which required custom fallback exceptions.

The Glitch (Zalgo) Generator and Diacritics

For the glitch and strikethrough generators, I had to work with Combining Diacritical Marks. These are characters designed to be rendered on top of, below, or through the preceding character.

For the strikethrough tool, it's as simple as appending \u0336 after every character. For the glitch tool, I wrote a randomizer that stacks up to 15 different random combining marks (like \u030d or \u0311) on top of a single base letter. This forces the browser to render symbols that physically overflow the CSS line-height boundaries.

The iOS Clipboard Struggle

Since the main user interaction is "one-click copy," I needed clipboard copying to be bulletproof. Modern browsers support navigator.clipboard.writeText(), but iOS Safari is notoriously strict. If the copy action isn't directly inside a synchronous user-initiated call stack, iOS blocks it.

To solve this, I built a reliable fallback:

async function copyToClipboard(text) {
  try {
    await navigator.clipboard.writeText(text);
  } catch (err) {
    const textArea = document.createElement("textarea");
    textArea.value = text;
    textArea.style.position = "fixed"; 
    document.body.appendChild(textArea);
    textArea.focus();
    textArea.select();
    document.execCommand('copy');
    document.body.removeChild(textArea);
  }
}

Keeping it Ultra-Light

By sticking to vanilla JS, avoiding modern UI frameworks (no React, no Vue), and optimizing our SVG icons, the entire site footprint is under 30KB.

You can test the live tool out at cursivetool.com.

I would love to hear your thoughts on how you handle text manipulation and clipboard compatibility in your own utility projects!