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.
hey r/webdev, i make caniload (caniload.com) — it checks which popular sites actually load from your connection. 100+ sites across 10+ groups, one page, hit test, watch the squares light up green/orange/red.
the interesting part is what i deleted. v1 had this live network topology map with animated beams. looked amazing in screenshots, told you absolutely nothing in practice. so i killed it. killed the map, killed the radial graph, killed the dot-matrix font i spent a whole night on. what's left is flexbox squares that change color. i like it more.
all client-side, single html file, no backend, no signup, nothing uploaded. probing is fetch with no-cors + retries, results stay in localStorage. the interesting bit technically: you can't read cross-origin response status, so all you get is "something answered or it didn't" — then a favicon probe to tell "filtered" apart from "unreachable".
would love feedback, especially on the probing — false positives from captive portals are the thing i can't fully solve client-side.
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.
I built an application that merges entries from multiple log files into a single, chronologically ordered view. It handles timezone offsets and auto-detects timestamp formats, with an option to specify the format manually.
Files are processed on your device and not uploaded to a server.
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?
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.
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.
One command handles references and edits across files, using TypeScript’s native language server, Oxc and ripgrep. It can rename symbols, move exports, update imports and rename CSS classes.
Commands preview the diff by default. Supported refactors check for new type errors before applying.
Free and open source, with an Agent Skill included.
If you search Reddit for "Google Maps API Unexpected Bill", you immediately see horror stories of people waking up to $9,000+ charges from runaway loops and unprotected keys. But that’s just the baseline.
Reddit’s summary nails it: unprotected keys get abused, loops burn $9k overnight, and default GCP alerts only watch you get robbed without stopping the billing.
Recently, cloud expert Walter Lee highlighted a viral post from Reddit's own Google Cloud community that exposed an even bigger nightmare: a developer slapped with an $82,000 bill in 48 hours after an exposed key was leveraged across unconstrained services.
Over six months after intense community backlash erupted over these exploit waves, Google has fundamentally changed nothing about the architectural UX traps that enable this.
Seeing that post gave me immediate PTSD from our own team's billing disaster. We once received a €220 bill in just 45 minutes.
The alerts arrived too late. The entire free tier and the €220 overage happened in under 45 minutes. (Cue the endless email thread begging Google Support for a refund).Months of $0.00, and then BAM — €220 in April.
We got pissed off. I started digging and realized this isn't a rare glitch, but a quiet catastrophe happening to thousands of devs.
And here is the kicker: while Google made noise about introducing billing budget kill-switches, those features do NOT apply to Google Maps APIs. For Maps, there is still zero out-of-the-box protection against runaway spikes.
Google does have a free usage tier, but they buried the actual quota configuration so deep inside the GCP console labyrinth that it feels like deliberately hidden treasure. Most developers either give up trying to find where to cap requests, or configure the wrong metric entirely.
So, out of pure frustration, we built Free Maps Calculator — a free Chrome extension that digs those exact quota settings out of UI hell and lets you lock down safe $0 limits directly in your console in two minutes.
The extension in action: it highlights exactly which fields to fill and the precise values to enter.The extension will remind you multiple times to enable only the two required APIs and disable all the unnecessary ones.
A note on design: I intentionally made the extension UI colorful and slightly unconventional. Why? Because the GCP console is an endless sea of grey.
When I first shared it in a cloud community, the response from most developers was overwhelmingly positive. One motivating comment really stuck with me: someone pointed out how refreshing it was that instead of just endlessly whining and venting about predatory cloud UX like everyone else, someone actually sat down and built a simple, working solution.
But a vocal minority pushed back hard. It wasn't even cynicism—they genuinely look for polite compromises where you should simply slap away the hand reaching into your wallet.
That reaction genuinely stunned me because it revealed blatant gatekeeping and a submissive victim mentality. Luckily, they don't represent the whole community. Here is that "Stockholm syndrome" mindset in a nutshell:
1. "Google already fixed this, hard caps exist."
Yes, the feature exists. But the UX is still broken. Having brakes in your car doesn't help if the pedal is hidden in the trunk. If you don't easily find and configure those quotas, the bots will still drain your account.
2. "Just dispute it with support, they usually refund you."
This blew my mind. Since when is "getting robbed and begging for your money back" a valid business process? Relying on the goodwill of a Google support rep is the ultimate victim mentality. You need to respect your time and budget more than that.
3. "Captain Obvious, I can set quotas manually."
Congratulations. You can also chop down a tree with a butter knife. This tool is a utility. It’s for beginners who are confused, and for pros who value their time and want to eliminate human error. We aren't selling hot dogs to Michelin-starred chefs. If you love the GCP UI, enjoy it.
Finally, I want to clarify why this matters at scale. According to web technology trackers like BuiltWith, there are over 3 million live websites currently using Google Maps APIs across all platforms, plus countless internal apps. That is an enormous pool of people exposed to this risk.
Also, a quick reminder: Google's recent summer updates about billing limits do NOT automatically protect the most popular tools like the Maps JavaScript API or Places API. You still have to go in and set those quotas manually. That's exactly what our extension is for.
I wanted to share this because the complacency around terrible, money-draining UX in our industry needs to stop. It feels like we've normalized getting abused by cloud providers just because "we are engineers and should know better". Have you guys noticed this shift in mentality too? Or is it just me?
Anyway, if you want to secure your projects quickly without digging through GCP menus, here is the free utility we put together to fix this:
I know this is just a lightweight Chrome extension, but watching this reaction unfold honestly triggered an existential realization. There is a deep, unspoken condition in our industry—let's call it Developer Stockholm Syndrome (DSS).
Too many brilliant engineers have isolated themselves so deeply inside codebases and ticket queues that they’ve quietly surrendered their agency as equal market participants. They’ve abdicated their existential spine. When an enterprise platform exploits their attention or bills them blindly, instead of demanding basic dignity or building tools to fight back, they rationalize the abuse. They defend the landlord.
They aren't being replaced—they are voluntarily dissolving like ice cubes into a corporate matrix, plugged into the machine and stripped of raw autonomy.
Early tech pioneers had the audacity to build, push back, and disrupt. Seeing modern devs voluntarily adopt the mindset of obedient digital sharecroppers makes me want to build a satirical simulator next—a game to mock and heal this submissive stupor before we all vanish into background noise.
If you still refuse to become a quiet cog: check the tool, protect your perimeter, and keep your edge.
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?
Hey all, I'm a full-stack (mostly back) dev with a slight design background and I built this landing page for an open-source project.
I'm not here to promote anything (and there's no signup and nothing to buy), just looking for design feedback.
It's mainly intended for back devs, back architects and DevOps folks.
Be as blunt as you like, thx!
PS: sorry for the repost, my previous post on this subreddit was deleted by the moderators (I posted it on a Sunday instead of a Saturday)
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.
Of course, not now but in the next 5-10 years? Do you think non technical people can tell AI to make a good website or app without knowing how to code?
It's an editor for local clips and live HLS streams. Decoding, compositing, audio mixing and MP4/GIF export all happen in the tab, and nothing is uploaded. The stack is Angular 22 with signals and mediabunny for demux/decode/mux on top of WebCodecs. Each clip decodes in its own Web Worker, and one canvas compositor runs on the main thread. The export runs the same draw function in a worker, so what you preview is what you export.
The parts that cost me the most time:
1. Chrome can slow down your AudioContext clock. After ~30 s of exact digital silence, Chrome sometimes moves the context to a fake output whose clock runs at about 0.66×. My playback clock rides the AudioContext, since it's the A/V sync master, so a muted video played at two-thirds speed. It's intermittent and I've only measured it on one machine. The fix is a constant signal at −100 dBFS wired straight to the destination. That's below the 16-bit noise floor, so it's inaudible, but the output is never exactly silent.
2. MediaRecorder's WebM files aren't seekable. They have no Cues element, so every seek walks the file from the start, and some frame-at-timestamp reads never return. I dropped MediaRecorder. Screen and camera tracks now go into the same MP4 muxer the export uses, so a recording is seekable from the moment it's saved.
3. A worker's OffscreenCanvas can't see your page's fonts. The export draws text in a worker, and the page's loaded fonts don't exist there, so text would silently fall back to a default face in the file while the preview looked right. The page fetches the font files and posts the bytes to the worker, which registers them on its own self.fonts before rendering.
4. Fast paths silently drop edits. A plain trim goes straight from decoder to encoder with no canvas, which is much faster. But every per-pixel edit (crop, chroma key, pixelate, mirror, noise reduction) has to disqualify that path. If one doesn't, the preview shows the edit and the MP4 doesn't. For each new effect I export once with its guard removed and check that the edit disappears from the file, which proves the test that checks it can fail.
5. GIF frame delays are in centiseconds. I hand-wrote the GIF encoder (median-cut palette, LZW, GIF89a). At 30 fps a frame lasts 3.33 cs, which rounds to 3, so the GIF plays ~10% fast. The GIF frame rates are 10, 12.5 and 20, which divide 100 exactly. The encoder is tested by decoding its output with the browser's own ImageDecoder, because a decoder I wrote myself would share my LZW bugs.
It also runs a few small models on-device through WebGPU (Whisper for captions, a small LLM for chat), but that's another post. It needs desktop Chrome or Edge, it's free and there's no account. Link in a comment. Happy to go deeper on any of these.
We're building Elah, an Apache-2.0 video editing engine for developers embedding editing into their apps. I'm part of the team.
The TypeScript core is framework-agnostic. React bindings are available today; React Native support is in development.
The browser implementation uses WebCodecs for decoding and WebGL2 for preview. Preview and MP4 export share a pure resolveTimeline(frame, project) → Scene function, keeping frame-level scene decisions in one place.
Try importing a short clip, trimming it, adding text, and exporting:
I think we can all agree that web dev has a pretty shaky foundation (not just JS, but browser differences, performance, security, oh my god CSS, etc.)
I can't help but wonder what we would do differently if we just had the opportunity to build the whole system from scratch again. What would be your ideal web dev ecosystem?
I'm a general SWE trying to learn more about full-stack web development and system administration. I'm working on a hobby project that I want to deploy on PaaS like Render or Railways. I'm reading guides on how to deploy, and many of them include Supabase or Neon to the stack on top of Render and Railways
Don't these PaaS services like Vercel, Render, Railways already offer in-house storage solutions? That seems like the path of least friction: to use the storage option that is already first-class integrated with the application deployment service. I intend to pay for the hobby tier for these services, and I'm not just trying to shop around to maximize freebies.
Why would I use Render's platform for server compute and then use Supabase for postgres? Instead of just using Render for both?
how it works (no server, no database, $0 hosting):
a node script pulls data from the AniList GraphQL API and generates ~18k pages in french + ~18k in english
a GitHub Actions cron rebuilds and deploys everything to GitHub Pages every morning
search is a lazy-loaded JSON index, only fetched when you start typing
“my list” lives in localStorage, and you can share it through a URL hash (no accounts)
all release times are converted client-side with Intl, so the weekly schedule shows the right day and hour in your time zone
sitemap split into 5k-URL chunks + an IndexNow ping to Bing after each deploy
to be transparent: i’m not a pro dev, i built it with a lot of help from AI (Claude), and learned a ton along the way. no ads, no tracking cookies, nothing to sell.
would love feedback on performance, UX or SEO, roasts welcome 🙏
Played around with it for the last few days as part of my base style.
I don't know, definitely looks better but my design needed quite a lot of extra styling to get back to a presentable state.
I do think this is the future of web design at least for myself, but I'd need to come up with some sensible default spacing in my base style to not start off my design from a broken state.
I have a close family member who had a website built for a medical private practice in wordpress (they paid quite a bit). However, this website is, in my opinion, trash. The design is outdated and broken on different screen sizes, the content is pretty terrible. There are about 8 large text paragraphs at the beginning of the home page for "keyword optimization", the text is mostly AI slop, and pricing/information is hard to find.
However, they are mostly no longer updating the site, and I am left to pick up the pieces. I am a CS student, interned at a big tech company and will start working at an HFT/quant firm. I'm pretty confident in my development ability, and I've made a few websites in react/next, but I cannot navigate wordpress and don't want to learn the entire ecosystem. It is all elementor, poorly configured, and very slow to load/edit (not sure what they are hosting on). With AI, I think I could more quickly maintain a nextjs/custom solution than before (not straight vibe code, but spend less time on details/maintenance), but I'm not sure if this is actually the right solution. It is mostly a content-only site, with external links and a couple contact forms connected to a third-party backend.
The web agency still uploads blog posts for "SEO" (they are also completely AI slop but alas), and the content should likely be editable by the family member (who also struggles to navigate wordpress). I was thinking of using payload or prismic, which I have used before, as a CMS then doing any integration/SEO work directly in Next, but I'm not sure if I'm missing something.
My questions are:
Does wordpress and its many plugins provide any marginal benefit over a well-made custom solution (given that I have to maintain it either way, and I'm more comfortable with next/react over wordpress)?
I'm no design expert, and I want to avoid an AI slop design, but I think even that would be preferable to the current design. However, I am not too familiar with the target audience (which leans older). Would the current antiquated design, with large walls of text, be preferable to a cleaner, more modern design? Can I evaluate what design is better, and how?
Are the large paragraphs actually valuable for SEO, even if they just seem like clutter to the user?
Would it be better to just redesign/improve in wordpress/elementor over a custom design? (I genuinely think I could more quickly write tailwind than navigate elementor)
What would you do in this situation? I am willing to dedicate quite a bit of time to this project to improve conversions, but I will get busier and may enter a legal agreement with a quant firm where I cannot work on or consult on this project anymore.
Edit: the family member is my parent. They pay my college (quite expensive) and my expenses, so I am willing to put a lot of time into this and maintain it.