119 karma · joined November 7, 2015
Good architecture, actor models, and collaboration patterns do not emerge magically from “more agents”.
Maybe what’s missing is the architect’s role.
If we outsource the whole “hands that think” loop to agents, we may ship faster… but we also risk losing the embodied understanding that lets us explain why something is hard, where the edges are, and how to invent a better architecture instead of accepting “computer says no.”
I hope we keep making room for “luxury software”: not in price, but in care—the Swiss-watch mentality. Clean mechanisms, legible invariants, debuggable behavior, and the joy of building something you can trust and maintain for years. Hacker News needs more of that energy.
I’m evaluating UI options for a new .NET product and I’m struggling to find balanced, experience-based pros/cons about Blazor (Server / WASM / Hybrid) compared to alternatives (React/Vue/Angular + API, MAUI/WinUI/WPF, etc.).
I’ve seen critical takes like this one: https://alexaka1.dev/blog/blazor-sucks
…but I’d love to hear from people who have actually shipped and maintained Blazor apps.
A few questions I’m trying to answer:
In practice, where does Blazor shine (team composition, product type, deployment model)?
What are the real pain points after 6–18 months (tooling, performance, debugging, interop, upgrades)?
Any “gotchas” that only appear at scale (large component trees, state management, long-lived connections, memory)?
If you had to start a new product today, would you pick Blazor again? If not, what would you choose and why?
Context: this is a long-lived product (multi-year), typical CRUD + some rich interactions, and we care about maintainability and developer velocity.
Thanks for any first-hand advice.
A simpler approach works surprisingly well:
Store atomic mutations locally (Redux-like) in SQLite.
Sync those mutations to a central server that merges with last-writer-wins.
Handle the few conflicts that do occur through clear ownership rules and some UI/UX design.
This makes local-first behave more like Git: clients work offline, push their “commits,” and the server decides the truth. Most of the complexity disappears if the data model is designed with collaboration and ownership in mind.
time based game over isn't a good idea.
good typer's are advantaged
insteed of that, distribute "try" token
More infos: https://en.m.wikipedia.org/wiki/Variable_speed_of_light
Paper: http://www.januscosmologicalmodel.com/pdf/1988-ModPhysLettA-...
one domain give one package/module, domains are now dependencies
actors models can act as services, one actor in a domain is a service with an API communicating with other trought event loops or tcp/ip (microservice?)
we can develop and debug the whole system in a mono-repo <- the monolith is the repository of code.