Web Development

I've been building this on and off for the past year - it started because I got tired of "free" PDF tools that upload your files to who-knows-where or watermark page 2.

Everything runs client-side: a PDF suite (edit/merge/split/sign/OCR), image and audio converters, 200+ calculators, and some AI tools that lean on local models where possible. No accounts, no file size gates, and it works offline once installed (PWA).

The webdev-relevant bits: most of the heavy lifting is WASM (ffmpeg.wasm, tesseract), plus service workers for offline. Honestly the hardest part was memory management on large files in Safari.

Would genuinely like feedback - especially on what tools are missing. If you want to poke at the audio/video side, https://practicalwebtools.com/studio is the fun part.

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?

We've open-sourced our Accessible Components Library, and, as you might expect, this includes the HTML, CSS, and JavaScript code. But, we thought, "Why stop there?" So, we've also published our documentation, including the accessibility requirements, test scenarios, and even the working automated tests which validate each one.

When a page looks fine in a browser but its discoverability is unclear, I’d separate three checks:

• Does the original HTML contain the page’s main content and useful navigation?
• Does the content appear only after JavaScript runs?
• Is the response different when you change the user agent, or is an access rule getting in the way?

Those are different problems. A 200 status alone doesn’t settle any of them, and a missing mention in an AI answer doesn’t prove a rendering problem either.

Disclosure: I’m the founder of Prerender Buddy. Our open-source CLI checks returned HTML and discovery files: https://github.com/kopachlager/prerenderbuddy-cli. It flags things worth inspecting; it doesn’t run a browser or prove that a real crawler failed.

If a rendering gap is confirmed, the fix could be in the app’s rendering approach or a managed prerendering layer. PB offers the latter, alongside monitoring: https://prerenderbuddy.com/. If the site already returns complete HTML, extra prerendering may not be needed.

What evidence do you normally collect before choosing between changing the app and adding a rendering service?

JSX, short for JavaScript XML, itself short for Extensible Markup Language, is a syntax extension for JavaScript that allows writing XML-like embeds anywhere an expression is accepted: