DEV Community: 陈宇翔

How I Built Browser-Based PDF Merging tool

陈宇翔 — Sat, 14 Mar 2026 09:09:59 +0000

When people say “just merge PDFs in the browser,” they usually mean “pick a library, wire up a button, and export a file.” I thought about it that way at first too. But once I started building pdfzus, I realized that a browser-based PDF merge is not really a file utility problem. It is a product architecture problem with strong privacy, UX, and boundary-setting implications.

That is why I chose to build pdfzus as a browser-based PDF merge workflow instead of starting with a server-first implementation. I wanted local processing, a cleaner privacy story, and a simpler user experience for common document tasks. But I also had to accept that browser-side PDF processing comes with very real limits, especially around memory, very large files, and edge-case documents.

Why I wanted to revisit “merge PDFs online”

A lot of online PDF tools solve the happy path, but many of them also push users into a tradeoff they did not explicitly choose: upload your files to a third-party server, wait, and hope the workflow is trustworthy enough for sensitive documents.

For a product like pdfzus, that tradeoff mattered. Merging PDFs is often not a casual task. People use it for job applications, contracts, forms, administrative paperwork, study materials, and financial records. In those contexts, “online” should not automatically mean “send everything away.”

That was the first architectural decision I made: if the common workflow is “combine a few documents, reorder them, and download one clean file,” then the browser is not just a delivery channel. It can be the execution environment.

That decision shaped the stack. In the repo, the frontend is a Next.js and React app. The PDF workflow is supported by pdf-lib for PDF manipulation, pdfjs-dist for rendering-related needs, and @dnd-kit/* for drag-and-drop ordering. That combination tells the real story: this is not a thin upload form. It is a client-heavy document workflow.

My contrarian take is simple: browser-side PDF merge is often a better product choice than server-side merge, but only if you are disciplined enough to say no to the workloads it should not own.

The stack I chose and why it made sense

I did not want pdfzus to become a generic document-processing backend hiding behind a pretty interface. I wanted a browser-based PDF merge flow that felt direct: import files, reorder them, merge them, export the result.

The core pieces are straightforward:

pdf-lib gives me browser-friendly PDF manipulation without forcing a server round trip.
pdfjs-dist helps support preview and rendering-related interactions that matter in a document UI.
@dnd-kit/* makes file ordering a first-class interaction instead of a clumsy afterthought.
Next.js and React give me a practical way to build the surrounding product experience.

That stack is not exotic, and that is part of the point. For this kind of tool, novelty is less important than control. I needed libraries that were understandable, composable, and realistic to operate in a browser-based app.

I also needed to be honest about what the product is not. The current service worker in the repo explicitly opts out of offline caching. So even though the product leans heavily on local browser processing, I should not describe it as a full offline-first application. That distinction matters. “Files are processed locally” and “the entire app is offline-first” are not the same claim.

That is one of the easiest mistakes to make in technical product writing: once a product has a strong privacy-friendly architecture, it becomes tempting to overextend the narrative. I try not to do that here.

What works well in a browser-based PDF merge flow

For light-to-medium document workflows, browser-side merging is genuinely strong.

If a user wants to combine a cover letter, resume, and certificates into one file, the browser is a great place to do it. If someone needs to merge a few office PDFs before sending them by email, the browser is a great place to do it. If a user needs drag-and-drop ordering before exporting a final document, the browser is a great place to do it.

That is where pdfzus gets its practical advantage. The workflow is narrow enough to stay understandable:

Import multiple files
Reorder them visually
Merge them into one output
Optionally compress the final document for sharing

This is also where local processing matters most. For everyday document tasks, avoiding unnecessary uploads is not just a technical implementation detail. It is part of the product value.

Another lesson I learned is that drag-and-drop ordering is not a cosmetic feature. In a merge workflow, ordering is the task. If reordering feels brittle, the whole product feels brittle. That is why using a real drag-and-drop foundation matters more than many developers expect.

Where the browser-side approach stops being elegant

My initial mistake was assuming that moving PDF merging into the browser would simplify everything.

It simplifies infrastructure. It does not simplify the entire problem.

The complexity moves.

Instead of designing upload queues, storage lifecycles, and merge jobs on the backend, I had to think harder about memory pressure, large file behavior, and awkward document edge cases. Browser-side PDF processing works well when the workload is modest and predictable. It gets harder when files are huge, document structures are messy, or users expect the browser to behave like a desktop batch processor.

This is where a lot of “browser-side everything” thinking breaks down.

A browser-based PDF merge is a good abstraction when:

files are reasonably sized
the task is mostly combine, order, and export
privacy matters more than heavy processing breadth
the user benefits from immediate, local interaction

It is a weaker abstraction when:

files are very large
the workflow is heavy batch processing
documents have edge-case constraints such as encryption
the product starts drifting toward full document infrastructure rather than focused utilities

That is the real failure lesson from building this kind of flow: local processing is not a universal answer. It is a scoped answer.

The architectural tradeoff I would make again

Even with those constraints, I would still choose a browser-based PDF merge for pdfzus.

Why?

Because the product is strongest when it stays focused on common document work, not when it tries to impersonate an enterprise PDF backend. For a privacy-friendly PDF tool, the combination of local handling, lower backend dependency, and a more direct UI is worth a lot.

It also forces better product discipline. Once you accept that the browser is your execution environment, you become more careful about scope. You stop pretending every use case belongs in version one. You think harder about happy paths, failure states, and what the user actually came to do.

That discipline is valuable. In my experience, it is what keeps a focused utility from turning into a confused platform.

What I would tell other developers building something similar

If you are considering a browser-based PDF merge or any client-side PDF processing workflow, I would start with three questions:

1. Is privacy a real product requirement, or just a nice headline?

If users are handling sensitive documents, local processing is a meaningful architectural choice, not a marketing flourish.

2. Is your workflow narrow enough to stay fast and predictable?

If your core task is “select, order, merge, export,” the browser can be a strong fit. If your workflow is much heavier, be careful.

3. Are you willing to define hard boundaries?

The browser is not the wrong place for PDF processing. It is the wrong place for pretending there are no limits.

My practical recommendation is this: use browser-side merge when you want a privacy-friendly PDF tool for common workflows, but design the product around explicit limits from day one. Be honest about what works well, what degrades under pressure, and what belongs in another architecture entirely.

That is the part I underestimated at the start. I thought the hard decision was choosing between frontend and backend processing. It turned out the harder decision was choosing what not to promise.

And that is probably the most useful lesson I got from building pdfzus.

Conclusion

A browser-based PDF merge is worth building when the goal is not “process every PDF workload imaginable,” but “make a common document task simpler, safer, and easier to trust.”

For pdfzus, that meant building around pdf-lib, pdfjs-dist, @dnd-kit, and a React/Next.js frontend, while staying honest about the boundaries of local browser processing. The result is not a universal PDF engine. It is a focused workflow for people who need to merge PDFs in the browser without unnecessary complexity.

If you are building a similar tool, my advice is simple: treat browser-side processing as a product strategy, not just an implementation trick.

Karmic Tail Calculator: Free Destiny Matrix Insights in Seconds

陈宇翔 — Mon, 12 Jan 2026 10:05:19 +0000

As developers, we often look for patterns. Destiny Matrix numerology is built on patterns too — and one of the most interesting is the Karmic Tail, a past/present/future sequence that highlights recurring life lessons.

I built a small tool to make this insight fast and frictionless: the Karmic Tail Calculator.

What it does

Calculates karmic tail past, present, and future themes
Explains the Arcana meanings behind each position
Delivers instant results with no signup

Why it’s different

Most numerology sites gate the explanation behind a paywall. This one doesn’t. The output is short, practical, and designed to prompt reflection — not overwhelm you with jargon.

How to use it

Enter your birth date
Click calculate
Read the three themes and their meanings

That’s it.

Try it

https://destiny-matrix.cc/en/tool/karmic-tail-calculator/

If you enjoy tools that blend ancient systems with modern UX, I’d love your feedback.

Building Privacy-First Image Merging with Client-Side Canvas API

陈宇翔 — Fri, 26 Sep 2025 13:06:23 +0000

Building Privacy-First Image Merging with Client-Side Canvas API - The Technical Architecture Behind mergejpg.me

How to build a completely private, browser-based image processing tool using modern web APIs and TypeScript

Introduction

In today's digital landscape, privacy concerns around file uploads are more critical than ever. When building mergejpg.me, I faced a fundamental challenge: how do you create a powerful image merging tool that processes files without ever sending them to a server? The solution involved leveraging the full potential of modern web APIs through what I call "UltraThink MCP" (Model-Canvas-Processing) - a client-side architecture that maximizes browser capabilities.

This article explores the technical principles behind a privacy-first image merging application that processes 50+ images entirely in the browser, with zero server uploads and unlimited creative freedom.

The Privacy-First Architecture Challenge

Traditional image processing tools follow a simple pattern:

Upload files to server
Process on backend
Return result

But this approach has fundamental privacy and scalability issues:

Data exposure: Sensitive images leave the user's device
Server costs: Processing requires expensive infrastructure
Latency: Network uploads add significant delays
Compliance: GDPR/privacy regulations complicate data handling

The UltraThink MCP approach flips this paradigm entirely.

Core Technology Stack: The MCP Foundation

Canvas API as the Processing Engine

The HTML5 Canvas API serves as our core image processing engine. Unlike simple CSS transforms, Canvas provides pixel-level control with hardware acceleration:

class ImageProcessor {
  private canvas: HTMLCanvasElement;
  private ctx: CanvasRenderingContext2D;

  constructor() {
    this.canvas = document.createElement('canvas');
    this.ctx = this.canvas.getContext('2d')!;

    // Enable high-DPI support
    const devicePixelRatio = window.devicePixelRatio || 1;
    this.canvas.width = width * devicePixelRatio;
    this.canvas.height = height * devicePixelRatio;
    this.ctx.scale(devicePixelRatio, devicePixelRatio);
  }
}

FileReader API for Secure Local Processing

The FileReader API enables direct local file access without uploads:

async function processImageFiles(files: File[]): Promise<ImageFile[]> {
  const promises = Array.from(files).map(file => {
    return new Promise<ImageFile>((resolve, reject) => {
      // Security validation
      if (!file.type.startsWith('image/')) {
        reject(new Error('Invalid file type'));
        return;
      }

      const reader = new FileReader();
      reader.onload = (e) => {
        const img = new Image();
        img.onload = () => resolve({
          file,
          img,
          width: img.width,
          height: img.height,
          url: e.target!.result as string
        });
        img.src = e.target!.result as string;
      };
      reader.readAsDataURL(file);
    });
  });

  return Promise.all(promises);
}

The Three-Layer Processing Architecture

Layer 1: The ImageMerger Orchestrator

The ImageMerger class serves as the main API, coordinating between different processing engines:

export class ImageMerger {
  private tldrawMerger: TldrawMerger | null = null;
  private isInitialized = false;

  async mergeFiles(
    files: File[], 
    settings: MergeSettings,
    onProgress?: ProgressCallback
  ): Promise<MergeResult> {
    // Process files into ImageFile objects
    const { images, errors } = await processFiles(files);

    if (settings.format === 'pdf') {
      return await this.generatePDF(images, settings, onProgress);
    } else {
      return await this.tldrawMerger!.merge(images, settings, onProgress);
    }
  }
}

Layer 2: TLDraw-Powered Canvas Manipulation

For advanced layout control, we integrate TLDraw's powerful canvas engine:

export class TldrawMerger {
  private editor: Editor | null = null;

  async initialize(): Promise<void> {
    return new Promise((resolve, reject) => {
      // Create hidden TLDraw instance
      const container = document.createElement('div');
      container.style.cssText = `
        position: absolute;
        left: -9999px;
        visibility: hidden;
        width: 800px;
        height: 600px;
      `;

      const TldrawComponent = React.createElement(Tldraw, {
        onMount: (editor: Editor) => {
          this.editor = editor;
          resolve();
        },
        // Disable UI for programmatic use
        components: {
          Toolbar: null,
          StylePanel: null,
          MainMenu: null
        }
      });

      this.root.render(TldrawComponent);
    });
  }
}

Layer 3: PDF Generation with pdf-lib

For PDF output, we use pdf-lib for client-side PDF creation:

export class PDFGenerator {
  static async generatePDF(
    images: ImageFile[], 
    settings: MergeSettings
  ): Promise<Uint8Array> {
    const pdfDoc = await PDFDocument.create();

    for (const image of images) {
      const imageBytes = await this.dataUrlToBytes(image.dataUrl);

      let pdfImage;
      if (image.type === 'image/jpeg') {
        pdfImage = await pdfDoc.embedJpg(imageBytes);
      } else {
        pdfImage = await pdfDoc.embedPng(imageBytes);
      }

      const page = pdfDoc.addPage();
      const { width, height } = this.calculateDimensions(
        pdfImage.width, 
        pdfImage.height, 
        page.getWidth(), 
        page.getHeight()
      );

      page.drawImage(pdfImage, {
        x: (page.getWidth() - width) / 2,
        y: (page.getHeight() - height) / 2,
        width,
        height
      });
    }

    return await pdfDoc.save();
  }
}

Dual-Mode Processing: Grid vs Creative Canvas

Quick Grid Mode: Structured Layouts

For simple horizontal/vertical arrangements:

class GridLayoutEngine {
  calculateLayout(images: ImageFile[], settings: MergeSettings) {
    const { direction, spacing } = settings;
    const positions: ImagePosition[] = [];

    let currentX = 0, currentY = 0;

    for (const image of images) {
      positions.push({ x: currentX, y: currentY, width: image.width, height: image.height });

      if (direction === 'horizontal') {
        currentX += image.width + spacing;
      } else {
        currentY += image.height + spacing;
      }
    }

    return { positions, canvasWidth: currentX, canvasHeight: currentY };
  }
}

Creative Canvas Mode: Unlimited Freedom

For advanced positioning with drag, resize, and rotate:

class CreativeCanvasEngine {
  addImage(imageData: ImageFile): CanvasObject {
    const canvasObject = {
      id: generateUUID(),
      img: imageData.img,
      x: Math.random() * (this.container.width - imageData.width),
      y: Math.random() * (this.container.height - imageData.height),
      width: imageData.width,
      height: imageData.height,
      rotation: 0,
      scaleX: 1,
      scaleY: 1
    };

    this.objects.push(canvasObject);
    return canvasObject;
  }

  render() {
    const ctx = this.container.getContext('2d');
    ctx.clearRect(0, 0, this.container.width, this.container.height);

    this.objects.forEach(obj => {
      ctx.save();
      ctx.translate(obj.x + obj.width/2, obj.y + obj.height/2);
      ctx.rotate(obj.rotation * Math.PI / 180);
      ctx.scale(obj.scaleX, obj.scaleY);
      ctx.drawImage(obj.img, -obj.width/2, -obj.height/2, obj.width, obj.height);
      ctx.restore();
    });
  }
}

Performance Optimization Strategies

Memory Management

class MemoryManager {
  private objectUrls = new Set<string>();

  createObjectURL(blob: Blob): string {
    const url = URL.createObjectURL(blob);
    this.objectUrls.add(url);
    return url;
  }

  cleanup(): void {
    for (const url of this.objectUrls) {
      URL.revokeObjectURL(url);
    }
    this.objectUrls.clear();

    // Force garbage collection if available
    if (window.gc) window.gc();
  }
}

Batch Processing for Large Image Sets

class BatchProcessor {
  async processImages(images: ImageFile[], batchSize = 10): Promise<ProcessedImage[]> {
    const batches = this.createBatches(images, batchSize);
    const results: ProcessedImage[] = [];

    for (const batch of batches) {
      const batchResults = await Promise.all(
        batch.map(image => this.processImage(image))
      );
      results.push(...batchResults);

      // Prevent UI blocking
      await this.delay(10);
    }

    return results;
  }
}

OffscreenCanvas for Non-Blocking Processing

// Main thread
class AsyncImageProcessor {
  private worker = new Worker('./image-worker.js');

  async processImages(images: ImageFile[]): Promise<ProcessedImage[]> {
    return new Promise((resolve) => {
      this.worker.postMessage({
        images: images.map(img => ({
          canvas: img.canvas.transferControlToOffscreen(),
          width: img.width,
          height: img.height
        }))
      });

      this.worker.onmessage = (e) => resolve(e.data.result);
    });
  }
}

// Worker thread (image-worker.js)
self.onmessage = function(e) {
  const { images } = e.data;

  const processedImages = images.map(imageData => {
    const canvas = imageData.canvas;
    const ctx = canvas.getContext('2d');

    // Heavy processing without blocking main thread
    ctx.filter = 'brightness(1.2) contrast(1.1)';
    ctx.drawImage(imageData.originalCanvas, 0, 0);

    return canvas.transferControlToOffscreen();
  });

  self.postMessage({ result: processedImages });
};

Multi-Format Export Capabilities

High-Quality JPEG Export

static exportAsJPEG(canvas: HTMLCanvasElement, quality = 0.9): Promise<Blob> {
  return new Promise((resolve) => {
    canvas.toBlob(resolve, 'image/jpeg', quality);
  });
}

WebP with Fallback

static exportAsWebP(canvas: HTMLCanvasElement): Promise<Blob> {
  return new Promise((resolve) => {
    // Check WebP support
    const testCanvas = document.createElement('canvas');
    const isWebPSupported = testCanvas.toDataURL('image/webp').indexOf('data:image/webp') === 0;

    if (isWebPSupported) {
      canvas.toBlob(resolve, 'image/webp', 0.9);
    } else {
      canvas.toBlob(resolve, 'image/png');
    }
  });
}

Security Considerations

Content Security Policy (CSP) Compliance

class SecureImageProcessor {
  static validateImageSrc(src: string): boolean {
    // Only allow data URLs and blob URLs
    return src.startsWith('data:image/') || src.startsWith('blob:');
  }

  static sanitizeImageData(canvas: HTMLCanvasElement): boolean {
    try {
      // Check for canvas taint
      const imageData = canvas.getContext('2d')!.getImageData(0, 0, 1, 1);
      return true;
    } catch (error) {
      console.warn('Canvas is tainted, cannot export');
      return false;
    }
  }
}

Real-World Performance Metrics

Based on production data from mergejpg.me:

Processing Speed: 50 images (2MB each) in 3-5 seconds
Memory Usage: Peak 1GB during processing, 200MB post-completion
Maximum Capacity: 500+ images (browser memory dependent)
Format Support: JPEG, PNG input → JPEG, PNG, PDF output
Zero Network Overhead: 100% client-side processing

The Business Impact of UltraThink MCP

This architecture enables unique value propositions:

True Privacy: No data ever leaves the user's device
Unlimited Scale: No server processing costs
Instant Processing: No upload/download latency
Offline Capability: Works without internet connection
Global Compliance: Automatic GDPR/privacy compliance

Use Cases in Production

mergejpg.me serves diverse professional needs:

Tax consultants: Merging confidential receipt scans into organized PDFs
Marketing teams: Creating social media comparison images
Designers: Building mood boards with unlimited creative positioning
Students: Combining screenshots for research documentation
Real estate: Creating property showcase layouts

Future Enhancements

The MCP architecture opens doors for advanced features:

WebGPU Integration: Hardware-accelerated image processing
WebAssembly Filters: Native-speed image effects
File System API: Direct file system integration
WebCodecs API: Advanced format support

Conclusion

The UltraThink MCP approach proves that modern browsers can handle sophisticated image processing traditionally requiring server infrastructure. By fully utilizing Canvas API, FileReader, and modern web standards, we've created a tool that processes images faster than upload-based alternatives while maintaining absolute privacy.

This architecture pattern extends beyond image processing - it represents a paradigm shift toward privacy-first, client-side applications that respect user data while delivering powerful functionality.

The complete implementation is powering mergejpg.me, where you can experience this technology firsthand. Try merging 50+ images instantly, with complete privacy, and see the future of client-side image processing.

Want to implement similar privacy-first processing in your applications? The techniques covered here can be adapted for document processing, audio manipulation, and other data-sensitive workflows. The key is thinking beyond traditional client-server patterns and fully embracing what modern browsers can accomplish.

Technical Resources

Building BPM Finder: Technical Challenges in Client-Side Audio Analysis

陈宇翔 — Sun, 14 Sep 2025 08:01:52 +0000

When I set out to build BPM Finder, a comprehensive audio analysis tool, I knew I was taking on some significant technical challenges. What started as a simple BPM detection tool evolved into a sophisticated platform handling multiple audio formats, batch processing, and real-time analysis - all while keeping user privacy as the top priority.

The Core Challenge: Privacy-First Audio Processing

The biggest technical hurdle was implementing 100% client-side audio processing. While most competitors upload files to their servers for analysis, I wanted to ensure that sensitive tracks - especially unreleased music from producers and DJs - never leave the user's device.

Web Audio API: Power and Pitfalls

The foundation of BPM Finder is the Web Audio API, but working with it presented several challenges:

// Decoding large audio files without blocking the UI
const decodeAudioData = async (arrayBuffer) => {
  try {
    const audioContext = new (window.AudioContext || window.webkitAudioContext)();
    const audioBuffer = await audioContext.decodeAudioData(arrayBuffer);
    return audioBuffer;
  } catch (error) {
    // Fallback for older browsers or corrupted files
    throw new Error(`Audio decoding failed: ${error.message}`);
  }
};

Challenge 1: Browser Compatibility
Different browsers implement the Web Audio API with subtle variations. Safari, in particular, has stricter security policies that require user interaction before creating an AudioContext.

Challenge 2: Memory Management
Large audio files (up to 50MB) can quickly consume browser memory. I had to implement careful buffer management and progressive loading for batch processing.

Algorithm Accuracy vs Performance Trade-offs

For BPM detection, I integrated the web-audio-beat-detector library, but achieving 99.5% accuracy while maintaining real-time performance required significant optimization.

Dual-Algorithm Approach

class BPMAnalyzer {
  async analyzeBPM(audioBuffer) {
    // Primary algorithm - more accurate but slower
    const primaryBPM = await this.detectBeats(audioBuffer);

    // Secondary algorithm - faster estimation
    const secondaryBPM = await this.guessBPM(audioBuffer);

    // Confidence scoring based on agreement
    const confidence = this.calculateConfidence(primaryBPM, secondaryBPM);

    return {
      bpm: primaryBPM,
      confidence,
      alternatives: [secondaryBPM]
    };
  }
}

The Dilemma: Accuracy vs Speed

High-precision analysis takes 3-5 seconds for a 50MB file
Real-time feedback requires sub-second response times
Solution: Progressive analysis with immediate estimates

Web Workers for Heavy Processing

To keep the UI responsive during intensive audio analysis, I moved all processing to Web Workers:

// tempo-change-worker.js
self.onmessage = function(e) {
  const { audioData, tempoRatio } = e.data;

  // Heavy processing happens here without blocking UI
  const processedAudio = processTempoChange(audioData, tempoRatio);

  // Send progress updates
  self.postMessage({
    type: 'progress',
    progress: (processedChunks / totalChunks) * 100
  });

  // Send final result
  self.postMessage({
    type: 'complete',
    result: processedAudio
  });
};

This architecture enables:

Non-blocking UI updates
Real-time progress feedback
Parallel processing for batch operations

Handling Multiple Audio Formats

Supporting MP3, WAV, FLAC, AAC, OGG, and M4A formats wasn't just about file detection - it required understanding browser codec support:

const getSupportedFormats = () => {
  const audio = new Audio();
  return {
    mp3: audio.canPlayType('audio/mpeg') !== '',
    wav: audio.canPlayType('audio/wav') !== '',
    flac: audio.canPlayType('audio/flac') !== '',
    aac: audio.canPlayType('audio/aac') !== '',
    ogg: audio.canPlayType('audio/ogg') !== '',
    m4a: audio.canPlayType('audio/mp4') !== ''
  };
};

Challenge: Format-specific edge cases

FLAC files often have metadata that breaks standard parsing
M4A containers can contain different codecs
Variable bitrate MP3s require special handling for accurate BPM detection

The YouTube Analysis Challenge

One of the most requested features was analyzing YouTube videos directly. This presented both technical and legal challenges:

Technical Implementation

// Client-side YouTube audio extraction (conceptual)
const analyzeYouTubeURL = async (url) => {
  try {
    // Extract audio stream metadata
    const streamInfo = await getStreamInfo(url);

    // Process audio chunks without storing full file
    const bpmData = await analyzeStreamingAudio(streamInfo.audioURL);

    return bpmData;
  } catch (error) {
    throw new Error('YouTube analysis failed');
  }
};

Legal Considerations: By processing everything client-side, we avoid server-side downloading or storage of copyrighted content.

Performance Optimization Strategies

1. Progressive Loading

For batch processing, I implemented progressive loading to handle 50+ files without memory issues:

const processBatch = async (files) => {
  const results = [];

  for (let i = 0; i < files.length; i += BATCH_SIZE) {
    const batch = files.slice(i, i + BATCH_SIZE);
    const batchResults = await Promise.all(
      batch.map(file => analyzeFile(file))
    );
    results.push(...batchResults);

    // Allow garbage collection between batches
    await new Promise(resolve => setTimeout(resolve, 100));
  }

  return results;
};

2. Audio Downsampling

For BPM detection, full audio quality isn't necessary:

const downsampleAudio = (audioBuffer, targetSampleRate = 22050) => {
  if (audioBuffer.sampleRate <= targetSampleRate) return audioBuffer;

  const downsampler = new OfflineAudioContext(
    audioBuffer.numberOfChannels,
    audioBuffer.duration * targetSampleRate,
    targetSampleRate
  );

  // Resample to reduce processing load
  // ... downsampling implementation
};

UI/UX Technical Challenges

Real-time Visualization

Creating responsive waveform displays that update during analysis:

const renderWaveform = (audioBuffer, canvasElement) => {
  const canvas = canvasElement;
  const ctx = canvas.getContext('2d');
  const data = audioBuffer.getChannelData(0);

  // Efficient rendering for large audio files
  const step = Math.ceil(data.length / canvas.width);

  ctx.clearRect(0, 0, canvas.width, canvas.height);
  ctx.strokeStyle = '#00ff88';
  ctx.beginPath();

  for (let i = 0; i < canvas.width; i++) {
    const amplitude = data[i * step];
    const y = (amplitude + 1) * canvas.height / 2;

    if (i === 0) ctx.moveTo(i, y);
    else ctx.lineTo(i, y);
  }

  ctx.stroke();
};

Beat Visualization

Synchronizing visual beat indicators with detected BPM:

const visualizeBeat = (bpm) => {
  const interval = 60000 / bpm; // ms per beat

  setInterval(() => {
    // Flash beat indicator
    document.getElementById('beat-indicator').classList.add('flash');
    setTimeout(() => {
      document.getElementById('beat-indicator').classList.remove('flash');
    }, 100);
  }, interval);
};

Lessons Learned

Client-side processing is possible but complex: With careful optimization, browsers can handle sophisticated audio analysis
Progressive enhancement is crucial: Always provide fallbacks for unsupported formats or older browsers
User feedback prevents frustration: Real-time progress indicators are essential for long-running operations
Memory management matters: Large audio files can crash browsers without proper handling

The Result

BPM Finder now processes audio files entirely client-side with professional accuracy, supporting multiple analysis modes and maintaining complete user privacy. The technical challenges were significant, but the result is a tool that DJs, producers, and content creators rely on daily.

Key Stats:

99.5% accuracy with industry-standard algorithms
Supports files up to 50MB
Processes 50+ files in batch mode
Complete client-side processing
Works across all modern browsers

The journey taught me that with careful architecture and optimization, client-side audio processing can match server-based solutions while providing superior privacy and user experience.

Want to try it yourself? Check out BPM Finder and let me know your thoughts! I'm always looking to improve the tool based on user feedback.

Tags: #webdev #audio #javascript #webapi #privacy #musictech

Destiny Matrix: Unlock Your Destiny Through Sacred Numbers

陈宇翔 — Wed, 07 May 2025 01:50:25 +0000

Destiny Matrix: Unlock Your Destiny Through Sacred Numbers

As developers, we often seek logic and patterns. There's a website that combines ancient numerological principles with modern technology to provide users with in-depth personal analysis - meet Destiny Matrix.

What is Destiny Matrix?

Destiny Matrix is a 100% free platform that provides instant personal analysis based on numerology. The platform allows users to gain deep insights into their core energy, life path, relationships, and more by simply entering their birth date.

Key Features

100% Free Analysis: Get full access to your destiny matrix chart with no hidden costs
Instant Results: Receive your analysis immediately after entering your birth date
No Registration Required: Quick access without the need to create an account
Personal Analysis: Detailed insights into your core energy and spiritual blueprint
Life Path Analysis: Understand your purpose and key focus areas
Relationship Compatibility: Discover how your numbers affect your relationships
Multiple Language Support: Available in English, German, Spanish, French, Portuguese, Italian, Indonesian, Azerbaijani and Khmer

The Intersection of Technology and Spirituality

As developers, we might be curious about how such a platform works. Destiny Matrix combines ancient numerological principles with modern web technology to create a user-friendly interface that makes complex numerical analysis accessible and understandable.

User Cases

Spiritual seekers use Destiny Matrix to gain deeper insights into their life purpose and spiritual journey
Individuals at crossroads in life consult their destiny matrix for guidance on which path aligns with their spiritual blueprint
Couples check their numerological compatibility to understand the dynamics of their relationship better
Self-development enthusiasts use the analysis to identify their strengths and areas for personal growth
Teachers and coaches incorporate destiny matrix charts as tools for helping clients understand their innate tendencies and potential

A Developer's Perspective

From a technical standpoint, Destiny Matrix demonstrates how traditional knowledge can be combined with modern technology to create an intuitive and valuable user experience. The site's design focuses on immediacy and accessibility, without complex registration processes or paywalls.

This approach can inspire us to think about how we might create frictionless user experiences in our own projects while providing meaningful content.

Conclusion

Whether you're interested in numerology, looking for some guidance on life direction, or just curious to see how this type of analysis works, Destiny Matrix offers a simple and free way to explore.

As developers, we can appreciate the technical implementation behind it and how it transforms ancient wisdom into a modern digital experience.

Visit https://destiny-matrix.cc/ to begin your numerical exploration journey.

Have you used similar numerological tools? How do you think technology can better integrate with traditional wisdom? Share your thoughts in the comments!

Pokemon TCG Pocket Hub

陈宇翔 — Sun, 10 Nov 2024 11:46:10 +0000

Introduction

I'm excited to share Pokemon TCG Pocket Hub, an open-source platform that combines an interactive card simulator with comprehensive game resources in 8 languages. As the Pokemon Trading Card Game continues to grow globally, we saw the need for a unified platform that could serve players across different regions.

🎮 Key Features

Interactive Card Experience

Live Card Simulator: Experience authentic Pokemon card drawing mechanics in your browser
Daily Free Packs: Open two virtual booster packs daily
High-Quality Animations: Stunning 3D card effects and animations

Comprehensive Game Resources

Complete Card Database: Detailed information and high-res images for all cards
Meta Analysis: In-depth tier lists and deck building guides (SS to C tier)
Strategy Guides: Expert tips for both beginners and veterans

Global Accessibility

8 Languages Support:
- English
- French
- German
- Italian
- Spanish
- Portuguese
- Traditional Chinese
- Cantonese

🛠️ Technical Implementation

Built with modern web technologies:

Next.js 14 with App Router
Server Components for optimal performance
MDX for content management
i18n implementation
Responsive design

🎯 Top Meta Decks

Currently featuring detailed guides for popular decks:

Starmie EX Deck: 90 damage with just 2 Water Energy
Pikachu EX Deck: Consistent 90 damage output
Mewtwo EX Deck: Powerful 150 damage potential

🌟 Why We Built This

The Pokemon TCG community needed a centralized platform that could:

Provide accurate, up-to-date information
Support multiple languages natively
Offer interactive features for engagement
Serve as a comprehensive resource hub

🔮 Future Plans

We're actively working on:

Expanding language support
Adding interactive deck building tools
Implementing AI-powered deck recommendations
Enhancing the card simulator
Building more community features

🤝 Contributing

We welcome contributions! Whether it's:

Adding new features
Improving translations
Sharing deck strategies
Reporting bugs
Suggesting enhancements

🔗 Links

Website

Wrap Up

Pokemon TCG Pocket Hub is more than just a website - it's a community project aimed at making the Pokemon Trading Card Game more accessible to players worldwide. We'd love to hear your feedback and welcome your contributions to make this platform even better!

pokemon #opensource #webdev #nextjs #gaming

Escape Road Unblocked: A Browser-Based Police Chase Game with Next.js 14

陈宇翔 — Sat, 02 Nov 2024 08:43:22 +0000

Building Escape Road Unblocked: A Browser-Based Police Chase Game with Next.js 14

Hey DEV community! 👋 I'm excited to share my latest project - Escape Road Unblocked, a high-octane police chase game built with Next.js 14 and modern web technologies.

What is Escape Road Unblocked?

It's a browser-based racing game where players engage in intense police pursuits across various terrains. The game features auto-accelerating mechanics focused on precise steering control, making it perfect for quick gaming sessions.

Technical Stack

Framework: Next.js 14 with App Router
Styling: Tailwind CSS
Animations: Framer Motion
State Management: React Context
Internationalization: Built-in i18n support
Performance: Server Components & Static Site Generation

Key Technical Features

Server-Side Rendering
- Optimized initial page load
- SEO-friendly content delivery
- Improved performance metrics
Progressive Enhancement
- Auto-accelerating gameplay mechanics
- Touch controls for mobile devices
- Keyboard controls for desktop
Cross-Platform Compatibility
- Responsive design for all screen sizes
- Browser-based gameplay without installation
- Optimized for school/work environments

Performance Optimizations

Asset Loading
- Lazy loading for non-critical resources
- Image optimization with Next.js Image component
- Progressive asset unlocking
State Management
- Efficient game state updates
- Minimal re-renders
- Optimized collision detection

Lessons Learned

Browser Limitations
- Working within memory constraints
- Handling different browser capabilities
- Cross-browser compatibility challenges
User Experience
- Balancing game difficulty
- Creating intuitive controls
- Implementing progressive feedback

Future Improvements

Multiplayer support
Additional vehicle types
More challenging environments
Achievement system
Community features

Try It Out!

Visit Escape Road Unblocked to experience the game yourself. No downloads required - just pure browser-based gaming fun!

Contribute

The project is constantly evolving, and I'd love to hear your feedback and suggestions. Feel free to:

Share your thoughts in the comments
Report any issues you encounter
Suggest new features
Contribute to the codebase

webdev #javascript #nextjs #gamedev #react