DEV Community: Eoin McGrath

Walktober

Eoin McGrath — Sat, 10 Oct 2026 08:19:42 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

Walktober is a small reason to go outside. Photograph what you notice, complete quests, and fill your scrapbook with the season. Then put your phone away.

Take a pic of something notable on your autumnal ramblings. It is then converted into a sticker and added into your scrapbook.

Demo

🍂 walktober.eoinmcgrath.com

Code

💻️ github.com/eoinmcg/walktober

How I Built It

Everything runs in the browser, with no server and no API calls, and it works offline once the files are cached. All the AI is open-weight and runs through ONNX Runtime.

Cutout and sticker: U²-Net-P
The image is separated from its background by U²-Net-P, a small (about 4.5 MB, Apache-2.0) salient-object-detection network. It runs through onnxruntime-web (MIT) on WebAssembly inside a Web Worker, so the UI stays responsive. The worker decodes the photo, resizes it to 320×320, normalises it, runs the model, and sends back a soft mask. The main thread turns that mask into alpha. The sticker (rounded white border, thin black outline, drop shadow) is plain canvas code on top of that alpha. It involves no extra model.

Classification and matching: CLIP via transformers.js
In order to make things interesting I decided to add a number of quests. Basically, take a pic of an acorn, mushroom etc. This requires a way of matching the sticker to the quest. I first tried MobileNetV2, which is lightweight but only has around 1000 ImageNet classes. This simply didn't cut it when attempting to classify images. After some experimentation, I settled on CLIP (Xenova/clip-vit-base-patch32, an ONNX conversion of OpenAI’s MIT-licensed model) through @huggingface/transformers. CLIP embeds images and text into the same vector space, so the cutout can be compared against any text description by similarity, without retraining.

Text embeddings: precomputed at build time
scripts/build-text-embeddings.ts loads CLIP’s text encoder in Node (AutoTokenizer plus CLIPTextModelWithProjection) and embeds every quest from quests.json once. It writes the vectors to public/embeddings/text-embeddings.json, rounded to 5 decimals to keep the file small. At runtime the browser loads only the vision encoder and compares the cutout’s embedding with those stored vectors. The text encoder never ships to the phone, which saves download size and memory. The build script and the runtime must use the same CLIP model, or the vectors live in different spaces and the similarities mean nothing.

Why Does Open Innovation Matter?

Purely Local & Offline-First

The core mandate of Walktober was 100% on-device execution. A closed-source API couldn't satisfy this requirement. Because model files and WebAssembly runtimes are served as standard static assets, the app operates without reliance on external servers. Photos are processed locally - ensuring privacy, instant response times, and uninterrupted outdoor use without requiring cell coverage.

Architectural Freedom

Open weights allow developers to reshape system architecture rather than merely call remote endpoints. By leveraging CLIP's decoupled vision and text encoders, I offloaded text encoding to build time. Furthermore, using open weights meant being able to swap U²-Net-P (4.7 MB) for larger alternatives or replace MobileNet with CLIP freely. Such decisions aren't possible with black-box APIs.

Debuggability & Inspectability

Open source makes edge cases solvable. When the classifier threw an unexpected JSON parse error, I diagnosed it directly by inspecting the transformers.js source code. I discovered that the library treated image classification as a multimodal task by looking for a tokenizer file; my development server was catching missing requests and returning an HTML fallback page with a 200 HTTP status code, triggering the JSON error. Understanding this permitted a clean workaround building the pipeline directly from its individual component parts.

Seamless Composition

U²-Net, CLIP, ONNX Runtime, transformers.js, and Nuxt originate from distinct maintainers, yet seamlessly interoperate through open standards (like ONNX) and permissive open-source licenses. Each piece remains independently swappable—such as introducing a plant-specific classifier later—without rewriting the core application.

Prize Categories

General Category

Why I built a local-first PDF toolkit using Nuxt and OPFS

Eoin McGrath — Tue, 06 Oct 2026 09:25:51 +0000

Every time you want to compress an NDA, sign a lease agreement, or compare contract drafts online, mainstream tools (like Smallpdf or ILovePDF) ask you to do the exact same thing: upload your sensitive document to their remote server.

Even when services use encryption in transit and promise to delete files after a limited period, uploading confidential documents to a remote server still means entrusting those documents to a third-party service. Encryption in transit protects the transfer; it doesn't eliminate the need to trust the system that receives and processes the document. Furthermore, depending on the type of files and your use case (e.g., legal or medical), uploading them to a third-party service may not be an option due to privacy, confidentiality, or regulatory requirements.

To solve this, I built beePDF, a 100% client-side Progressive Web App (PWA) where document processing happens entirely in the browser and documents are never uploaded to a remote server.

Here is a breakdown of how it works, why I chose OPFS coupled with IndexedDB, and the architectural tradeoffs of building local first document tools on the modern web platform.

🛠️ The Tech Stack

Framework: Nuxt (Vue 4, TypeScript, Vite)
PWA & Offline Support: @vite-pwa/nuxt + Service Workers
In-Memory File Processing: pdf-lib, PDF.js, native Canvas API
Local Persistence: Origin Private File System (navigator.storage.getDirectory())
Styling & UI: Pico CSS. Yes, I'm a dinosaur that prefers to write minimal CSS rather than reaching for tailwind.

Having previously worked with Next.js, I have to say that Nuxt is a breath of fresh air. If you haven't already taken it for a spin, I cannot recommend it highly enough.

💡 Why OPFS (Origin Private File System) Changed Everything

When building a local-first web app that handles binary documents, local persistence becomes a major bottleneck:

LocalStorage: Limited to ~5MB-10MB and synchronous text-only storage completely useless for binary PDFs.
IndexedDB: Excellent for structured metadata and smaller binary objects, but less natural for treating large documents as persistent files with efficient byte-level access.
File System Access API: Great when an app needs to work directly with files in the user's filesystem, but access requires user permission and is subject to browser security restrictions.

Enter OPFS

The Origin Private File System (OPFS) provides a private, origin-scoped filesystem designed for persistent file-like data, with low-level byte access and optimized in-place writes. It also offers synchronous access handles inside Web Workers for performance-sensitive workloads.

// Accessing the local OPFS root directory
const root = await navigator.storage.getDirectory();
const draftHandle = await root.getFileHandle("working-draft.pdf", { create: true });

// Writing binary data stream directly to local disk
const writable = await draftHandle.createWritable();
await writable.write(pdfArrayBuffer);
await writable.close();

Why OPFS is crucial for PDF processing:

Zero Permission Prompts: Because the directory is private to https://beepdf.app, the browser doesn't spam the user with permission modals.

Blazing Fast Disk I/O: OPFS provides direct byte-level file streams. In Web Workers, you can even use createSyncAccessHandle() for near-native, synchronous file read/write operations.

Storage Quotas & Cleanup: Files persist across browser reloads (so you don't lose your working document if you accidentally close the tab), but automatically honor the browser's origin storage quota.

⚙️ How the Processing Pipeline Works

When you drag and drop a PDF into beePDF:

Local Intake: The browser reads the File object into an ArrayBuffer in memory.

OPFS: The document is immediately stored in the local OPFS workspace directory.

Meta data and a very small thumbnail are stored in indexDB. This also makes searching and tagging trivial.

Web Worker Offloading: Tasks like rendering page thumbnails, extracting plain text / Markdown, or running word-level diffs are offloaded to Web Workers to keep the UI running at 60 FPS.

Client-Side Export: Modifying or signing a document creates a fresh Uint8Array in memory, which triggers a direct client download via a URL.createObjectURL Blob.

Airplane Mode Test: You can load beePDF, turn off your Wi-Fi or disconnect your internet completely, and merge, split, compress, or sign documents offline.

🤔 Challenges & Lessons Learned

Modern browsers provide a remarkably rich set of capabilities, many of which can be accessed by web applications through standardized Web APIs. Building pure client-side file tools, however, isn't without its limits:

Browser Memory Ceilings: Processing massive 500MB+ scanned PDFs inside browser JS can hit V8 heap memory limits on lower-end devices.

Main Thread Blocking: Heavy image compression or canvas manipulation must be offloaded to Web Workers; otherwise, rendering high-DPI canvases will freeze the UI thread.

💬 Let's Discuss!

I’d love to get feedback from the DEV community!

Have you used OPFS in production yet? How does it compare to IndexedDB for your use cases?

What client-side tools or WASM integrations would you like to see next?

Check out the live app here: https://beepdf.app

Frontend Challenge: World Asteroid Day, 30th June

Eoin McGrath — Mon, 23 Jun 2025 19:05:43 +0000

This is a submission for Frontend Challenge - June Celebrations, Perfect Landing: June Celebrations

What I Built

A celebration of World Asteroid Day, 30th June

🌌 View live here

Journey

I've wanted to learn Tailwind CSS for a while, so this challenge was the perfect opportunity to expand my skills. Space has always fascinated me, so choosing World Asteroid Day as my inspiration was a natural fit. My goal was to create an educational and inspiring site for a younger audience, which led to this interactive landing page celebrating the day.

It Features:

☄️ Real asteroid field
🚀 Space travel
ℹ️ Interesting facts
❓ Interactive quiz
🧑‍🎓 Downloadable personalized certificate.

Tech used

React with typescript
R3F for animated asteroid field
Tailwind CSS for styling
Google Gemini (free plan) for image generation

I had a blast creating this landing page, and I hope you enjoy it too!

MIT license

Github repo

Code a mobile friendly game with LittleJS

Eoin McGrath — Fri, 28 Feb 2025 11:55:22 +0000

Hey all! I hacked together a super simple game last weekend, which I thought lent itself to a tutorial.
So, I also wrote up a tutorial, which can be found here:
https://eoinmcg.github.io/little-ski/tutorial.html
and the game:
https://eoinmcg.github.io/little-ski

If anyone has the time and inclination to check out the tutorial, I'd really appreciate any feedback!
Thanks!

p.s. the github repo: https://github.com/eoinmcg/little-ski/

Mountains

Eoin McGrath — Fri, 02 Aug 2024 15:24:07 +0000

This is a submission for Frontend Challenge v24.07.24, CSS Art: Recreation.

Inspiration

As developers we can spend too long in front of our screens.
Take a break. Look up!

Demo

See it in action.

Journey

I expanded my knowledge of CSS animations, that's for sure.
On previous projects, I've only scratched the surface of what can be achieved with CSS animations. This exercise give me a chance to experiment. And most of all, have fun ;)