nexo-v1

Loved the process write-up and the iteration screenshots. The hero section looks cool, but the rest of the front page could be refined even further (it still has an AI‑generated look).

When doing web designs with AI, I start with design tokens, typography, then build out every section by multiple iterations. Unfortunately, the more vague the prompt is, the more "AI‑generated" the end result looks.

I was never happy with how heavy LocalStack was, so I'm going to try this for my next green field cloud app.

I think having such emulator being lightweight and quick to run becomes more important in AI coding/worktree-based workflows where it's important to pre-setup the worktree with dependencies and dependent services on local ports.

I like the minimalistic UI, nice design, and quick startup times, but how is this better than Safari in practice?

It is available, but the last time I tried it, I was only able to select specific audio files for import. I couldn't import the whole directory at once

I switched to DuckDuckGo recently too. It's good enough for most things, but for deeper or niche info, I still bounce back to Google (with uBlock).

Haven't tried Kagi yet — not sure the difference is big enough to pay for.

Honestly, I'm still stuck using some Google stuff anyway, like Maps. I'd like to de-Google a bit more, but in practice it's hard.

Out of curiosity, what influenced your decision to prioritize stepping and watchpoints early? Was it driven more by debugging your own compiler code, or anticipating end-user needs

I keep coming back to the idea of curating my own reading through RSS.

I missed the first wave: mostly stuck to aggregators and blogs, but eventually set up a Feedly account. Like others here, I found maintaining a meaningful list takes real energy. It's easy to over-subscribe and end up with a second inbox.

Still, I think the effort is worth it. The best systems I've worked on always rewarded small, regular maintenance over trying to automate everything away. Feels like curating information works the same way.

This sounds a lot like structured logging with a fresh coat of paint. Wide events are nice conceptual model, but if you’ve been doing structured logs seriously, especially with something like Loki or ELK stack, you’re already capturing rich context per event — including things like user info, request paths, even DB queries if needed.

I’ve been using Loki recently and really like the approach: it stores log data in object storage and supports on-the-fly processing and extraction. You can build alerts and dashboards off it without needing to pre-aggregate or force everything into a metrics pipeline.

The real friction in all of these systems is instrumentation. You still need to get that structured event data out of your app code in a consistent way, and that part is rarely seamless unless your runtime or framework does most of it for free. So while wide events are a clean unification model, the dev overhead to emit them with enough fidelity is still very real.

Shipped and supported enough startup apps to learn this the hard way: users will delete things they shouldn’t, and you will be asked to explain or undo it. Soft deletes and basic metadata (created_at, deleted_by, etc.) have saved me multiple times — not for some future feature, just for basic operational sanity.