Coding With David

  Image Generated by ChatGPT For years, developers working with JavaScript frameworks like React and Next.js have been able to lean on AI tools like Copilot, Claude, or Cursor to rapidly spin up applications. In those ecosystems, “vibe coding” – letting the AI take a prompt and generate a surprisingly functional application – is a real and tangible experience. But what about Blazor? Could you vibe code in a .NET environment where structure, conventions, and configuration matter far more than in lightweight JavaScript apps? The short answer: yes, you can. It’s not the same as working in Cursor with React, where you can drop in a one-liner prompt and have a complete working skeleton in minutes. With Blazor, you can absolutely use AI to accelerate your workflow – but you need to do some of the setup yourself. Once you’ve got that foundation, Copilot becomes a surprisingly capable “junior developer” that saves hours of coding and testing time. Let’s walk through exactly what I ...

  Why Is It So Hard to Find "Just One" Blazor Component? Blazor is a fantastic framework. It lets C# developers build interactive web UIs without touching a single line of JavaScript. But as the framework matures, a common frustration is bubbling to the surface: the state of its UI component libraries. While there are many powerful options available, they often present a frustrating, all-or-nothing dilemma. Why can't you just grab a single, well-made component without buying into an entire ecosystem? Your observation is spot on. Unlike the React world, where developers can easily find and install individual components—from a simple tooltip to a complex data grid—the Blazor landscape feels different. It's an issue of walled gardens. The "All-or-Nothing" Problem Most major Blazor UI libraries, both paid and free, are built as comprehensive suites. They provide dozens of components, from buttons and inputs to charts and schedulers. This is great if you're s...

  In the ever-evolving landscape of web development, choosing the right framework can be the most critical decision you make. For years, the conversation has been dominated by JavaScript libraries and frameworks. But with the power of WebAssembly, Microsoft's Blazor has emerged as a formidable contender, challenging the status quo and offering a compelling alternative for C# and .NET developers. While the most obvious difference is the language—the ubiquitous JavaScript for React versus the robust C# for Blazor—the real story lies deeper. The fundamental architectural philosophies, rendering strategies, and developer experiences set these two frameworks on divergent paths. Let's move beyond the surface-level language debate and explore the core differences that truly matter in 2025. The Core Architectural Difference: Rendering Philosophies The most significant distinction between React and Blazor is how they approach rendering content and handling interactivity. React: The Java...

  When designing and building a software solution, you must always keep your users in mind.  These may seem like minor details or not worth the coding effort but saving your users time, money and even their business can go a long way to building customer loyalty.   Here are a couple real-life little UX and system changes that had a huge impact on a user or even a company. "Could I just hit enter" This question came from a user of a sales ordering software application.  At the top of the Orders screen, there was a text box where the user would enter a sales order number.  They then would tab or use the mouse to click a lookup / find button.   As a team, we thought the UX was very cool, just 2 steps to look or find an order.  We had a session with the user to show off our new UI, with all the bells and whistles.  They were very polite and liked what we showed. At the end, we asked a simple question, "What do you think?".  She said it ...

You may be asking yourself, what’s the difference, plenty.  If you are a developer who only codes because it is your job and you make a good living, which there is no problem with that, you may not enjoy working for a software company. Both companies need those types of developers.  But if you align yourself as a software engineer, who likes solving problems and is passionate about the profession of Software development, then you want to work for a Software company.  A company that makes and sells software is usually founded by a domain expert who wrote or had a friend write an application he needed, and they started reselling it.  A software company has usually evolved from a company that sells software but learned that the value they are providing to their customers is a high-quality system and high-quality customer support that improves the user’s lives.   My goal is not to state that one type of company is better or worse than the other, my goal is to ma...