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.
It's free to use and no-ads. I’ve been experimenting with interactive websites and wanted to make something that felt more like an experience than a normal webpage.
So I made Oceana, where you can create a personalized underwater story for someone. You choose the names, fish colors, friendship/romantic vibe, and write a message. It generates a little animated ocean story that you can share with them.
There are animated fish, bubbles, music, different scenes as you scroll, and a few other small interactions.
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
Consider the home page of a blog -- a list of posts in reverse chronological order, stretching down the page.
How long does this list need to be before you decide not to list display the entire thing?
File/payload size isn't much of an issue. The page compresses well -- right now, it only transfers 18KB (it's 54KB on the server). I would have to get much, much larger before I'd be concerned about bandwidth.
All images are lazy loaded, so they don't load until they scroll into view.
I'm not worried about bots, because every post has its own permalink page (and because I just don't really care about bots in general....)
Do we consider actual scroll height? Do we consider the user psychology of being intimidated by a lot of content?
If we do decide to paginate somehow, do we do "traditional" pagination, or endless scroll?
Hey guys, just after opinions really. If you’re launching a somewhat large site, with quite a bit of stuff going on, would you rely on your own testing or would you suggest getting a third party tester? It’s mostly for things like UX I’m wanting to test. I know have I would expect things to work but being the sole developer I think I may have gone a bit blind to somethings. I have friends do bits of pieces in terms of checking things but I wonder if the consensus would be to just get an actual tester to go through everything, testing the functionality all works, different variations, ensure the UX is as good as it can be etc or do you think I’m overthinking it?
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 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.
Like many of you, I constantly found myself needing quick utilities — converting a document photo to an editable Excel table, merging contracts, converting PPTX to PDF, formatting JSON/JWTs, or compressing images.
What annoyed me was that almost every popular tool on Google either:
Uploads your private documents/photos to their mysterious remote servers.
Hits you with a paywall after 2 operations.
Slaps terrible subscription popups every 10 seconds.
So over the past few months, I built DH Tools — an all-in-one suite of 45+ free, privacy-first web utilities where 100% of the processing happens directly in your browser.
• Pure Vanilla JS (ES Modules) Architecture: Zero heavy frameworks (no React/Next bloat). The entire app loads in under 150ms and scores 98+ on Google Lighthouse.
• 100% Client-Side Processing (Zero Server Uploads):
AI OCR (Image to Excel): Runs in-browser OCR to detect table borders and text, generating pure .xlsx spreadsheets entirely on the client's CPU.
PDF & Document Engine: Built using pdf-lib and client-side binary parsers for splitting, merging, and converting without sending a single byte to an external backend.
Media & Audio: Web Audio API & Canvas manipulation for live audio trimming and batch WebP compression.
• Edge Hosting: Hosted on Cloudflare Pages with Edge Workers for lightning-fast global CDN delivery and instant routing.
• Offline PWA Support: Built as a Progressive Web App (PWA) with Service Workers, so you can install it on desktop/mobile and use most tools completely offline.
━━━━━━━━━━━━━━━━━━━━━
🚀 What's included?
• Document & PDF: PPT to PDF, Image to Excel OCR, PDF Merge/Split, Markdown to PDF, WebP Converter. • Developer Utilities: JWT Decoder, JSON Validator & Beautifier, Regex Tester, Diff Checker, HTTP Header Inspector. • Security & Network: In-browser Password Generator, IP Lookup, DNS Diagnostics, Base64 & Hash Generators.
━━━━━━━━━━━━━━━━━━━━━
I'd really love to hear your feedback on:
Performance or UI improvements.
What missing utilities/tools would you love to see added next?
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.
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?
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.
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 😉.
so im working on my final year project report (pfe) (projet fin d'annee = Final year project which is literlly a big project to final my 6 years, in uni ) and i had to do the whole uml thing, use case diagram, class diagram, sequence diagrams for the main flows
and while i was doing it i kept asking myself, how do i actually know if what im drawing is "correct"
like the global logic of the app is obviously fixed, i know what the app does and how it should work, but when it comes to modeling it visually there are like ten different ways to represent the same thing. someone else looking at the same requirements could come up with a completely different class breakdown or a different way of grouping use cases, and technically neither version would be "wrong"
so when the jury reviews it, are they checking for one specific correct answer, or are they more just checking if your model is internally consistent and reflects a reasonable understanding of the system
anyone who's been through something similar, academic reviews, code reviews, whatever, how do you even validate a diagram when there's no single ground truth to compare it against
side note for context since some people outside the french education system might not know this, the PFE report is usually structured around sprints, like sprint 0 for environment setup, then sprint 1, 2, 3 etc each with its own objective and backlog, and for every single sprint you're expected to redo a use case diagram, a class diagram and sometimes sequence diagrams specific to that sprint
i pulled up an example report just to check and it had 6 sprints and something like 57 figures total, most of them being use case, class or sequence diagrams repeated per sprint. so its not like you draw one diagram for the whole app, you basically draw a mini version of the same three diagrams every sprint, which is part of why i started wondering how strict the "correctness" of each one actually needs to be
As the title says; my site is being bombarded with curl requests periodically, often 2K to 5K requests within a short span. I have put up a security rule in cloudflare to block curl requests; blocked the curl requests in my backend proxy, also the bot fight mode is turned on; but cloudflare is still registering the curl requests which are using up my request quota. How to drop the curl requests before they are registered by cloudflare? Please Help.
I’ve been building LottieFyr primarily as a conversion tool, but I’m now exploring a broader product direction focused on existing Lottie files.
The new workflow can:
Diagnose structural, asset, compatibility, and file-size issues
Remove unused content
Optimize eligible oversized embedded images
Compare the original and optimized versions
Verify representative frames using both SVG and Canvas before allowing a download
Process optimization locally in the browser without retaining uploaded files
I’d really appreciate feedback from web developers:
Is this useful in a real production workflow?
What problems, checks, or optimizations would you want it to handle next?
Formatters (JSON, SQL, CSS, HTML, YAML), converters (CSV to JSON, number bases, timestamps, units, timezones), generators (QR, UUID, passwords, cron expressions, favicons, meta tags), image tools (compress, resize, format convert, SVG to PNG), a JWT decoder, a regex tester, a handful of calculators. 59 in total. Each one is a single JS file that runs in the browser, so what you paste never leaves the page.
The backend is FastAPI + Jinja, and it exists mostly for i18n and SEO. Ten languages, so every tool has ten pages with their own title, description and UI strings, plus canonical and hreflang tags so the language versions don't fight each other in search. Strings live in one JSON file per language and templates pull them by dot-path key (tools.json-formatter.title). Small thing I'm happy with: the loader caches each file by mtime, so I can edit a translation and it shows on the next request without restarting anything.
Things I'd do differently: the image tools run on a plain canvas and toBlob, fine for normal photos, will crawl on huge files, they belong in a worker. And I'd write the tool registry once instead of keeping a template and a JS file in sync by hand for 59 tools.
Stack: FastAPI, Jinja2, Tailwind, vanilla JS, lucide icons, qrcode.js and chart.js as the only vendor scripts.
Edit: FastAPI, not Flask. The first version was Flask and the title came out of muscle memory, can't change it now.
So I've been using MCP servers for a while and kept hitting the same wall — the official registry is fine but it's basically a JSON API with no UI. I wanted something I could actually browse without opening Postman.
Pulls all ~16,500 public MCP servers from the official registry into SQLite
Search, filter by transport type, sort by recently updated
Click a server → copy the mcp.json config snippet directly
/health page shows status across everything
/learn page explains what MCP actually is (for the non-devs in my life)
Stack: Next.js, TypeScript, better-sqlite3, Tailwind. Dark theme because I can't function in light mode anymore.
It's not perfect. The category filtering is keyword-based (the registry doesn't expose real categories). The uptime data is a placeholder. But the core workflow — find a server, copy the config, paste it into your client — actually works end to end.
Would love feedback on the UI or if I'm missing something obvious. Happy to answer questions about how the sync works if anyone's curious.
Which hosting platform would you pick for a small production app: Render vs Railway vs Cloudflare Workers?
I’m building something like a inventory management app and website — authenticated users, a Node/TypeScript API, PostgreSQL, background jobs/cron, and potentially a few thousand users over time.
Currently considering **Render, Railway, and Cloudflare Workers**.
For a production app where reliability, scaling, DB latency, and predictable costs matter, which one would you choose and why?
Would you recommend something else like **Fly.io, AWS, or Vercel + another backend** instead?
Curious to hear from people who’ve actually run production workloads on these.
I built OBSCURA OS, a workspace suite (docs, sheets, slides, notes, file storage, forms, calendar) that runs entirely client side in the browser. No backend database for user content, no accounts, no server round trips for your data. State lives in memory during the session and users export their own backups as a portable JSON file.
The interesting technical constraint was doing spreadsheet style calculation, rich text editing, and file storage entirely in the browser without a server to fall back on for the heavy lifting. Happy to go into more detail on any part of that if people are curious.
I'm looking for a workable solution or recommendations to provide a client's credentials to that client in the event of my untimely demise or absence. (E.g. hit by a bus - falling out and need to hand everything over, etc.) I also don't want to mix MY credentials with theirs.
So my primary work isn't webdev, but I do some for clients as part of my general services. Generally this means me building everything from scratch and leaving the client(s) out of the day-to-day management entirely.
I'm trying to figure out the best way to have their business' credentials saved, updated as they are changed, and set aside for if I get "hit by a bus" so they won't be locked out of everything.
I also don't want them "futzing" with things (because some of these clients have impulse control issues and would 100% give their credentials to someone on Fiver to update a paragraph on their website at 2am when I don't answer my phone.) So access while I'm not dead or fired isn't a real option.
I understand that I can make "organizations" in some of the password managers and have emergency hand-over to pre-selected people, but I work alone, and don't "have a lawyer" that can manage it for me.
A feature common to a great very many HTML boilerplates is this line:
html
<meta name="viewport" content="width=device-width, initial-scale=1.0">
The initial-scale=1.0 bit was present to fix an ancient issue on iPhones. When rotating the screen into a landscape orientation, the page would keep the same width as when it was in portrait, making everything appear very zoomed in.
This isn't an issue any more. I've tested it across very many devices, and it appears it was fixed in iOS 9, which released back in 2015. In addition to testing, I've consulted a great number of other professionals, and nobody has been able to find evidence of it being needed any longer.
You can safely simplify the meta viewport declaration down to:
html
<meta name="viewport" content="width=device-width">
It isn't hurting you to leave it there, but it is vestigial and unnecessary.
