Posts

Modern HTML Replaced Your UI Framework (You Just Didn’t Notice)

Image
You Don’t Need a UI Framework Anymore Modern HTML & CSS Are the UI Library For years, the default answer to “How do I build a UI?” has been: Use React Use Angular Use a component library like Telerik, MUI, or Bootstrap That advice made sense 10 years ago . It makes far less sense today. Modern HTML and CSS have quietly absorbed huge portions of what UI frameworks used to justify themselves for — and most teams haven’t noticed. This post shows how far plain HTML + CSS has come, how much payload you can avoid , and why building a native, framework-agnostic UI library is now not only possible — but often the better architectural choice. This is a continuation of a previous post, Beyond AI: Why HTML Elements Still Boost Productivity in Blazor The Hidden Cost of “Just Use a Framework” Before we even look at code, let’s talk about downloads . Typical UI stack sizes (approximate, min+gzip) Stack Download Size React + React DOM ~120–150 KB React + common UI libs 300–600 K...

Why Repository Abstractions Usually Hurt Blazor Apps More Than Help “You didn’t decouple EF Core. You just hid it badly.”

Image
 “You didn’t decouple EF Core. You just hid it badly.” I’ve built this architecture. More than once. Early in my Blazor projects, adding repository abstractions felt like the responsible thing to do. The code looked clean. The layers were clear. Code reviews were easy. Then the app grew. The team changed. Performance started to matter. That’s when the repository layer stopped helping—and started getting in the way. This article isn’t about theory. It’s about what I’ve learned the hard way, maintaining long-lived Blazor applications. Why I Used Repositories (And Why They Felt Right) I didn’t introduce repositories because I was careless. I did it because: Books recommended them Talks showcased them Juniors expected them “Clean Architecture” diagrams normalized them And early on? They worked. That’s the trap. The Year-Two Problem The pain never shows up in month three. It shows up when: Queries need tunin...

Stop Hardcoding AppSettings: A Clean Pattern for Blazor Environment Configuration

Image
  If your Blazor app works locally but breaks in Azure, there’s a good chance configuration is the real bug. Blazor developers often treat configuration as a startup concern —something you wire up once and forget. That works… until you add environments. or feature flags. or secrets. or a second app. Then the configuration quietly turns into a distributed liability . Let’s talk about why hardcoded AppSettings patterns don’t scale—and a cleaner, environment-aware approach that actually survives real projects. The Common (But Fragile) Pattern Most Blazor apps start like this: // appsettings.json {   "InCounter": 5,   "FeatureFlagStyleTable": true } Var styleTable = configService.Value.FeatureFlagStyleTable; At first, this feels fine. Then you add: appsettings.Development.json appsettings.Test.json appsettings.Production.json Azure App Service settings Feature flags Secrets in Key Vault Suddenly: ...

Stop Asking for Real-Time Data (You Probably Don’t Need It) Or: Why “real time” is one of the most expensive words in software architecture.

Image
  The uncomfortable truth After decades of building enterprise systems, here’s an observation that makes some people uncomfortable: Most people who ask for “real-time” data updates don’t actually need real time. What they want is confidence , responsiveness , and trust — not millisecond precision. And yet, the moment the phrase real time enters a requirements meeting, costs go up, architectures get complicated, and teams quietly inherit a system they now have to babysit forever. What people say vs. what they actually mean When someone says: “We need this data in real time.” They usually mean: “I don’t want stale data.” “I don’t want to refresh the page.” “I want to react quickly.” “I want to trust what I’m seeing.” None of those requires true real-time infrastructure. They require fast-enough data and good UX . Once you cross into true real time , you introduce: Persistent connections Stateful servers Fan-out scaling challenges Reconnection logic O...

Does Anyone Know What Time It Is?

Image
  If you’ve ever written a unit test that failed only on Tuesdays , only after midnight , or only on CI but never locally , then congratulations — you’ve been personally victimized by DateTime.Now . Time is one of those sneaky dependencies we rarely think about… until it breaks our tests. Thankfully, modern C# finally gives us a first-class way to deal with time in a testable, civilized way: ๐Ÿ‘‰ TimeProvider Let’s talk about why it exists, why it matters, and how it makes your unit tests calmer, cleaner, and way less haunted. ๐Ÿงจ The Classic Problem: Time Is a Liar Here’s a pattern we’ve all written: public bool IsExpired ( DateTime expiresOn ) { return DateTime.Now > expiresOn; } Seems harmless, right? Now try to unit test it. What time is it right now ? What happens if the test runs at midnight? What about daylight saving time? What if the test is slow? What if it runs in a different time zone? You don’t control time — time controls you . ๐Ÿง  Enter: TimePr...