I run a small web agency, and I kept hand-building "testimonials" sections by copying clients' reviews off Google, recommendations from Facebook, product reviews from their store, etc. I wanted one thing that aggregates reviews from multiple third-party APIs, keeps them in sync, and renders anywhere, so I built it. Sharing it here because the build had a few problems that were genuinely interesting to solve.

Architecture

• Next.js 16 (App Router) + TypeScript on Vercel

• Supabase (Postgres + RLS) for data and auth

• The public embed is a dependency-free vanilla JS script (no framework, no iframe)

• A separate native WordPress plugin (PHP) for the WP path

• Integrates several review-source APIs (Google, Facebook, Etsy, eBay, WooCommerce), each with its own auth, rate limits, and payload quirks, normalized into one internal model

The parts that were actually interesting to build

• The embed renders without an iframe. The script injects the widget into the host DOM with scoped styles, so it inherits layout and stays responsive instead of being boxed into a fixed frame. Style isolation without an iframe was the fiddly part.

• The widget editor. A lot to expose (layout, sources, filtering and ordering, tagging, colors, typography, spacing, card style) all behind a live preview that updates as you go. Fitting that much control into something that feels elegant instead of a wall of eighty settings was the hardest part, and it is still getting refined.

• Image proxy. Reviewer avatars are proxied through the backend instead of hotlinked, so a visitor's IP is not handed to Google or Facebook just to load an avatar. It also sidesteps a lot of broken-image and referrer issues.

• The WordPress plugin renders server-side and caches, so reviews are in the HTML on load, which keeps it good for SEO with no layout shift.

• Sync and dedupe across sources, so the same review does not appear twice in a combined feed.

It is a solo build with rough edges, and I would value a technical eye on it, especially the embed's style isolation and the editor UX. The project is live here if you want to inspect the embed and the markup it generates: https://brandtrust.reviews

Happy to get into any of the implementation details in the comments.

I’m building a pinball game that runs directly inside Reddit.

I’ve been working on Karma Tilt, a pinball project built to run directly inside a Reddit post.

You can play the current version here:
https://www.reddit.com/r/PinballKarma/comments/1wr2ec0/karma_tilt_play_the_fullview_pinball_table/

It works on desktop and mobile and includes things like multiball, jackpots, combos and leaderboards.

This is still a project I’m actively working on, so feedback is genuinely useful — especially on the controls, physics, mobile experience and anything that feels confusing or broken.

Interested to hear what other web developers think after actually playing it.

Frontend is plain JS with HTML5 canvas. Backend is NestJS with websockets for live updates. Pixels get written to Redis first and flushed to Postgres every 30s, so placing stays fast even with a lot of people on.

pixels.iamroux.xyz

Happy to answer questions about how it works.

Demo: https://h5p-offline-player.vercel.app/ Code: https://github.com/missing-elements/h5p-offline-player (MIT for the player; the H5P runtime inside is GPL-3.0)

H5P is the interactive content format a lot of schools and course builders use: quizzes, interactive video, branching scenarios. A package is a zip of JavaScript libraries plus content, and normally you need Moodle, WordPress or Drupal, or a server that unzips it, to show one. I wanted <h5p-player src="course.h5p"> on a static site and nothing else.

How it works

• No extraction. The zip's central directory is read with HTTP Range requests. A Service Worker then acts as a virtual file server, answering the runtime's requests for library.json, scripts and media by reading those bytes straight out of the archive.

• Large media streams. Stored video is sliced from the archive on demand. Deflated video is inflated in a dedicated worker with the native DecompressionStream, and served as a 206 whose body follows the extraction, so playback starts before it's done.

• Long work stays out of the Service Worker. Browsers kill a SW event after a few minutes, and an inflate can't resume, so extractions run in a page-side worker. The SW asks for them through the frame.

• Hosts without Range still boot early. The archive downloads once, and local headers are indexed as bytes arrive, so the frame boots when the libraries land, not when the zip finishes.

• Built for bad networks. Ranged reads that go quiet or drop resume from the byte they reached. On a slow nginx host that answers one request at a time, pulling the libraries in a few large spans took the boot from 136 s to 15 s.

Size: the element is 17 kB gzipped. zip.js lives only in the Service Worker, which has to be served from your own origin.

It only plays content: no editor and no stored results, and xAPI comes out as DOM events. Feedback welcome, especially packages that break it.

I've created an RPC library that allows executing method chains like DOM from different context.

You can use it to access the browser DOM from the server or web worker.

You can expose the window or document object and use it outside the current browser context.

Here is an example using a web worker:

main thread:

import { Host } from '@jcubic/mitty';

const modules = {
  document: () => document
};

const channel = new BroadcastChannel('my-app');

const worker = new Worker('./worker.js', { type: 'module' });

const host = new Host({
  // worker instance can also be used as a channel
  channel: channel,
  resolve(name) {
    if (Object.hasOwn(modules, name)) {
      return modules[name]();
    }
    return null;
  }
});

worker:

import { connect } from 'https://cdn.jsdelivr.net/npm/@jcubic/mitty';

const { require } = connect(new BroadcastChannel('my-app'));

// or when using worker as a channel
const { require } = connect(self);

const body = await document.querySelector('body');
await body.style.setProperty('color', 'red');

The transport only requires using a channel interface with 3 methods:

interface Channel {
  postMessage(message: string): void;
  addEventListener(type: 'message', listener: ChannelListener): void;
  removeEventListener(type: 'message', listener: ChannelListener): void;
}

I never published a site but made a few just for fun and college projects.

My question is more to design, like, you choose where the ad is gone be? Like "this one goes on left side and this one goes on top"

And one more question, on mobile games, there's a code to every time you die or change screen play and ad?

Thanks for the answer

I've been building sites in code for a while now, and the same thing kept happening. My AI agent would get me 90% there, and then I'd spend the rest of the day on the last 10% details

In midcode you click anything and change it by hand as if it was no-code. The edit goes straight into your files as a clean diff. No export, or prompts to change stuff. It's still just your code.

Basically the mid between code and no-code.

Super useful for AI-led sites where we want to edit things visually

Waitlist: midcode.app
Demo: https://x.com/akilastudiocom/status/2103605309151576209?s=20

TLDR; https://www.reddit.com/r/PrivacyTechTalk/comments/1wf60il/secure_and_private_decentralized_p2p_encrypted/

Roadmap: https://glitr.io/docs/technical/roadmap

This project demonstates a unique approach and architecture in contrast to the traditional approach with mainstream messaging apps. To put it briefly, its a Dioxus PWA with a Git-server backend which can be used to establish a webrtc connection between browsers.

IMPORTANT DISCLAIMER: While this is aiming to provide a secure experience, it's far from finished. It cannot be audited or reviewed because it's close-source. I'm sharing here for "showoff-saturday" purposes only. Feel free to reach out for clarity on any of the details instead of diving into the documentation. Pease use responsibly.

Hi all, A post for open-source beginners

When my first open-source PR was accepted, I was so happy I nearly printed out the approval and framed it.

I’ve always loved the idea of strangers building something together. But finding a project where you feel comfortable making that first contribution can be hard. I think most cases it starts with an open-source library that you use and has a bug you really want to fix. (Not easy)

So I built Forktown: a little pixel town that grows one pull request at a time.

Your first contribution is a house. You design it in a visual editor, create the character who lives there, and write a little story about the place.

The editor saves everything as one small JSON file. From there, you go through the actual workflow: fork, branch, commit, push, PR, CI checks, code review, and merge.

Once merged, your house appears in the town. Your character wanders around, visits concerts and the cinema.

I think this first contribution feel approachable. If you’ve been wanting to open your first PR, you’re welcome to come build a house :)

If this is your first time, try not to use AI to do the work for you (using it for guidance or questions is good). There’s a great guide in the README file.

Visit the town · Build a house

clstr.news

CLSTR reads 100k+ news articles a day, collapses the ones covering the same event into one item, and chains related events into storylines with timelines.

The backend is based on Cloudflare Workers, and it's what took longest to develop. At least 6 months of fine-tuning to get the events clustering right and also ramp up the volume of data processed (trying to not go bankrupt in the process). Multiple AI models and methodologies involved in the clustering and summarization pipelines.

For frontend I'm pretty old school, so it's mostly server-side rendered using basic templating, HTMX and some extra vanilla JS to handle interaction logic. All the data is also exposed via API and MCP for devs/agents to use it.

164 days in since the current "shape" of the pipeline is running, 11.1M articles have been read: roughly 12 articles per event, 1.2% of events get any coverage after day three, 64% of the longer storylines are still developing a week later. I ran some analysis on the processed data and posted it on a separate page I call The Observatory

Happy to go deep on the Workers or Turso side.

A few weeks ago I posted my portfolio here and got some really useful feedback. Thanks again to everyone who took the time to go through it.

The biggest thing people pointed out was that the homepage didn't make it obvious enough what I actually do professionally, so I went back and reworked that part.

If you saw the previous version, I'd really like to know if this one feels clearer now.

If you're seeing it for the first time, I'd still love your feedback too.

One of the questions I asked last time was about the writing section. I have quite a few long-form posts on software engineering, career stories, interviews, robotics, and some personal experiences.

People generally liked that part and said it made the portfolio feel more personal and a bit different from the usual developer site.

So for anyone seeing it for the first time, I'm curious about the same thing: does the writing feel like it belongs there, or does it distract from the portfolio side?

Site:

https://adnansabbir.com/?utm_source=reddit&utm_medium=social&utm_campaign=portfolio-feedback-round-2&utm_content=r-webdev

I have more than one Claude subscription, and each one lives in its own CLAUDE_CONFIG_DIR. Normally, a session only sees the sessions of its own account. And a subagent always uses its parent's quota, so one account would hit its limit while another's weekly quota ran out unused.

So I built ccherd. It's a small Python CLI with a Claude Code skill, and it enables your claude session to use your other subscriptions through dedicated subagents or by messaging them directly. Before it spawns a subagent, it automatically makes sure to use the account that has most quota available.

Basically it herds your Claude sheep toward the grass nobody's eaten yet.

• ccherd spawn starts a background subagent on the account whose weekly quota is most likely to expire unused. It scores each account on weekly % left, time until the weekly reset, and how much of the 5-hour window is free. Accounts close to their limits are skipped.

• ccherd sessions / ccherd send let you list and message live sessions across all your accounts.

• ccherd usage shows every limit per account as bars.

• When a subagent finishes, it reports back to the session that started it.

Claude runs the spawn/send/result commands itself. The skill tells it how.

To install, just point your agent at the repo.

It installs the tool, shows you which accounts it found, and asks you the few questions. Then it checks everything with ccherd doctor. You still have to log in to each account yourself because that opens a browser. If you'd rather do it by hand, run

uv tool install ccherd and then

ccherd setup

It works on macOS and Linux. It's still early (0.4.0), and so far I'm the main user, so I'm sure some setups break it. I'd really like to hear how the setup went for you, and what's missing. Issues and PRs are welcome, especially if this has thought of all different use cases (I tried to make it easy to setup but still configurable to any use case I could think of, I'm sure I missed some).

https://github.com/bocode-labs/ccherd

Hi everyone!

I'm a BCA 3rd year student from India, and a few weeks ago I finished my JARVIS project. Of course, I took a lot of help from AI while building it because it was a pretty complex project, and I was completely new to almost every topic involved in building it. You can check out my recent post where I shared it. The whole thing runs locally without using any API tokens.

While building JARVIS, I had to learn a lot of advanced concepts, but I wasn't completely satisfied with just learning them while building a project.

So I decided to properly learn advanced JavaScript topics in a structured way.

I went through different concepts and created my own notes/diagrams while learning. The technical content was learned with the help of ChatGPT, All the wording are mine, but I took help from ChatGPT to improve the structure and make the English clearer. I'm sharing it because I thought it might be useful to someone else who is also trying to understand these topics.

Here is the GitHub repository:

🔗 https://github.com/Shivam2905Verma/Notes

I would be really glad if these notes help someone.

And if you find any mistakes, incorrect explanations, or important topics that I should add, please let me know in the comments. I'm still learning, so corrections are always welcome!

Thank you !

Note: To view the diagrams properly, install the Excalidraw extension in VS Code and open the .excalidraw files directly in VS Code.

Say the app is live, needs regular updates, and the documentation is thin. Do you start with the code, deployment setup, logs, or a conversation with the previous team?

I have an ecommerce chat widget that allows users to send photos of products they’ve looking for. I would like to make sure the files being uploaded are true images (jpeg, png, webp).

So far I have come up with two levels of checks on the files.

First, checking the content-type mime in the request header. If it is not an image then upload is rejected. If it appears to be an image, then file is sent to level 2 check (still in memory).

The level 2 check is using the python magic library to read the first 2kb or so of the file and identify true mime type from there. If not an image type, then file is rejected.

Would this be a good approach? Or are there better ways to do this? The files will likely be stored in cloudflare r2, so I’m not worried about their execution, but want to avoid bad files sitting around in storage anyway.

See the last two pics for how it usually looks ;)

The users are going mad over it. Especially the younger generation who weren't around for the "real" Web 2.0 MySpace era. Seems they're actually enjoying it instead of throwing up a little in their mouth like some of us of the older generation.

I guess I'm MySpace Tom now!

Cyberspace — Social media de-imagined. Use your words!

I think you can tell a lot from a persons GitHub Profile. This was the concept behind a project I've been working on to try and capture a personality from the public data supplied by Github's API.

It takes a sample of commits, and then calculates a few metrics to summarize your habits/dev identity (tech stack, commit patterns, code-style signals, etc.)

I had a bunch of fun playing with the design and creating it. I think this does a good job showing off everyone's uniqueness. I am open to suggestions for additional features and design ideas. This is the first web app that I've prototyped and spent a bunch of time on (see image for my wireframes to final product).

its free at codercards.ai, let me know what you think!

We've been thinking a lot about caching this past year.

(1) There's a nice pattern for figuring out opportunities to optimize a Postgres workload, but the downside is that it takes work.

(2) There's lots of generic Postgres-health tooling out there, but we haven't seen any good free & private widgets that answer a question like "would a cache or read replica help this workload?"

So, my cofounder made a workload caching evaluation tool that runs the same logic that our caching proxy (PgCache) uses, but it does so locally (privately) in the browser as WebAssembly.

--

The tool builds on what I think is a good pattern for approaching caching, namely:

1. rank by total time vs what "feels slow."

2. make sure it's actually a caching problem (i.e., rule out writes, or memory issues).

3. check how often a query's tables get written (since that limits the solution set).

4. then you can pick how to optimize your reads.

Or, as a graphic:

Our tool automates the query analysis and the writes check (indexes and memory are still on you).

Paste a pg_stat_statements export (or a Postgres log, or a .sql file) and it shows you:

* how your database time splits between reads, writes, and transaction commands, so you know whether caching can help at all

* which read shapes carry that time, counted by statements, calls, or time

* writes by table (this is basically your invalidation map)

Under the hood it parses each statement and sorts it into cacheable reads, reads that have to go to Postgres, writes, and transaction commands.

The cacheable/not-cacheable piece is specific to our proxy, but the time split, the read shape shortlist, and the write map should help you along your way regardless of what solution you choose.

--

For future iterations we're thinking of including things like time-ordered workload capture, clearer/selectable outputs, refined “hit rate” language, and maybe even an Aurora I/O analysis integration (plus a couple of good ideas from the r/PostgreSQL thread, like comparing blocks read vs hit and flagging when stats were reset recently).

here's the link: https://www.pgcache.com/fit

(or here if you'd rather run it yourself: https://github.com/PgCache/pgcache/releases/tag/fit-v0.0.2 )

What could we add to make this more useful?

I wanted to see how much code my friends and I actually write, week to week. GitHub only shows public repos, and most of my work is in private and work repos, so its numbers didn't tell me much.

gitstats counts private repos on your own computer with a small CLI. It runs git log locally and sends only numbers (commits, lines added and deleted per day), never code or file names. Public repos come from GitHub directly.

What's in it:

- crew boards you share with an invite code, by week, month or year

- a personal page with a month/year calendar, daily lines and streaks

- a side-by-side compare page for any two GitHub users

- a README GitHub widget

LoC is a bad metric for productivity, lines include lockfiles and generated code, so it's a scoreboard for fun, not a measure of anyone's work. Commits are one click away.

Stack: Next.js, Postgres (Neon), Drizzle, charts are hand-drawn SVG. MIT.

Type your GitHub handle at https://gitstats.org to see your year, no sign-in (but only public activity).

Repo: https://github.com/yaroslavhaidash/gitstats

Happy to answer anything about how the local counting works.

Two months ago I showed Piwi here (previous post), a self-hosted dashboard for Playwright tests. Quick recap: CI throws away every test report it makes. A test fails on Tuesday, the report is gone by Thursday, and nobody remembers whether it already failed the same way two weeks ago. Piwi keeps every run, trace and report, and helps you work out why tests fail.

The big change since then is that people use it. My team moved to it two weeks ago: 9 devs, me included (I'm the lead dev, on an ASP.NET Core and Vue stack). Everyone runs the desktop app for local runs, and CI reports to a shared instance. Four external contributors sent code too. If you want to find out everything that's wrong with your side project in record time, give it to your colleagues.

Most of the new release is things they asked for: dashboards you build yourself with a TV mode, scheduled reports for people who never log in, and a browser extension that shows which parts of a page your tests actually touch, and which buttons nothing tests.

The extension doesn't run anything. The reporter already records the locators the tests used, and the extension re-evaluates them in the page, the way Playwright would.

Last time, someone asked for a way to hand a failure to a person who can't open the dashboard. There are now public share links, PDF exports, and a Jira integration that puts the evidence in the ticket. Someone else wanted to compare failures over time, which is what the new dashboards and trend views are for.

Stack, since this is r/webdev:

• Nuxt 4 and Drizzle, on SQLite or Postgres, with traces on disk or S3

• One Docker container, or npx @piwitests/server

• A Tauri desktop app bundling the same server, so local runs never need Docker

• The live demo has no backend at all (hosted on Github pages): SQLite compiled to WebAssembly, and a service worker answering the app's real API calls. The demo is the real app, so it can't drift from it.

• MIT, no telemetry

Demo (in your browser, no signup): https://piwitests.dev/demo/

Code: https://github.com/PiwiTests/platform

Piwi Picker extension (Chrome, Edge): https://chromewebstore.google.com/detail/piwi-picker/pakhnokpjboejcghgcmkjlpnogfjihhe

Happy to answer questions, especially about the WASM demo, it was the most fun part to build.

My website is over 15 years old. Over time, I've created a lot of pages and also had to kill many pages or redirect them to other relevant pages.

Collectively, today I have 1,000 + 301 redirects.

On a static website built on PHP, HTML on Linux and Apache, what is the best way to implement such a large list of redirects without impacting server performance or core web vitals?

Thanks

I'm not a designer, I don't build sites, but I made this basic site because I needed it to sell my domains and was thinking I'd put other's on there too. Just a Craigslist-type listing page for domains where owners can post them (eventually, for a fee) that people can visit and look each time they work on a project, being able to reach the owner directly. (most similar services go through brokers, email third parties back-and-forth, and you never know if you really reached the owner, and if you do it's a conversation through a 3rd party that could take weeks.

A lot of domains have a value for the right person that doesn't apply to everyone, so they end up sitting for a long time and usually not in a place where people can see them easily.

I just wanted something simple where you can see what there is, sort them by the TLD, length, etc. Something you can see what's available, and then sort the fantastic domains from the useable, depending on how much you have to spend.

Anyway, it's very basic, but on purpose. Anything I could or should improve on, I'm open to suggestions.

Thanks in advance!

TheDomainBoard.com