C# Deserves Better. So We Built It.

# csharp# dotnet# webdev# javascript
C# Deserves Better. So We Built It.George Rios

Go to any new API platform, any hot developer tool, any freshly launched SDK. Scroll to the code...

Go to any new API platform, any hot developer tool, any freshly launched SDK. Scroll to the code examples. You'll see Python. You'll see TypeScript. Maybe Rust if they're feeling adventurous. Five years ago, you'd see C# right there alongside them. Ruby too. Now? Nothing.

This isn't because C# got worse. It got better--dramatically better. Minimal APIs, native AOT, top-tier performance benchmarks, a type system that would make TypeScript developers weep with envy. But somewhere along the way, the ecosystem stopped showing up. The community stopped demanding a seat at the table. And the rest of the industry quietly moved on without us.

The .NET Visibility Problem

Here's the thing about ecosystems: they're self-reinforcing. When a new developer sees Python and TypeScript examples everywhere, they learn Python and TypeScript. When they build products, they build them in Python and TypeScript. When they launch developer tools, they write docs for--you guessed it--Python and TypeScript.

Meanwhile, .NET developers are out here building enterprise systems that process millions of transactions a day, running cloud infrastructure that never goes down, writing code that is genuinely excellent--and getting zero credit for it in the broader developer zeitgeist.

The language doesn't need a glow up. The ecosystem does.

So We Built nugx.org

For years, .NET developers have relied on NuGet--and it's solid. The registry works. The CLI works. But when it comes to discovering packages, understanding dependencies, or comparing alternatives, the default experience leaves a lot on the table.

So we built nugx.org--an alternative NuGet front-end designed for how developers actually work:

  • Better search. Results ranked by relevance, not alphabetical order. You shouldn't have to know the exact package name to find what you need.
  • Popularity and usage signals. Download trends, version adoption, maintenance activity--the signals that actually help you decide between three packages that do the same thing.
  • Dependency graphs at a glance. Before you install a package, you should know what you're pulling in. Not after. Not buried in a CLI output nobody reads.
  • A cleaner, faster UI. This is 2026. Developer tools should feel like developer tools, not government portals from 2011.

It's free, it's open, and it's live right now. If you're a .NET developer, go break it and tell us what's wrong. Seriously.

Why Build This in Public

I've spent my career building software for clients behind NDAs and closed doors. That work pays the bills and I'm proud of it. But there's a problem with only building in private: nobody sees the craft. Nobody benefits from the decisions, the tradeoffs, the hard lessons.

Building in public isn't about clout. It's about accountability. When you ship something the community can see and touch and criticize, you can't hide behind vague roadmaps and polished pitch decks. The code either works or it doesn't. The experience either respects the developer or it doesn't.

nugx.org is the first public artifact of something bigger we've been building. And I want people to watch the whole thing happen--warts and all.

Interested in learning more? Continue here...