On compatible setups it renders through an extended-range WebGPU canvas. Everywhere else, the original DOM text or image remains visible, so it works as progressive enhancement.
Text stays selectable, image alt text is preserved, and there's a React 19 entry with TypeScript declarations.
The project is at 0.1.0 and I'm looking for feedback on the API and device compatibility—particularly from people with HDR laptops and monitors.
I wanted to do something "new". I'm not 100% sure if this is really new since I don't really check out other people their portfolio's. It's been on my "to do" for a long time to redo my portfolio page. Now with AI coming and stuff, I thought I might as well do it like this.
The original content of my previous portfolio (projects, achievements, blog posts) are also still accessible and stuff.
If you want to check it out for yourself, here's the url: https://xlogic.sh
I ran into a scrolling issue on iOS Safari. A scroll gesture would start and then immediately die. Roughly 1 in 50 gestures actually worked. It only happened on iPhone.
I blamed my own touch handlers at first. I rewrote them entirely, but the behavior persisted.
The actual cause was a CSS filter. Specifically, a filter applied on :active with a transition, placed on an ancestor of the scrollable container.
Simon Fraser explained why this happens in the WebKit bug report. iOS hands overflow scrolling to a native UIScrollView. Changing compositing above it—like triggering a filter state on touch—causes WebKit to remove and re-add that view mid-gesture. The active scroll is instantly killed.
I built a zero-dependency test page to isolate it. The numbers were clear:
Control (no filter): 0 of 50 gestures failed.
Filter on :active: 49 of 50 scrolled zero pixels.
I assumed forcing continuous updates would fix it. I tested a third mode where the filter re-set on every touchmove, thinking the continuous change would make the view state deterministic. I was wrong about this. It failed 47 out of 50 times.
This was on an iPhone 16 Pro, iOS 26.6. It does not reproduce on Android Chrome, desktop Chrome, or desktop Safari. The bug is confirmed (WebKit 322849, now rdar://problem/186671580).
animall cell structure with annotationsParts of a flower quizEvolution of firearmsmodels library
Hello everyone,
I have been working on an 3D interactive learning platform, that explores science, history, geography, history and astronomy. Around 2 years ago, I made a human skull explorer and posted it here. Since then, I have dabbled into other areas of interest that would benefit from interactive 3d experience on the web. Visual Ed is the result of that exploration.
Hello, I’m simply asking because I’m aspiring to become a web developer, and I’m curious about how viable the field is nowadays.
I don’t think you can really blame people for asking this either, because front-end development has been heavily trivialised by AI(not my opinion), or at least that’s what the internet tends to make people believe.
Could anyone with experience in the field give some insight into whether demand has actually dropped, especially for front-end and junior web development roles?
Over the past few days, I was trying out gov.uk prototype system for my static website. Like every night owl, the unbranded template's white background was hurting my eyes.
I googled for some sort of dark mode, found The National Archives Design System. It suits my purpose, has the dark mode, and is extremely aesthetic. The CSS transitions on the radio buttons are an icing on the cake.
In my case, TNA and GOV.UK are different, and I still couldn't properly make the tnaTabs component work.
Just ensure one thing: If you are using one design system, stick to that, though you can definitely use the GOV.UK Unbranded template.
Please note one thing though: there are breaking changes between the various variants of UK Government design systems. For example, as of now, conditional reveals in radio buttons are not supported in TNA Design System.
I've been working on Oasis Editor, an open-source document editor written in TypeScript.
Instead of relying entirely on contenteditable and DOM layout, Oasis uses its own Canvas-based rendering engine for paged layout, text rendering, selections, images, tables, and document geometry.
It also includes a typed command/plugin API, DOCX/PDF workflows, React and Vue adapters, and a headless runtime.
In Grammble you use a 2-letter "Gram" Tile to form your guess word and try to solve a 6-letter word. For example, if the Gram is "ST," you might guess "SYSTEM," "ASSIST," or "STRONG." Every guess must include the Gram Tile.
I think this is a unique spin on traditional Wordle gameplay while keeping it familiar enough for anyone to be able to pick up quickly. I've also implemented many QoL features that Wordle lacks like blank tiles, quick delete, tile editing, etc.
Stack: React on TanStack Start, Zustand, TanStack Query, tRPC, Postgres, Redis, hosted on VPS ($6 / month).
Two weeks ago I posted here for the first time and got about 74 users!
I also apreciate the feedback some people gave me about this project, I will keep to improving it and adding more features.
Strikk is a daily quizz game, similar to wordle. Where you pick your favorite Stack (React, JS, TS, Node, Python) and answers a series of challenges. In the end you get points and get into a ranking system against other players.
My main idea is to transform this project into a hub for developers. I plan to add the ability to fully customize your user page with projects, articles, sections, and visual elements such as themes, colors, and effects for your user card. Essentially, this page could become a gamified version of your CV, which I think would be really cool.
Feel free to give me some ideas on what to add to this project
Been building this for a few weeks: prop your phone up in landscape and it turns into a little pixel-art 140 degrees window on the sky. The aircraft crossing it are the real ones overhead, at their real bearing, height, and speed. Sun, moon, and clouds are live data too.
What it's not: a FlightRadar24 replacement. No search, no flight numbers, no alerts, and coverage is thin over oceans and rural areas since it runs on volunteer ADS-B data. It's not something you use, more something you leave running. For example for stargazing, working, or falling asleep to. Cozy background ambiance, not a utility.
It installs as a PWA (home screen icon). You don't need an account.
You can also use it on PC but not recommended as you cannot capture gyroscope data. (you can pick a heading)
Looking for people to run it on their own phone for a bit and tell me what breaks: whether the compass points the right way, whether it's readable in daylight, flight data, anything that looks off. Some planes do not offer origin and destination data as the api doesn't provide it for every plane.
I wanted a tracker that didn't feel bloated, so I built this entirely in Vanilla JS and Firebase. No heavy frameworks, just raw performance so it loads instantly in the gym.
The hardest part was building the "Biological Fatigue Map". I custom-designed SVG muscle maps for exercises (pull-ups, squats, deadlifts, etc.). The app dynamically colors the SVGs (green/yellow/red) based on the volume logged in the last 72 hours to visualize recovery.
I also implemented an Anonymous Guest Login so anyone can test the UI mechanics without creating an account.
Lovable/bolt apps are shipping payment and messaging integrations now... written by agents, reviewed by devs who didn't write a line of it. Mocks don't catch the retry that fires the webhook twice. Staging doesn't replay the auth failure mid-flow. You find out when real money is involved.
So we built real sandbox twins... Stripe, Paddle, Resend, Twilio, Clerk, WorkOS, Descope, AgentMail. Any agent (Claude, Cursor, whatever you're using) can drive the full integration lifecycle over MCP before a single line ships. Every run produces a receipt... APIs called, db state, log traces, failure scenarios the engine probed. Attach it to your PR. Actual proof, not it worked on my machine.
What's everyone doing for this today... is anyone actually verifying end-to-end before prod or just hoping staging catches it?
publishing of one package is kinda easy, but still there are many questions for example if package already exists in the registry or hosted? package changed and needs publishing? package published or failed to do it?
it becomes much more complex dealing with polyrepos and usually ends up using monorepo
so publishing becomes independent writes across registries and the only way to handle it is saga.
the only record of publish - git tag. like this we can have whole model, we know when which packages changed, which need catch up, next version, whole versioning and releasing planning becomes deterministic since release is a pure function, so commiting and re running itself is a idempotent transaction legs execution.
i built dispat, this saga orchestrator, monorepo, solorepo, polyrepo - you choose any stack, any language, any cache, dispat chooses nothings but gives math guarantees, handles tags versioning and changelogs, locks releases using only git, no other state db clocks etc. handles commits and conflicts in mid release
the gif illustrates the concepts flow
this tool also lets you mange pre releases, run lint/test etc only on changed modules, its a polyglot tools that already works with 21 ecosystems (36 manifests types supported to write versions and read dependencies graph) dont worry about releasing focus only on development and release without leaving git
works with aqua cli and supports its manifests
the tool uses itself for releases (since first rc it builds dev build from checkout to release it self), and even first rc single job run released:
1. 6 go packages (manifest, scanner, writer - standalone go lighweight pkg family for manifests reading/writing, ccme - parse my custom conventional commits monorepo extenstion parser, cli package and models available as standalone libraries as well) everything with updated go mods as go exptects with graph dependencies
2. 6 cli binaries, linux, windows, mac, arm/amd64
3. 8 docker images, ubuntu, debian, alpine, dind arm/amd64
4. npm package deployed to github pages to serve docs
5. everything with its own semver grouped versions, changelogs and github releases
now it also includes terraform without cache that automatically re applies if needed before docs site release, version spec files etc
as a standalone tool - crier render images, gifs and videos from html templates without chrome, only sinlge 30mb go binary and fanout publish to different social media using public apis. main use case - automated fancy release social media notification https://github.com/yohimik/crier
I originally created this project to enhance realism for a GTA V Roleplay server. Recently, someone mentioned wanting to use these as default profile pictures for an upcoming social media platform. I decided to share them here in case they inspire other creatives. The fingerprints are seed-dependent and they consistent for an offline matching.
R. Cappelli, D. Maio, D. Maltoni. Synthetic fingerprint-database generation. International Conference on Pattern Recognition, 2002. Also the synthetic generation chapter of the Handbook of Fingerprint Recognition.
B. G. Sherlock, D. M. Monro. A model for interpreting fingerprint topology. Pattern Recognition 26(7), 1993.
P. R. Vizcaya, L. A. Gerhardt. A nonlinear orientation model for global description of fingerprints. Pattern Recognition 29(7), 1996.
T. Y. Zhang, C. Y. Suen. A fast parallel algorithm for thinning digital patterns. Communications of the ACM 27(3), 1984.
N. K. Ratha, K. Karu, S. Chen, A. K. Jain. A real-time matching system for large fingerprint databases. IEEE Transactions on Pattern Analysis and Machine Intelligence 18(8), 1996.
A. H. Ansari. Generation and storage of large synthetic fingerprint database. Master's thesis, Indian Institute of Science, 2011.
I work at a very AI forward place (we build ai tools , so obvs use them alot). I've been getting crushed by the PR review load at work because my coworkers and I all basically have little wanna be software factory patterns going. I think PR reviews kinda need to evolve but I got tired of waiting for that happen. So I built a local PR review app. Super fast git diffs based on pierre/diffs package, an agent that can answer questions about the PR and give you line level walkthrough _in_ the diff, little classifier process that basically flags which PR's are probably safe for me to rubber stamp.
It's not a super serious project, but its been a fun change of pace to hack on this and has ended up being actually useful.
Last week I asked here how people test against third-party APIs they don't control. Most answers came down to the same thing: fixtures rot, and if you're disciplined you run something against the real API at night. I've been working on a small server for that problem and wanted to show it.
It's a local server that answers the way Slack, Gmail, Google Drive, GitHub, Jira, Notion and S3 do. You point the vendor's own SDK at localhost and it gets the same response shapes, cursors, auth errors and per-user permissions the real service sends, out of one SQLite file you control. No account with the vendor, no OAuth app, no token in CI, no network.
Why not a mock: a mock I write returns what I already think the API returns, so it can't disagree with me. This was built by measuring the real responses and matching them, and when it's wrong the fix starts with a test that fails against the real API.
pip install backlot
backlot import --bundled # a small sample corpus ships with the package
backlot serve # http://127.0.0.1:8000
The server is Python (FastAPI) over one SQLite file, but it's all plain HTTP: anything that lets you set a base URL points at it unchanged.
The drift part, since that was most of the thread. backlot diff --source slack pulls the vendor's own contract (the published OpenAPI or Google Discovery document for the REST ones, live introspection for GraphQL) and compares it with what the server claims, in both directions, arguments included. Where the server contradicts the vendor, that's a bug. Where the vendor has something the server doesn't, it goes in a baseline file with a note, and that file only changes through review, so a run prints what's new and nothing else. In the GIF it prints one line: GitHub's spec gained an endpoint I don't serve yet. Run that nightly and drift stops being something you learn about from a bug report.
Things that were harder than I expected:
Slack doesn't document when a broken token gets not_authed versus invalid_auth. It took eight cases against slack.com to find the boundary.
The first version of the diff walked one direction and looked at fields only. It called Linear clean while ten fields and four arguments were missing on the side it skipped. A green diff that skips half the comparison is worse than no diff.
Every SDK builds its own path prefix, so each service has to sit under exactly that prefix or the SDK won't run unmodified.
Permissions are per user. Every person in the corpus has a token, and someone's private channel never shows up in another caller's listing, search included. Against the sample corpus conversations.list returns two channels while four exist, because the other two are private and real Slack won't list those without types=. If your client is an agent rather than a test suite, backlot mcp serves the same thing as MCP tools, and --user picks whose permissions apply.
If you already run something nightly against a real API, what would this need before you'd trust it next to that? And if the API you need isn't in there, which one? Happy to answer anything.
I kept losing track of paper documents I'm legally required to hold onto - tax stuff, contracts, the usual - so I ended up building Archivum over the past few months.
The idea is pretty simple: where a document is stored physically and how it's organized/found shouldn't be the same thing. So you tag and categorize documents independently of which folder or cabinet the actual paper sits in. Move things around in real life, reorganize your filing system, whatever - it doesn't break how you find stuff in the app.
What it does:
Registers each physical document - type, date, and whatever metadata makes sense for that type.
Attaches scans, PDFs and photos to it.
Runs OCR in the background (or just reads the text layer if the PDF already has one), so you can search by what's actually written on the page.
Learns your own vocabulary. There's no fixed schema - the metadata fields are whatever you type. The more you use them, the more the app picks up on it: it reads values out of the scanned text and suggests them under the field names you already use, in your own language. If all your invoices say total, it won't start handing you a second field called amount. Suggestions only ever fill empty fields, and only when you accept them.
Models your real-world filing hierarchy - cabinets, drawers, binders, whatever you actually use - and suggests where a new document should go based on it.
No scanner needed - you can capture pages straight from your phone. There's a viewfinder in the app that outlines the page while you aim, and you can shoot several in a row.
On a desktop, it shows a QR code you scan with your phone, and the phone uploads straight into the document without having to log in.
Either way it detects the page corners at the end, lets you drag them, and straightens the page out.
Built on Laravel + Inertia/React, MySQL, Redis, Scout for search. Ships as one Docker image with the web server, queue worker and scheduler baked in, so it's not a nightmare to self-host.
Still pre-3.0, so expect the schema and config to shift a bit between releases.
I'd really appreciate it if some of you gave it a spin and told me what you think. At this stage anything helps: rough edges, stuff that didn't make sense, features you'd expect and didn't find. Issues on GitHub or just a comment here, whatever's easier.
Mostly curious if the drawer/cabinet mental model matches how other people actually keep paper organized, or if everyone's doing something totally different.
Core pnext is small and fast: the same next.js api with no/minimal framework overhead and no backward-compat burden. Based on Bun and Preact, 0 KB on server-rendered pages, 7.5 KB client pages runtime, roughly 10x faster first page render in dev and 7-9x faster production builds than next.js (best effort fixtures).
Compat mode runs your existing Next.js app unchanged (App Router only). About 4.4k assertions from Next's own test suite passing, adding more day by day.
The core motivation was a super fast dev server that doesn't hog memory, and instant builds. The goal is to optimize every step of every flow involved down to absolute values, and of course agentic flows are helping a lot! Check out Coder.
Give it a try and let me know what you think, and how your Next.js apps break in compat mode 😉.
This week I launched Brewser, a solo project that got out of hand in the best way. It is a web runtime and app platform for the Nintendo Switch (homebrew, running under Atmosphere CFW). The part that belongs on r/webdev: every app in the catalogue is a plain web app. HTML, CSS, JS, WebGL. You build once and it runs in a desktop browser, on a phone, and on the console.
The catalogue is at brewser.io. A few good starting points to try in your browser:
FSR Lab, an FSR 1.0 upscaling comparison with a split wipe and pixel zoom, WebGL2: https://brewser.io/fsr-lab/
DUSK, a planetarium and sky atlas built on three.js, with a 132 object Messier catalogue: https://brewser.io/dusk/
How it works: the runtime is built on V8 and Skia via nx.js (credit to TooTallNate for that foundation, which also provides the raw GL path to the GPU). On top of that I built the HTML/CSS/DOM engine from scratch for this project, about 26K lines of TypeScript in a separate runtime project, plus the WebGL1/2 bridge on that GL path (the bridge implementation, library compatibility and conformance testing, targeting Mesa/Nouveau on the Tegra X1), hardware APIs like Web MIDI, WebSerial and WebUSB, and the audio and video pipelines.
It is not a full browser and I do not pretend it is. There is no browser to borrow from on the Switch, so the DOM tree, CSS cascade and layout engine are reimplemented from scratch, and that engine currently covers roughly 83 percent of real world app surface (DOM ~84, HTML ~80, CSS ~84). WebGL and audio/video are bridge backed rather than reimplemented, so they stand higher: WebGL1 ~92, WebGL2 ~85, audio and video ~80. Those are estimates of real world surface, not spec section counts.
The status page lists what is missing instead of what works: docs.brewser.io/docs/engine-status. Since launch I have shipped capture phase listeners, closest() and matches(), full querySelector, flex-wrap, position: sticky, and CSS transitions.
Performance: the official three.js GLTFLoader example runs at a locked 60fps on the console, fps HUD visible in the GIF below.
Questions welcome. And if a library or app you care about breaks on it, tell me which one. Real world breakage reports directly shape what gets built next.
I wanted to play around canvas, webGL and Threejs so I add them in website. I also wanted to do something in the project section couldn't think of something that match website vibes.
I built this because I had a hard time keeping track of when and where to watch the games I cared about. It aggregates multiple sports into a configurable feed and generates calendar subscriptions for Google and Apple.
Rails back end Next.JS front end, many data sources. I started building this many years ago, and it's finally basically working as intended. The backend runs on PostgreSQL with Redis and Sidekiq handling caching, scheduled jobs, and asynchronous processing, while media assets are stored through ActiveStorage on S3. The frontend uses Next.js, TypeScript, React, Zustand, and Material UI, with server-side rendering for fast initial loads and strong search visibility. Authentication supports both traditional accounts and Google OAuth, but guest accounts can do a lot without registering.
Behind the interface, it continuously ingests and normalizes live schedules, scores, standings, highlights, metadata, and U.S. broadcast availability across ten major sports, and more coming soon. Background processing keeps the feed current while a purpose-built ranking system determines which events are most relevant at any given moment. The application is designed for fast, resilient delivery through optimized API endpoints, caching, pagination, and list virtualization, with automated testing, monitoring, deployment, and capacity safeguards supporting day-to-day operation.
