Coding With David

Ten hours of manual file-moving work dropped to about ten minutes. For the people on that team, that meant nearly ten hours of tedious, error-prone friction erased from their work week. But for me, the most striking part wasn't just the time saved—it was how we got there. The application itself had been vibe-coded in a couple of days during a hackathon, and getting that prototype into a secure, production-ready state took another two days of engineering work. Now that everyone can create a convincing prototype, how do we turn the worthwhile ones into applications people can depend on? The most interesting question about vibe coding isn't what happens during the demo. The screens look good, the workflow makes sense, and the business users are excited because someone built in forty-eight hours what used to take weeks just to explain. Then comes the inevitable friction: If it only took two days to build the app, why would it take months to put it into production? I found m...

When I share these raw HTML controls for Blazor, the goal isn't just to walk through C# syntax or show off lifecycle methods. It’s about taking a step back to look at the types of UI controls you can actually create when you strip away heavy third-party component libraries and lean into native web standards. Too often, we reach for massive UI suites or build clunky, full-page forms just to update a single piece of text. If a user just wants to rename a project, tweak a purchase-request description, or fix a typo on a dashboard label, forcing them into a modal or a separate edit screen is overkill. It breaks their flow. Instead, we can build a clean, accessible Inline Text Editor using nothing but standard HTML elements and a bit of Blazor state management. Click the text, edit it right where it lives, and either save it or walk away.

I needed a few basic controls for a side project and I refuse to pull in a massive JS bundle or write interop code if I don't have to. So I spent way too much weekend time building four common components using strictly C# and CSS. No IJSRuntime , no hidden script tags in wwwroot , and no node_modules folder blowing up my disk space. Here is what I ended up with: A carousel. Full of dogs because obviously. A credit card form. Complete with a live 3D card flip when you hit the CVC field. A hover card. Preview links on hover without needing an external library. A questionnaire. Built as a Batman quiz because testing things with boring lorem ipsum forms is miserable. Visit the demo site! Why avoid JS here? Honestly, every time you reach for JS interop in Blazor, you're introducing a second language to debug when something blows up at 11 PM. If you keep the state logic in C# and let modern CSS handle the visual presentation (like animations and 3D transforms...

I wanted to keep rolling with my series on turning raw HTML, CSS, and JavaScript into clean Blazor components—and honestly, I just wanted to build something fun for a change. So, I put together a little playground I'm calling David's Cool Components . It's got a colorful countdown timer, a sleek digital clock, a rotating testimonial slider, and a slide-out navigation menu tying it all together. No grand enterprise architecture here. Sometimes you just want to make stuff move on the screen, watch numbers tick down, and say, "Hey, that actually looks pretty slick!" But beneath the fun stuff, it turned out to be a solid exercise in taking plain web component behaviors and expressing them naturally in Blazor. Check out the demo site!! Four Colorful Boxes and Something to Look Forward To The countdown is the first thing you see when you land on the app. It features four chunky, rounded cards displaying days, hours, minutes, and seconds against a dark backgr...

When building a Blazor application, it is easy to reach for a heavy component library every single time you need something visual on the screen. Component libraries certainly have their place, but they are never a hard requirement for building clean, attractive user interfaces. Blazor lets us use the exact same HTML and CSS that power the rest of the web. We can build robust layouts with CSS Grid, arrange content cleanly with Flexbox, animate navigation panels with CSS transitions, and rely on ordinary buttons, links, and images. Then, we wire up the interactions using C#. To prove this out, I put together a small .NET 10 Blazor WebAssembly application featuring three distinct examples: A slide-out navigation menu. A custom multi-select control. A responsive restaurant menu complete with food photography. None of these examples relies on a third-party UI component library. Their visual presentation comes purely from HTML and CSS, while their application behavior is...

Say what it is, not how it looks How meaningful markup makes Blazor applications more accessible, maintainable, resilient, and understandable. Blazor lets us build interactive web applications with C# and Razor components. That changes how we write application logic, but it does not change what the browser receives: HTML. That last detail matters. A polished Blazor application can look correct while still being difficult to navigate with a keyboard, confusing to assistive technology, hard for search engines to interpret, and unnecessarily complicated to maintain. Semantic HTML helps solve these problems by giving content a clear purpose. Instead of describing how an element should look, semantic HTML describes what the element is. <!-- Describes presentation through class names --> <div class="top-navigation">...</div> <div class="page-content">...</div> <!-- Describes purpose through native elements --> <nav aria-la...