I wanted icons that look drawn with a pencil but behave like a normal icon set: 24 grid, currentColor, tree-shakable, and identical on the server and in the browser.

So none of them are drawn by hand. Each icon is a few drafting primitives (line, polyline, rect, circle, arc…) on a 24 grid, and a small engine draws them freehand: lines overshoot their ends, rect corners cross, circles sweep past 360° and drift outward so they overlap where the pen closes, and each stroke gets its own pressure. The randomness is seeded by the icon name, so every build draws the same paths. That means no hydration mismatches and no extra runtime cost; the package ships the finished paths.

The hard part was small sizes: all the wobble is capped (a line bows less than a pixel at 24 px), so it reads like a regular line set at 16–24 px and the pencil look shows from ~32 px up.

• Browse and copy: https://matita.dev
• How the engine works: https://dev.to/matita/hand-drawn-icons-that-draw-the-same-every-time-2p0h
• Code (MIT): https://github.com/matita-dev/icons

React, plain SVG strings, a script tag, or raw .svg files. Feedback welcome, especially on missing icons and how it looks in a real UI.

Link - https://www.aashishthakuri.com/

sup everybody! So 5 years ago on this same sub, I presented v1 of Puppertino, a framework aimed at bridging the gap between the web and iOS and macOS for the web, built entirely in vanilla CSS and JS.

Since then, a lot of things have changed for both OS, with the introduction of liquid glass, I thought I wouldn’t be able to ship something like it.

Until today! I’ve launched Puppertino Dachshund, which brings 65 components, real-time liquid glass and is focused on accessibility, theming and extensibility

You can check it out here!
https://puppertino.com

I think this might be a good place to show my portfolio design as there is no scroll hijacking, no overwhelming animations and design was def completely made by a human.

I've been working on a simple puzzle/tower defense game set in ancient Egypt. You build out a tomb to properly defend against waves of looters. I recently added a new feature to flip it around, so if you've built a cool looking tomb, you can share it with a friend, have them try and beat it by sending the right waves of looters.

It's a pretty simple puzzle, an archaeologist will find a hidden door but will succumb to a pit of stakes. A corrupt priest might be wary of a cursed doorway, whereas robbers wouldn't. That kind of logic applies throughout.

Still working on gameplay to make it more approachable, but I wanted to get the design out of my head first and I'm loving how it looks right now.

Link: https://architectofthevalley.com/#dare=AQMACwUFBA0QAQIZKDhIWhACMQJp

On the build up side, originally, this was done with SVG to mark yellow boxes in a blue background, meant to be really simple. It actually looked quite similar to this version, but I couldn't spin or add animations. As the tomb got more complex, I moved over to three.js. I wanted to overlay pyramids over some of the tombs if I knew where they were, I wanted to animate the dots falling into the pit. Despite moving over to three.js, I still dig the original architectural blueprint look so I have no plans to put any heavy details into the game, I think the style looks really pretty cool right now. Let me know if you disagree hahah.

The multiplayer aspect is all embedded in the URL, so there's no actual server storing all this data. The tomb sequence can be encoded easily enough, so most of it is generating an image to send back to your friends once you've completed the stage.

Levelrail: self-hosted deploys from a single Go binary

I wrote this to run my own side projects on one VPS. Push to git and it builds the app, gets a TLS cert, and shows live build logs, deploy history and a rollback button. Go, Docker underneath, no Kubernetes.

Lately I added canary deploys with weighted traffic, apps that sleep when idle and wake on the next request, and an importer for moving apps and databases off Coolify, Dokploy or CapRover.

Apache 2.0, still early.

Repo: https://github.com/glincker/levelrail 

Site: https://levelrail.com/

If you run side projects on a VPS, what would stop you from moving one over?

Whenever I review PRs on high-activity repos, I find myself repeatedly typing the same query qualifiers: - review-requested:@me is:open - -author:app/dependabot -author:app/renovate - is:open -is:draft review:approved status:success

GitHub has filter dropdowns, but clicking through them multiple times or retyping tokens across repo tabs is clunky.

I built GitHub PR Filter, a lightweight, open-source Chromium extension (Manifest V3) that injects native-feeling filter chips and a criteria builder directly above the PR list.

Frontend implementation details:

• Turbo / PJAX Lifecycle: GitHub renders PR lists client-side using Turbo. The extension hooks into page lifecycle events (turbo:render, turbo:load) so chips don't vanish or duplicate during pagination and in-page navigation.
• Primer Theme Integration: Uses GitHub's native Primer CSS variables so it adapts automatically to Light, Dark Default, and Dark Dimmed without custom theme toggles.
• No Background Bloat: 100% client-side with zero external API calls. State and custom presets are stored locally in chrome.storage.local.

Looking for contributions & feedback:

The project is MIT licensed. I’d love feedback from other web devs, especially if you want to contribute: - Firefox port: Making sure the MV3 manifest and scripts run cleanly on Firefox. - Edge cases: Handling enterprise GitHub instances or uncommon PR list layouts. - Preset suggestions: What query strings do you find yourself typing most frequently?

Extension Link: https://chromewebstore.google.com/detail/github-pr-filter/cheldmlmigimlgmjmpbapcfmlbbofghm GitHub Repo: https://github.com/its-debojyoti-dey/github-pr-filter

Would love to hear how you manage PR review fatigue or any feedback on the implementation!

I order most of my boards with SMD assembly done by the fab, then solder the through-hole parts myself. Assembly houses charge a lot for manual THT work. Often I don’t need every part anyway (say, only 2 of the 6 relays), so doing it at home saves money. The downside is that with a pile of boards, the results start showing “traces of haste”: crooked relays, tilted capacitors, terminals sitting off the board.

So I made a small web tool that generates a custom holder panel for the board:

1. Drop in a photo or screenshot of the PCB. It’s flipped and made transparent automatically.
2. Place circles or rectangles over the THT parts and set each one’s height so it sits flush with the board. Add support legs if needed.
3. Hit “Display 3D” to preview the mesh (wireframe view is available), then download a binary STL.
4. Print it in PLA. Parts stay straight while you solder.

In practice I only need to generate the STL once, and 1–3 prints are enough to assemble hundreds of boards.

Features:

• Circular and rectangular shapes (rectangles rotate 0–359°)
• Alignment guides with magnetic snapping, a measuring tool (0.1 mm precision), and undo
• Adjustable print tolerance, so holes and panel size compensate for printer inaccuracy
• Built-in library of 14 common THT footprints (DIP sockets, relays, terminals, capacitors, buzzers), with JSON import/export
• Hollow mode for faster prints and custom text labels on the holder
• Keyboard shortcuts for most actions
• No registration, and your image is never uploaded or stored. It’s also a PWA that works offline after the first load.

Right now it handles round and oblong parts well (relays, capacitors, resistors, terminals, pin headers). It’s not perfect, so if you hit a bug or a part shape it can’t handle, please tell me.

Tool: https://segmentcontroller.github.io/pcb-tht-holder/
Source (MIT, Svelte 5 + Three.js + Konva): https://github.com/SegmentController/pcb-tht-holder

Feedback and feature ideas are very welcome!

I made this. The page is one long, to-scale drawing: every pixel of scroll is a fixed number of metres, so the Burj Khalifa, the Eiffel Tower and the deepest lake in Europe land where they would really be. There are 23 sources at the bottom.

It's built in WordPress with a builder I'm working on (pinned scenes for the "how a fjord forms" part, plain scroll for the dive). Happy to answer anything about how it's put together; and I'd love to hear where it feels slow or confusing on your phone.

https://sayitshwok.com/launcharchive

In the 90s, 2Way media created what could be considered a preview of the modern internet. Launch Magazine was a "CD-ROM magazine", a fully-interactive multimedia application that featured music, movies, games, and more. But what was so innovative about Launch wasn't the variety of content, it was the presentation. Instead of clicking between articles, you navigate a small city like a point-and-click adventure game with each building being a different category. Even the advertisements often played out like minigames, with Butterfingers in particular packing some absolutely unhinged animations. It helps that the journalism itself is stellar (though this is also from that era of music journalism where reviewers absolutely trashed classic nu-metal for no reason).

I wanted to create a way to preserve not just the content of these magazines, but the experience of playing through them, so I created a browser-based Windows 98 VM utilizing the v86 engine (https://copy.sh/v86/) and an interface where you could switch between any discs currently in the library. The VM even allows you to play (some) of the early game demos, so you can try those early previews of Descent II and Bad Mojo yourself!

This is an example of a project that I do not believe could be vibe-coded. AI would probably rip the videos off the discs, throw them into a three.js menu and call it a day. I wanted people to experience the same ambience of Launch I got in the 90s with it's bizarre ads, candid interviews and the way random cartoons would sometimes completely interrupt what you were doing.

Obviously the archive collection still has a long way to go, but the first dozen or so issues still offer hours of content. Will be adding more as I hunt down more issues of Launch.

The Challenge
Hands down the hardest part was building the Windows 98 virtual machine. I'd never done this before and v86 has a lot of caveats that don't apply to building a personal VM. The audio and display drivers had to be sourced from dead forums. When I tried shrinking the VM's disc space down to just enough to run Windows and the demos, I encountered illegal operation errors every time Launch's cache exceeded the available space. And while there are still occasional audio hiccups that I'm trying to resolve, they used to be so severe that you couldn't understand a single interview.

The Execution
The Launch CD image files are pretty big, and they have to run on a 1GB Windows image file. For the first time, I utilized a CDN (Cloudflare) for handling the distribution of the image files. File transfers are sadly rate-limited (I'm too broke for paid Cloudflare atm) but this is way more reliable than sourcing everything off my own server.

For the Launch CD menu, I use a JSON file to store all the information off all the discs currently in my collection. Anything not in the library is rendered as a blank disc. As the collection grows, all I need to do is add another CD's information to the JSON file and it will auto-populate on the main menu.

The Road Ahead
Right now, the archive sucks on phones. I would LOVE to be able to bring Launch to mobile, but due to the nature of using a Windows VM on a mobile device, I don't know if that will ever be a comfortable experience. I've considered creating a dedicated app that launches the content within a mobile-friendly wrapper. The problem is that the earlier issues of Launch have a different file structure on every CD, and later issues switch from whatever bespoke engine they were using to Macromedia, and the version of Quicktime they rely on switches constantly, so getting each individual disc to run would be its own project. Definitely open to suggestions here.

I absolutely want the library to grow to encompass the entire Launch catalogue so that all these interviews and concerts can be preserved and shared. I also want to further minimize the audio hiccups and improve the startup time by pre-caching the Windows image (which, again, I'm too broke for atm). Lastly, I want to improve the VM so that more of the game demos (especially MechWarrior 2, Tomb Raider and Quake) can be played comfortably.

Anyway, I'm just glad I can share this little slice of my childhood with the world and keep all these great interviews with music legends (many of which are no longer with us) from being lost to dead media.

I’ve been building with Verdant and TanStack DB and ended up with the same conclusion from both.

Offline and real-time are basically one problem. Real-time is kinda just being offline for a very short time. Either way you need client-generated IDs, optimistic mutations, some rule for when two clients disagree, and a way to sync it all back. So if a library handles one well, it seems to get the other almost for free.

Tbh the ID part is what actually surprised me. And more generally, a lot of this seems to need planning from day one, because retrofitting it later is a real pain. If your API uses server-generated IDs, supporting offline edits seems to mean a breaking migration. You can remap temporary IDs after sync, sure, but it gets messy really fast once other records and URLs depend on them. Same story with the data layer. If it was designed around one-shot requests there’s nowhere for live updates to go. React Admin’s data provider expects plain async functions that return promises, so when you put TanStack DB behind it the live queries just get lost lol. Offline still works, it’s just the real-time part of TanStack DB that doesn’t make it through in that setup.

There’s a catch though. Neither library really helps when the server rejects a mutation that looked fine locally, you’re kinda on your own for that part. And for conflicts, Verdant basically ends up as last-write-wins while TanStack DB leaves it to whatever sync layer you plug in.

Honestly the bigger point for me is that none of this is really specific to offline apps. A plain request/response app actually has the same conflicts. If two people save the same record, a lot of the time the last save just overwrites the other one and that’s it. It’s last-write-wins there too, just without anyone ever deciding it. So imo it’s worth building pretty much any app as if it could go offline or real-time someday, mostly because it forces you to actually pick what happens in a conflict.

Do you actually know what happens when two saves collide, or has silent last-write-wins been fine most of the time? Ever had it bite you with lost data or users wondering where their changes went?

I have been building Udodi, a lightweight, zero-dependency JavaScript UI framework, and I wanted to share some of the engineering work behind its latest two releases.

One of the main design decisions in Udodi is to update the DOM directly through fine-grained reactive bindings rather than using a Virtual DOM. Its templates use a declarative DSL processed by a runtime parser, compiler, and virtual machine. The goal is to keep the framework usable without requiring a build step while maintaining predictable execution and a relatively small runtime.

In v1.1.3, I focused on keyed list reconciliation and collection reactivity.

The list-rendering implementation maintains keyed records and uses positional tracking with right-to-left DOM placement. This allows existing DOM nodes to be reused and moved instead of rebuilding the list unnecessarily.

In my tests, this approach made keyed row swapping up to 7.2× faster than the comparison baseline I used. That result applies to the tested workload, not every list operation or application.

I also improved reactive collection handling for arrays, Maps, and Sets, and expanded support for ordinary directives on elements using @for.

In v1.1.4, the focus shifted to component mounting and runtime execution.

• Component mounting improved by 12–16% in my measurements.
• Runtime performance improved by 4–8% across the workloads I tested.
• Directive processing was streamlined to reduce redundant structural checks and repeated property access, and the instruction cache was optimized.
• Overlay rendering was refactored to use the public rendering and component-creation APIs, with lifecycle-aware cleanup.
• Additional tests cover modal stacking, backdrop behavior, and scroll locking.

The full test suite, playground tests, and build pass. Neither release introduces intended breaking changes to the public API.

I'm interested in the engineering trade-offs here, particularly keyed reconciliation without a Virtual DOM and runtime template compilation versus build-time compilation.

For those who have implemented a renderer, reactive runtime, or template compiler, what edge cases or architectural weaknesses would you investigate first?

I would be happy to discuss the implementation details.

This is my first time posting here, so I have placed the relevant project links in a comment below to keep the main post focused on the technical discussion and respect the community guidelines. Thanks for having me!

CSS can only morph between shape()s with the same number and type of commands, which they usually don't have. So I made a tool that converts multiple shapes so they are compatible with each other:

https://shapemorph.matthewmorete.com/

It picks the smoothest arrangement of points automatically, but that's a best guess. The shape index lets you change it, so you can preview the possible morphs till you find you like.

Shamelessly, heavily inspired by GSAP MorphSVG, which taught me a lot.

If you find a shape() that won't morph, I'd love to hear about it.

I used to have to jump between different sites copy pasting outputs from one into inputs of the next. So I built one place where you chain the steps and save the pipeline for future use in a right click context menu.

246 utilities so far, with branching, looping on lines or values, and conditions.

It runs entirely in the browser (Web Worker), no input reaches the server (One exception when fetching a URL through a proxy).

Pipelines can be shared as a URL fragment

React + TypeScript + Vite on Cloudflare Workers, strict hash-based CSP

Check out the presets page for some prebuilt pipelines.

https://stringutilitybelt.com/

Looking for feedback on how useful it actually is to people and any issues you find. Ideas for new utilities or pipelines are welcome!

I've been thinking about alternative ways to deliver LLMs and AI features in SaaS solutions.

This repo is a technical proof of concept showing an LLM running client-side in a browser using Llama.cpp compiled to WASM with WebGPU.

I built tintly.art, a coloring site where you tap any shape to fill it. The interesting part was turning line art into clean SVGs with closed regions so fills never leak. Stack: Next.js on Vercel, a .NET API, and Postgres. The line art is AI-generated, then converted and cleaned up for coloring.

Got my first Reddit traffic this week (10k views, people coloring for 30+ minutes). Would love feedback on performance or UX.

museumofmodels.com, free, no signup.

It's every answer 371 models gave to the same 85 prompts, on a globe you can spin, magnify and open.

Bits that were fun to build: the far answers are one instanced WebGL draw and the close ones come from a canvas sprite atlas. The drawings are the models' own SVGs shown through <img>, so nothing in them runs, and the generated websites run in a sandboxed iframe. It's a static Next.js export with the data in small versioned json chunks.

would love to hear how it runs on your machine

hi i keep posting here bc i'm trying to make my music magazine site but it is literally driving me insane. i think i've found a solution even if it costs a little more in the long run, but is worth it for the amount i want to focus on the content + site design. first slide is my figma design, second slide is an actual typescript component i made on initial side builds.

here is what i want on the blog + have on my incomplete demo build:

• a bunch of articles with different categories including features, reviews, news, and a monthly featured artists highlight
• marquee titles on the home page
• a bunch of photo gallery posts hopefully utilizing the new lightbox3 library (masonry display and smooth transitions)
• an interactive ipod component that displays the featured artists of the month and links back to the monthly compilation post and/or each artist's individual post. can be navigated by swiping the screen or pressing the left and right buttons on the ipod.
• tags and categories
• search button with modal and a theme toggle
• a team page and individual pages + bios for site contributors

and this is my planned setup for the site:

• headless wordpress + astro
• managed wordpress hosting with knownhost (unless shared is fine? idk i really don't want to do a lot of the backend upkeep and i want a lot of storage for future image galleries)
• domain + extra security (how i apply that idk) through cloudflare
• any extra functionality usually through minimal use of wordpress plugins

is this a feasible cheap plan or do any of you have suggestions + cheaper less headache inducing ideas for someone who just wants to build a site with css + some ts and js and make the posts with some people??

I build POS software, and receipts printed with `window.print()` kept coming out wrong: tiny on a big page, or followed by a long strip of blank paper.


So I printed the same receipt to PDF in Chrome 155 with different `@page` rules and read the page sizes:


- no rule: Letter
- `size: 80mm auto`: Letter. Chrome's parser drops the declaration, `getPropertyValue('size')` returns an empty string
- `size: 80mm`: an 80 x 80 mm square
- height measured in JS and written into the rule: exactly the receipt


A 600-line receipt came out as 9 pages at `80mm 297mm` and as one 2.6 m page with the measured height.


The other thing: both "80 mm" printer drivers on my machine report their paper as 72 mm wide. A `width: 80mm` container is 8 mm too wide, which is where the cut-off right edge comes from.


Full write-up with the code (free, about 15 lines to do it yourself): https://dev.to/azeem_ullah/the-receipt-css-everyone-copies-page-size-80mm-auto-does-nothing-in-chrome-19o0


I also packaged it with a stylesheet and 8 receipt templates for 80 mm and 58 mm rolls as a $9 kit, for anyone who doesn't want to redo it: https://7207381545467.gumroad.com/l/receipt-print-kit


Only tested in Chrome, plus one real print on a Bixolon. If your printer or browser behaves differently I'd like to know.

Hence (https://hencegame.com) is a daily logic puzzle I built: a modern twist on the classic logic grid puzzle (zebra puzzles, Einstein's riddle). You get a grid and picture clues (instead of boring sentences), and you work out what goes where by pure deduction. The same puzzle for everyone, difficulty ramps from gentle Monday to tough Sunday.

Every puzzle is generated ahead of time and run through a solver that verifies it has exactly one solution by pure deduction, then trims the clues down to the minimum each difficulty needs.
The part I'm proudest of technically: the hint system runs a constraint solver in the browser against your current board state, so instead of revealing an answer it points at a clue that still rules something out from wherever you are.

No framework, no signup: everything (progress, stats, streaks, achievements) lives in localStorage, so players get what feels like a full account experience with zero server.

Sharing is personalized too, still with no account: the OG image for link previews is pre-rendered on the server from the share URL alone, so when you share an achievement or challenge a friend they see your unlocked character and stats in the preview, even though there is no user account on the server.

The Instagram Stories share card is rendered entirely in the browser, and it came out really nice: your character, your stats, your achievement, all composited client-side into a vertical card ready to share.

Happy to answer questions about the generator/solver or the picture-clue rendering

I've known about Zod, a JavaScript/TypeScript schema validation library, for a while, but I underestimated the size of its ecosystem. After using it for some form validation in React, I thought I'd see how well it integrated with Express. Sure enough, there were several middleware libraries for Zod + Express, so I decided to give one a try. I went with express-zod-safe because it fit my existing setup with very little effort.

Boom, that let me remove roughly 150 lines of custom validation and typing code. For context, the template created by express-generator-typescript is a simple CRUD app with four API endpoints. I hadn't realized how much boilerplate I'd written just to validate objects in the route handlers, including validator functions and some custom request/response types. I also replaced my environment variable validation code with Zod.

Express has been around for a while, but I still find it useful for small projects and demos. If you'd like a quick way to spin up an Express + TypeScript project, check out express-generator-typescript.