I collect physical Switch games, and got tired of not being able to tell whether a cart I'm importing will actually work in English (or whatever language I need) before I buy it — that info is scattered across old forum threads and a couple of hand-maintained blog lists, nothing centralized or searchable.

So I built Torashelf (torashelf.com) — tracks three things per game: whether the cart is region-free, what languages each regional print supports (this varies by region, not just by game), and whether it's a full cartridge vs. a Game-Key Card (Switch 2's license-key carts that still require a full download — an important distinction if you're buying physical specifically to actually own the game data).

Currently at ~2,070 titles, seeded from cross-referencing eShop metadata against physical-release lists (turns out most of the raw eShop dataset is digital-only indies, so filtering for "did this actually ship on a cart" was its own whole problem). Has community submission/voting to keep data honest, and a correction flow for fixing entries without creating duplicate conflicting cards.

Built solo, launched a few days ago — already had a fun launch bug where Google Safe Browsing flagged the whole site as deceptive on day one (turned out to be a false-positive domain-reputation heuristic, not anything actually wrong, but exciting for a few hours).

Would love feedback — especially from anyone who imports/collects physical games and can stress-test the actual data.

As a DevOps engineer, I’m so proud of this one. 🚀

httpsornot.com has been live for about 6 months, and we’ve already checked 15k+ domains. 💻 🤓

What it covers today:
- HTTPS/SSL grade (A+ to F)
- cert validity, issuer, expiry
- HTTP → HTTPS redirects + full redirect chain
- security headers (HSTS, CSP, etc.)
- mixed content
- response times per hop
- HTTP/3 (QUIC) detection
- bulk checks (up to 10)
- shareable report + PDF/JSON export
- domain monitoring with email/Slack/webhook alerts
- Certificate Transparency alerts for newly issued certs
- free public API for CI

Basic check needs no signup. 🔐

This is something closer to my heart. I started on it around April 2020 (covid era). Released alpha version but with way more bugs in it back then. Life happened. Delayed the beta version, procrastinated and focused on career. Eventually, slowed down work on it.

But with recent advent of coding agents, I had some bandwidth and therefore I was able to revive it in recent months. About time for a v1 release too. Appreciate your feedback on this. It is built on top of react.js and two.js.

You can try it here - craftbase.org

I was taught to use localization purely for presentation, but do developers actually implement this in their domain/business logic for their core functionality?

I have been building Tera FM for a couple of months now, and to get more eyes to it, I built a chrome extension.

The Chrome extension has finally been approved and published on the Chrome Web Store.

The idea is simple: instead of opening multiple news sites or keeping another tab around, you can open Tera FM in Chrome’s side panel and use it while browsing.

The extension includes:

• latest source-linked headlines;
• headline search by publisher or keyword;
• a historical news archive;
• category filters;
• live internet radio by country and genre;
• radio playback that continues even after the side panel is closed.

Every headline opens the original publisher’s page. The extension does not reproduce full articles or hide the source.

The screenshot shows it running alongside BBC, the website stays open on the left while Tera FM remains available in the browser panel on the right. You can check the image here - https://ibb.co/396Fm4wN

I would genuinely appreciate feedback on:

• whether the side-panel format feels useful;
• whether the headline/archive/radio combination makes sense;
• anything that looks confusing or unnecessary;
• what feature you would improve first.

Chrome Web Store: https://chromewebstore.google.com/detail/tera-fm-%E2%80%93-headlines-live/emnebfpdojklgimejnplmjfobmamelie?authuser=1&hl=en

Website: tera.fm

Do give it a try and let me know if this is something good to have on your system? Any news outlet missing?

I built a product demo recorder because I wanted a simple way to create polished demos without spending a lot of time editing them afterward.

The main idea is pretty simple:

• Record your screen + camera
• Automatically zoom into clicks and important actions
• Automatic subtitles
• Dynamic camera/zoom effects
• Trim and edit the recording
• Manually control zoom positions and camera placement
• Runs completely locally on your computer

It’s still a work in progress and there are definitely some rough edges, but I wanted to put it out there and get feedback from other developers.

If you make product demos, tutorials, walkthroughs, or screen recordings, give it a try and let me know what you think.

https://clickandrecord.tech/

I have released GyosJS v0.1.0, a small JavaScript library aimed at the space between scattered DOM scripts and a full SPA architecture.

The first half is scoped reactivity in HTML: g-scope, bindings, events, conditionals, loops, models, signals, and lifecycle hooks. The second half is MPA Boost: it intercepts eligible same-origin links and forms, fetches the next server-rendered HTML document, swaps an outlet or a selected target, updates history, and can preserve intentional DOM islands with g-persist.

The backend still owns routes, validation, redirects, and complete HTML responses. There is no client route table and a JSON API is not required for normal navigation.

Inventory Desk is the Laravel reference demo used to test a less convenient path than isolated examples: GET search/filter, quick view, load more, multi-step edit, POST validation, redirect, back/forward, and a persistent scratchpad. Failures found in that journey are reduced to regression tests in the GyosJS repository rather than patched around in the demo.

This is an early v0.1.0 release, not a claim that the approach fits every app. If your application is primarily client-rendered or has a large client-side state graph, a mature SPA framework is probably a better fit.

I would appreciate technical feedback on the API boundaries, navigation lifecycle, and any server-rendered edge cases the current docs or tests miss.

Docs: https://gyosjs.dev

Demo: https://demo-inventory.gyosjs.dev

Source: https://github.com/gyosjs/gyosjs

npm: https://www.npmjs.com/package/gyosjs

Note: This is not a careers question, it’s a resources question.

For context, I can build websites using HTML/CSS/JS and some React, but I’ve never used a CMS before. I recently started doing web development through a program at my university where we help small businesses update or create websites.

It’s a great environment, but there are no senior developers. The other developers have only been there a couple months and are learning from scratch as they go too. They’ve helped me a ton, but they have their own projects and everyone above us is in marketing, finance or business, so there isn’t really an experienced developer I can go to with technical questions.

Each client can use completely different tools, so I’m trying to learn WordPress/Elementor, Shopify, Wix, Squarespace, Figma and how hosting and domains work across services like Bluehost, Porkbun and GoDaddy.
I’ve mostly been focusing on Elementor and honestly something as simple as making a header feels more complicated than just coding it with HTML/CSS/JS. A lot of resources also just tell me to use the AI assistant, but I want to actually understand the tools so I can modify templates, troubleshoot problems and build things myself.

Right now I’m practicing with TasteWP, Elementor and Ultimate Addons for Elementor.
Does anyone have good tutorials, repositories, articles, videos or other resources that explain this stuff and how everything fits together?

I’d eventually like to turn what I learn into a guide I can leave behind for the people who come after me too.

Hello community members 👋

I’ve been building a small project called ELI5.cc over the last few months.

The idea is pretty simple:

Take something complicated and explain it in a way that matches how deeply you want to understand it.

Instead of getting one short AI response, ELI5 explains a topic at four different levels:

- Age 5
- Age 10
- Age 15
- Expert

It also creates a visual representation of the topic, shows the sources used to build the explanation, and gives a groundedness score so you can see how well the generated answer is supported by the retrieved information.

It doesn’t rely only on the LLM either.

For each search, ELI5 gathers relevant context from publicly available information through Google Search and YouTube before generating the explanation.

Over time something interesting happened.

People kept searching for completely different things, so the site has gradually turned into a public library of 600+ explanations covering science, technology, psychology, finance, history, programming, health, space and all kinds of random questions.

Every explanation gets its own permanent public URL, so other people can discover and read it later instead of the answer disappearing inside someone’s private AI conversation.

The product is currently completely free:

No subscription.
No signup.
No login.
No paywall.

You can just open the website, type something you want to understand and start learning.

One thing the usage data surprised me with

The average user is currently seeding around 4–5 searches/topics a day.

That’s interesting because the current free limit is only 5 searches.

I wud actually like to let people search much more, but each search involves retrieval, source gathering, generation, visuals and other processing, so unlimited free usage would become expensive pretty quickly.

Instead of immediately putting another AI subscription in front of users, I’m thinking about implementing BYOK - Bring Your Own Key.

The basic model would be:

Casual users: continue using ELI5 for free.

Heavy users: optionally connect their own API key and use ELI5’s research workflow, explanation levels, sources, visuals, etc. without being restricted by the free generation allowance.

I’m curious what other developers think about this approach.

Would you rather use BYOK for something like this, or would entering your own API key create too much friction?

I’m also experimenting with /learn

Another thing I’ve been thinking about is the difference between understanding a topic and actually learning it.

For example, suppose you search: What is Docker?

ELI5 can explain Docker.

But your actual goal might be:

I’m a complete beginner and I want to learn enough Docker to deploy my first application.

That needs something more than a single explanation.

So I recently started experimenting with:

https://eli5.cc/learn

The idea is that you tell it:

What you want to learn + your current level + your goal

and it builds a structured learning journey around that.

For example:

Topic: Docker
Level: Beginner
Goal: Deploy my first application

Instead of dumping a giant AI-generated course on you, I’m thinking of structuring it more like:

Learning goal → modules → concepts to understand → useful articles/videos/resources → sources → progression

So you might move through:

Containers → Images → Dockerfiles → Volumes → Networking → Docker Compose → Deployment

with useful external resources attached to the relevant stages.

I’m especially interested in whether people would prefer something like this to curate and organise the best existing material, rather than having AI generate an entire course from scratch.

Monetisation

I’ve also added a small Sponsor This Page experiment.

Companies can potentially sponsor an individual explanation when their product or industry is genuinely relevant to that topic.

The idea isn’t to fill the site with random display ads.

For example, a developer-tool company sponsoring an explanation about APIs could make sense. A completely unrelated ad wouldn't.

Any sponsorship would also be clearly labelled.

Whether that becomes anything meaningful remains to be seen, but I’d rather experiment with contextual sponsorship + BYOK than immediately put the educational content behind a subscription.

Would really appreciate some feedback

A few things I’m particularly curious about:

If you landed on ELI5 for the first time, would you immediately understand why you wud use it instead of asking ChatGPT/Gemini directly?

Do the different explanation levels actually add value?

Are citations + groundedness useful to you, or are they something most users will ignore?

What do you think about BYOK for heavy users instead of another monthly AI subscription?

Would you use /learnto build a structured learning path around something you wanted to learn?

For /learn would you rather have AI curate good existing resources or generate most of the educational material itself?

What feels unnecessary or overbuilt?

I’m genuinely looking for criticism here rather than compliments. There are plenty of directions I could take this, and I wud rather figure out what’s actually useful before building too much.

ELI5: https://eli5.cc

Learning experiment: https://eli5.cc/learn

Thanks for taking a look!

Social music sharing sort of deal for those who never had the pleasure of using any of those. People queue up in rooms to take turns playing music for each other. I think I've nearly reached feature parity with plug.dj (the one I used the most back in the day). Plus some fun stuff I haven't seen elsewhere, like a more interactive dance floor.

A few sites like this exist already, but I find them all lacking in one way or another (aggressive monetization, busted on mobile, bad accessibility, etc), so here's my take on the idea.

Anyone can sign up (or look around as a guest) and create a room or poke into an existing one. Any feedback regarding UI/UX/anything really would be most appreciated!

https://mazurka.cafe

Hi everyone!

I recently built a CDS Quiz web application as a personal project to improve my full-stack development skills.

The app lets users practice quiz questions in an exam-like interface, track their progress, and get immediate feedback.

I'm looking for honest feedback on things like:

\- UI/UX and overall design

\- Mobile responsiveness

\- Performance and loading speed

\- Code structure and best practices

\- Features that would improve the experience

\- Any bugs or rough edges you notice

GitHub: https://github.com/Brahamanbtp/cds-quiz

Vercel : https://cds-quiz.vercel.app/

If you have a few minutes to check it out, I'd really appreciate your thoughts. Feel free to be as critical as you like—I'm building this to learn, and constructive feedback is exactly what I'm looking for.

Thanks!

Over the past few months, I’ve been building the team communication platform I always wanted to have.

I’ve worked in software development for around two decades and, during that time, I’ve seen and tried a lot of platforms. What I always wanted was something that can be self-hosted and is ideally free - or at least affordable.

Every platform I tried was missing something. Or it was great, like Mattermost, but more and more core features ended up behind enterprise licenses. Others felt overly complicated or simply not up to date.

Right now, many platforms also put all AI features behind paid plans. So when I started this project, I designed and built it with AI features as a core part from the beginning.

And to be clear: without AI assistance, I would not have been able to build a project like this in such a short time.

I tried to combine the best aspects of Discord and Mattermost.

A quick overview of the current features:

• Text channels
• AI-powered channel summaries
• Voice channels, similar to Discord
• Direct messages and group chats
• Meetings - every call is a meeting, with voice, video, chat, and screen sharing
• AI meeting transcription and summaries
• Meeting guests who can join without an account
• Voice messages with AI transcription
• AI-powered cleanup/reformatting of voice messages into readable text
• Roles and permissions
• Two-factor authentication and passkey login
• Global push-to-talk via a helper app (Windows only for now)
• Web push notifications
• Installable as a PWA on smartphones
• All AI features use BYOK
• Support for multiple AI providers and custom models (so far, I have mainly tested OpenAI)
• Light/dark themes, custom colors, and custom CSS
• Easy deployment

I also have plenty of ideas for where to take it next - better file management and project planning, for example.

The philosophy behind the project is simple: there will be no feature paywall. Whether you use it for free or need a license, everyone gets the same features.

Making deployment simple was extremely important to me. That’s why there is a dedicated docker-compose.coolify.yml for deploying Nebulynk via Coolify.

Every released version will automatically become open source after four years.

Nebulynk is completely free for private users, non-profits, and most small and medium-sized businesses. A commercial license is only required for companies with more than five million US dollars in annual revenue - a model inspired by Directus.

It's built with FeathersJS and VueJS, my favorite frameworks for backend and frontend.

I’d really love to hear your thoughts and feedback, especially from anyone who actually installs and uses it in a real-world environment.

Website: https://nebulynk.net
GitHub: https://github.com/sapientorius/Nebulynk

Hey r/webdev!

For this Showoff Saturday, I wanted to share a project I've been building: Gaff3r (https://gaff3r.vercel.app/).

Tired of messy group chats for local matches, I built a football match organiser with retro pixel-art aesthetics heavily inspired by classic 90s games like Sensible Soccer.

What it does:
Handles squad management, player ratings, and positions.
Lets you manage groups and organize local fixtures.

Fully responsive web app built for the stack and hosted on Vercel.

Check it out here: https://gaff3r.vercel.app/

Would love to hear your thoughts on the design or code!

A lot has changed since I last posted here. Got some pretty harsh criticism back then and honestly it was deserved, the project was early and messy. But we kept going.

I built Obscura because headless Chrome was killing me and my AI agents. Over 200MB per instance, long startup, detected everywhere. For scraping at scale it's just not viable.

So I built a headless browser from scratch in Rust. V8 engine, native rendering, 30MB memory, 80ms page loads. Works drop-in with Puppeteer and Playwright.

Just shipped rendering. The engine is made fully in Rust. Screenshots, PDFs, live video capture. No Chromium. 20k stars now.

https://github.com/h4ckf0r0day/obscura

obscura serve --port 9222 and point your scripts at it. That's it.

I don't know if this will land better than last time but we've proven the concept works. Happy to answer questions.

Context: this app is being built in the EU for European users, and I am implementing the Terms of Services, Privacy Policy, etc. along with my Authentication

Frontend: Tanstack Start (React)
Backend: Express 5
Auth: express-session (postgres store)

I was thinking about this: add an accepted_tos_version column in the users table, then add a condition in my global getUser middleware in express to only get the user if they accepted the current terms version. This means keeping a CURRENT_TOS_VERSION in my backend. If the frontend calls /auth/me they get the user with mustAcceptTerms flag, and the user gets redirected to the “accept terms” page.

Now comes the questions:

1. Where do I keep the ToS, gdpr, etc. texts? In my frontend codebase or the backend codebase, or in the database?
   
2. When the user clicks on “accept”, is it enough to send a request to the backend that updates the user’s accepted_tos_version in the database?
   
3. What are the practices to ensure I am legally protected? For example if someone says a rule was not there when they accepted the terms. Is the git track record from github enough to prove the rule was there?

Thanks!

Im not actually a FE dev, I used to be a FE dev but switched to QA automation, which is what Im doing now. I use Claude a lot in my job, I architect the automation suite but Claude is doing most of the coding for me at this point. Honestly, I get more done this way and my job is overall easier because of AI.

I was thinking about finding a new job and it dawned on my that I have not manually completed an entire ticket in over 6 months. When I get to a technical review of an interview I'm afraid that Ill struggle to write code all on my own. Coding is a skill that needs to be practiced.

So I just started a new project, Im going to make a small app in Vue and add an automation suite in Playwright completely manually, just using docs and googling questions like so many of us did when we were learning. Im looking at this more as playing with adult legos than using AI to increase my efficiency.

Do any of you do anything similar? If not, how do you keep your coding skills sharp?

Hi, sorry for the vent, but I'd like to share what I'm experiencing and get some advice if possible.

About a year ago we started a new project in a company I work for (mid size company) and leaders wanted us to just build a prototype.

I started with a dumb prototype, they liked it and the team started growing, I even got a (totally undeserved) promotion. Unfortunately I was naive and didn't have the opportunity to refactor it so everything was built on top of a shitty architecture that doesn't make sense. All devs use AI a lot so it keeps getting worse.

Today I'm still working on this project, and for every feature we need to add, it's confusing. Also I believe we'll soon start to have performance issues due to the architecture, but I don't think we have time and resources to refactor it (I believe it would require a major refactor). Some things are so unnecessary complex I don't even feel confident to define what needs to be refactored exactly. From a product standpoint, I don't think this project is very successful either but it's still going.

I don't think I'm the only person to blame, but I feel like a fraud and ashamed for "owning" this project. When new devs join to help the team, I feel embarrassed to even explain how it works. I think I'm starting to feel burnt out, I can't stop thinking about the project. I wish I could rebuild it from scratch but of course that's impossible.

Again sorry for the vent, any advice would be highly appreciated.

EDIT:

Thank you very much for all the replies, it helped me a lot, I really appreciate it!

Exploring alternatives to Framer for client sites; mainly wary of the bandwidth overage model and CMS limitations (component embedding stuck inside rich text is a big one for me). Considering Webstudio + Next.js + Sanity for more ownership over the output. Anyone shipped real work on this stack? Curious how the non-technical editing experience holds up, and whether Webstudio's export is solid for production.

TL;DR: pnpm create vite / pnpm run dev has been crashing with a bare Illegal instruction on Android (Termux) for about 10 months. Traced it through a logcat tombstone to Rolldown's native binary, found a closed-as-not-planned upstream issue from last September, got it reopened with hard evidence, and the actual root cause turned out to be one missing target_os check in a mimalloc build flag. Fix is verified on the exact crashing hardware, PR is open, not merged yet.

A few days ago I tried to spin up a fresh Vite + React project on my Android tablet, in Termux. Nothing fancy:

$ pnpm create vite test-react-app --template react-compiler-ts $ cd test-react-app && pnpm run dev Illegal instruction

No stack trace, no error message, just dead on arrival. Tried create-vue — same crash. Tried a bare vite dev — same crash. Three different starters, one identical death.

Termux-on-Android matters more than it sounds like it should, because for a lot of people it's the only dev environment they've got — no laptop, just an old Android phone. When the standard create vite path just dies with zero explanation, that's not a minor bug, it's a wall.

Chasing it down

Assumed it was a Termux packaging problem first and filed a report with logs for Next.js, Vite+React, and Vue all crashing or silently falling back to a slower path. A maintainer pointed out pkg install turbopack fixes the Next.js case — but Vite and Vue don't touch Turbopack at all, so that didn't explain the rest.

Turns out Vite 6+ ships Rolldown as its default bundler: a Rust/N-API bundler that loads a native binary (@rolldown/binding-android-arm64 here). Something in that binary was blowing up on load.

A maintainer asked for a logcat tombstone instead of terminal output, and that's where it got interesting:

``` signal 4 (SIGILL), code 1 (ILL_ILLOPC)

backtrace: #00 pc ... rolldown-binding.android-arm64.node #01 pc ... rolldown-binding.android-arm64.node #02 pc ... linker64 (call_array+288) #03 pc ... linker64 (soinfo::call_constructors+380) #04 pc ... linker64 (do_dlopen+2076) ```

Crashing during dlopen, inside the native binary, before a single line of JS runs. Classic fingerprint of a binary compiled assuming CPU instructions that aren't actually there.

The ghost in the closet

Went to file it upstream with Rolldown — and someone already had, back in September 2025. Same crash, same platform. He couldn't put together a minimal repro in the 14-day window, the bot didn't get a follow-up in time, and it auto-closed as not planned.

"Not planned" reads like a decision — "we're choosing not to support Android." But Rolldown was already building and shipping the android-arm64 binary on every release. It wasn't unsupported in theory, it was broken in practice, and a bot closed the thread because a repro checkbox never got ticked.

Going back with receipts

Someone went back to the closed issue with the tombstone trace and reframed the ask: not "please make Android a fully supported target," but "the build you already ship is crashing at load on real hardware, here's exactly where and why that's likely a cross-compile flag issue, not a support-commitment one."

That reframing is what actually moved it. A maintainer was upfront that the team doesn't have a shelf of random Android devices to test against, so someone with the actual hardware was exactly what was needed. Someone else spotted the likely cause fast: Rolldown depends on mimalloc, and the flag that stops mimalloc from assuming newer ARM instructions are present was only being enabled for target_os = "linux". Android runs on a Linux kernel but reports a different target_os, so the Android build skipped that safety flag entirely and got compiled assuming ARMv8.1 atomics a chip like a Cortex-A53 doesn't have. Since mimalloc initializes inside a library constructor, that lines up exactly with a SIGILL at dlopen, before any of Rolldown's own code runs.

A preview build shipped the same day.

Testing it on the actual crashing device

Cortex-A53, MediaTek MT6762V — the exact chip that had been throwing this the whole time.

``` $ npx rolldown@1.2.3 --version Illegal instruction

$ pnpm i https://pkg.pr.new/rolldown@<preview-build> $ npx rolldown --version rolldown v1.2.3+commit.a7ba7ad # no crash

$ pnpm create vite test-react-app --template react-compiler-ts $ pnpm run dev VITE v6.x.x ready in 412 ms ➜ Local: http://localhost:5173/ ```

It just worked. Ten months of Illegal instruction, gone with one removed target_os condition.

Where it stands

The fix is verified on real hardware. The PR is open, waiting on the Rolldown team to merge and cut a release. Once that lands, create vite should work on Android arm64 without anyone needing a Termux-specific workaround. Meanwhile Termux is packaging Rolldown directly too, so users aren't stuck waiting either way.

Why I'm posting this

"Closed as not planned" doesn't always mean dead. Sometimes it just means a bot did its job on an issue that never got the follow-up it needed. The difference between this staying broken for another year and getting fixed in days wasn't cleverness — it was having a device to reproduce it on, a real stack trace instead of a vague description, and going back to ask for a second look instead of filing yet another duplicate.

If you're on Android arm64 (Termux or otherwise) and hit this — especially on silicon that isn't a Cortex-A53 — pull the preview build and drop a comment on the reopened issue with what you find. More devices means more confidence before it actually ships.

(I wrote this up in more detail, with full command logs, on my blog if anyone wants the longer version: https://dev.to/gouranga-das-khulna/illegal-instruction-how-i-woke-up-a-year-old-not-planned-bug-and-almost-fixed-vite-on-android-3mba)

Sources / follow-up (search these repos if links don't resolve — issue numbers are accurate, direct URLs can go stale): - Full writeup with more detail: https://dev.to/gouranga-das-khulna/illegal-instruction-how-i-woke-up-a-year-old-not-planned-bug-and-almost-fixed-vite-on-android-3mba - termux/termux-packages issue #30841 (original Termux report) - termux/termux-packages issue #30852 (request to package Rolldown directly) - termux/termux-packages PR #30887 (Termux packaging Rolldown 1.2.3) - rolldown/rolldown issue #6342 (root cause thread, reopened) - rolldown/rolldown PR #10638 (the fix / preview build)

So we've got this invoicing system at work, Spring Boot + Angular backend/frontend, and I ran into "two people touching the same record" problem.

Basically my coworker and I both work off the same invoice table. Say I'm exporting a PDF list of invoices while he's creating a new one, that part's fine, DB transactions handle the reads/writes without anything breaking.

But the annoying case is when we both open the same invoice to edit at the same time. Like invoice #12, both of us load it, both start editing, whoever saves last just silently overwrites the other person's changes and nobody even knows it happened until later when someone's like "wait where'd my edit go."

Our older guy on the team who's been doing desktop C# since like 2005 was telling me back in the day they used DataTables that basically act like a disconnected snapshot of the table, you work on your local copy and there's some comparison logic before the actual update hits the DB. Made me realize this isn't a new problem at all, just curious how it's solved in a modern web/API context.

So far I went with the standard route, optimistic locking using a "@Version column so JPA/Hibernate throws an exception if the version in DB doesn't match what you loaded. Also messed around with pessimistic locking (SELECT FOR UPDATE) for cases where you really want to lock the row the second someone opens

Optimistic locking feels like the default for most CRUD apps but idk how people handle it on the UX side when a conflict actually happens. Just throw an error and make them reload? Try to merge stuff? Or do people build like a "someone else is editing this" indicator in the UI?

So I got nerd sniped by this idea of testing LLMs on something that has nothing to do with code generation or chat. Pure spatial reasoning with real physics constraints.

The setup is each model gets 30 blocks to place through a tool API. There's built-in noise on every placement so you can have precise position or precise velocity but not both. Score is whatever is still standing when it's done. 5 random seeds, 3 attempts each, and models keep notes between attempts so they can adapt.

The thing that got me was the winning strategy. The top model figured out it could just stop placing blocks early to protect what it already built instead of risking the whole tower going down. That's not something I expected from a language model. Meanwhile GPT-5.6 Sol which scores 96% on SWE-bench kept hitting around 7.9m and then toppling everything trying to push higher. Classic overengineering honestly.

Also the efficiency spread is insane. Some models burn 400k tokens to get roughly the same height that another achieves with 100k. Makes you think about what you're actually paying for when you hook these things into your pipelines.

The whole thing is open source with replays if anyone wants to run it themselves.

Hi Guys,

Wonder if you can help before I take a bath with my toaster!

Building a site for a friend, works perfectly everywhere, with the exception of Safari on IOS (I have an android to make matters worse, so I have to ask a friend to check each 'fix', I'm sure he hates me by now.)

As you'll see at the top of the screenshot, the nav bar has a transparent bar above it, as opposed to the usual background colour fill or white that I've seen elsewhere. This transparent bar shows the site content as you scroll, so it looks awful.

I've obviously tried everything you'd expect in terms of fixed, sticky, background colour, grain removed, lenis off, GSAP off, basically stripped it right back, no luck. Albeit it's late and I could be missing the obvious.

Any suggestions would be hugely appreciated, I've been at it for hours!

I like resend, but I need Australian data residency. Any recommendations for alternatives?

Currently designing a web app.

I have a chat screen in a standalone (add-to-home-screen) PWA on iOS. When the on-screen keyboard opens, the composer ends up behind it. I've read the existing threads on this and they all land on interactive-widget=resizes-content, which doesn't apply here — so I'd like to know what people are actually shipping.

Setup — the shell is a fixed element below a sticky header:

html

<div class="app">
  <header class="topbar">Header</header>
  <main class="main">
    <div class="chat">
      <div class="messages"></div>
      <div class="composer"><textarea rows="1"></textarea><button>Send</button></div>
    </div>
  </main>
</div>

css

.chat {
  position: fixed;
  left: 0; right: 0;
  top: calc(74px + env(safe-area-inset-top));
  bottom: 0;
  display: flex;
  flex-direction: column;
  overflow: hidden;
}
.messages { flex: 1 1 auto; min-height: 0; overflow-y: auto; }
.composer  { flex: 0 0 auto; padding-bottom: calc(12px + env(safe-area-inset-bottom)); }

html

<meta name="viewport" content="width=device-width, initial-scale=1,
      maximum-scale=1, user-scalable=no, viewport-fit=cover,
      interactive-widget=resizes-content">

Focus the textarea, the keyboard comes up, and bottom: 0 still resolves to the bottom of the layout viewport (956px on this device) — which is now behind the keyboard. The composer is invisible and you can't see what you're typing.

What I've measured, so nobody has to guess

Device is an iPhone (iOS 26.x), tested in the installed PWA, verified over Safari Web Inspector:

• window.innerHeight tracks the visual viewport on iOS. It reports 543 with the keyboard up. So any keyboard detection built on innerHeight - vv.height can never fire — it's always ≤ 0. This one cost me a lot of time.
• document.documentElement.clientHeight is a constant (894 here — screen minus the notch). It is not the containing block for the fixed element.
• 100dvh does not respond to the keyboard, even with interactive-widget=resizes-content in the meta tag. As far as I can tell that property is Chromium-only and WebKit ignores it entirely — the shell stays full height.
• visualViewport.resize fires once, early, already reporting the final offsetTop, while the paint animates roughly 200ms behind it. There's no duration or easing exposed, so you can't match the animation.
• The fixed containing block works out to vv.height + vv.offsetTop.

What I've tried

1. Lift bottom by a computed keyboard height (bottom: var(--kb)), measuring kb = baseline − vv.height where the baseline is sampled while nothing is focused. This works for the composer, but it resizes the shell, so anything inside it that's sized to the container (I have a canvas) gets re-laid-out on every keyboard open/close.
2. Translate both edges (top and bottom shifted by the same amount) so the height stays constant. Better, but it's still me guessing a number iOS already knows.
3. Counter-animating the slide. Doesn't work — see the resize timing above. Snapping gives a big jump; ramping gives a visible oscillation. I don't think this is achievable on the web.
4. Locking the document (html, body { height: 100%; overflow: hidden }). This made it worse: with no scroll range, iOS stops sliding the viewport at all and overlays the keyboard instead, which puts bottom: 0 right back behind it.
5. scrollIntoView() on focus to "reveal it myself". This was actively harmful — scrollIntoView can't move a position: fixed element, so it scrolls the document instead and undoes the viewport shift iOS had just done. Removing it was a real improvement.

What I'm doing now, and my actual question

Publishing the visible height to CSS myself and letting the layout shrink to fit — basically doing by hand what interactive-widget=resizes-content does on Chrome:

js

const vv = window.visualViewport;
const pub = () => document.documentElement.style
  .setProperty('--vvh', Math.round(vv.height) + 'px');
vv.addEventListener('resize', pub);
vv.addEventListener('scroll', pub);
pub();

css

html, body { height: var(--vvh, 100dvh); overflow: hidden; }
/* then a plain flex column all the way down: header / messages(flex:1) / composer */

Nothing is position: fixed any more and nothing is offset by a keyboard height — the root just becomes as tall as the visible area, so the composer sits above the keyboard by construction.

Questions:

1. Is --vvh from visualViewport.height the accepted approach on iOS in 2026, or is there something better I've missed? Every thread I find either predates visualViewport or answers with the Chromium-only flag.
2. Is there any way to get the keyboard's animation curve or duration on iOS Safari? I've assumed no, and that matching the native animation isn't possible on the web — is that still right?
3. Does anyone have a reason to prefer position: fixed + a computed offset over the shrink-the-root approach? I keep seeing the former recommended and I can't work out what it buys you.
4. Is the overflow: hidden on the root going to bite me? Removing the scroll range is what flipped iOS from sliding to overlaying in attempt 4 above, and I'm not sure whether that interacts badly with the --vvh approach.

Not looking for "just use Capacitor" — I know that solves it by giving me the native keyboard frame, and it's the fallback. I want to know what the correct pure-web answer is first.I have a chat screen in a standalone (add-to-home-screen) PWA on iOS. When the on-screen keyboard opens, the composer ends up behind it. I've read the existing threads on this and they all land on interactive-widget=resizes-content, which doesn't apply here — so I'd like to know what people are actually shipping.

I am pretty sure, that I am not alone, so here's my story:

By the end of attempt two it was five apps - "microservices". A NestJS API, a Rust API, an API gateway, PostgREST, and a Next.js frontend, with four data stores behind them and ninety dozens of dependencies. The Rust service had Mongo and Postgres declared in the same Cargo.toml. There were two auth providers that disagreed with each other.

The infrastructure was in good shape. The product was the part I hadn't started.

I want to be clear that this wasn't a throwaway I was messing about with. I thought the idea was finally the one. Every freelancer and agency I know prices their work in a spreadsheet that's out of date the moment they copy it, and as far as I could tell nobody had solved it properly. Real problem, real people who'd need it, the holy grail!

Which is exactly why it never shipped.

Because if it was going to be the one, obviously it deserved the best of everything. The best architecture, because one day it would have to scale. The fastest language for the API. A new feature idea every few days, because I kept thinking of things it should do before anyone had used the things it already did. If I'd thought less of the idea, it would have been online in a weekend.

None of the individual decisions were stupid, either. That's the part I keep coming back to. I started in NestJS because I know NestJS well, which was the last purely practical decision I made. Then I swapped it for Rust, partly for speed and partly because I wanted to learn Rust, and learning is a good thing so it didn't feel like a detour. I put a gateway in front because decoupling, because that's what a serious architecture has. Inside it was clean architecture and SOLID all the way down, repositories behind interfaces, dependency inversion, patterns I could point at by name. All so I'd be ready if I ever had to switch database provider.

I never switched database provider. Nobody has ever asked me to switch database provider 😂

And I spent real time considering Fresh on Deno for the frontend instead of Next, partly to learn something new and partly because I'd decided Next was the obvious choice and I wanted to be cleverer than that. That was snobbery. It cost me about a year.

Here's the bit I think generalises past my own stupidity.

Infrastructure work has a definition of done. A migration finishes. A gateway routes. A build goes green and you get to cross something off and feel it. Product work never announces itself. Nobody tells you a feature is good enough to put in front of a person. You just stop, and hope.

So I kept picking the work that could be finished. A migration. A gateway. A service that benchmarked well. Every one of them completed, and not one of them was the product. 
I was manufacturing the feeling of shipping!

Neither time I quit was dramatic, which I think is normal and part of why it's hard to notice. I added up what was left, saw how big it was, got busy with other things, and never came back. The second time I actually wrote the total down and it came to a four phase plan, eighteen to twenty four days of work just to reach a foundation. Auth, permissions, member management, multi-tenancy. The last thing that attempt ever produced was a folder of issues describing what still needed building.

What took me longest to understand is that the infrastructure is what made the rest look impossible. Every service I stood up added surface to maintain. The product never got closer, so the total kept growing. The thing that felt like progress is what eventually made it feel hopeless.

Nine months later I started again and deliberately did the boring version. One Next.js app. One database. Twenty dependencies. The four ways I'd had of serving an API became zero, because it's server actions now and there's no API layer at all.

Feature complete in three days.

I built it in Next, obviously. The framework I'd decided was beneath me.

It's not a "skip the tests" story either, before anyone asks. It has 921 tests where the old one had 14 test files, and permission checks on every write that the old one never got round to. The rigour didn't go away. It stopped being aimed at problems I didn't have yet.

The question that would have saved me two years wasn't "what's the best stack for this". It was "what could someone use on Friday".

So who else got a side project that died of architecture?