Why the Rewrite?

🙏 Standing on the shoulders of giants

🔗 Try it yourself

🤔 Is a rewrite actually the right call?

📊 By the numbers

🔬 Real problems, with evidence from the code

These aren't theoretical concerns. Each one is grounded in specific code from the legacy source.

• ☠️
  SQL injection — user input flowing straight into queries

  In the original PHP, user-controlled values are interpolated directly into SQL query strings. Escaping is inconsistent and easy to miss. The .NET rewrite uses an ORM that generates parameterised queries by design — it is not possible to accidentally concatenate user input into a query. Safety is the default, not a discipline you have to remember.
• ⏳
  Every page load blocks waiting for Steam

  Loading a player profile in the original PHP triggers a synchronous call to the Steam API mid-render. If Steam is slow, your page is slow. If Steam is down, your page hangs. The .NET rewrite is fully asynchronous — Steam is contacted in the background, avatars are cached, and the page renders immediately regardless of Steam's availability.
• 🐌
  Sequential database queries — one at a time, every time

  The PHP player profile runs its database queries one after another in a single blocking thread. The .NET rewrite runs all independent queries in parallel — everything the page needs is fetched concurrently, and the page assembles as results arrive. On busy servers with large datasets, this is the difference between a fast page and a timeout.
• 🔓
  Database errors expose your server details to every visitor

  When the original PHP encounters a database error, it renders the server address, connecting username, and the failed query directly in the browser. Any visitor who triggers an error sees your infrastructure. The .NET rewrite shows a safe error page to users and routes full exception detail to the application log only.
• 🌐
  Global shared state — untestable and unpredictable

  Every PHP page and function reaches into shared global variables for the database connection, configuration, and game context. There is no isolation between requests and no way to test anything in isolation. The .NET rewrite uses dependency injection throughout — every dependency is explicit, swappable, and independently testable.
• 🪲
  The Perl daemon: 3,000+ lines, no tests, no strict types

  The original daemon is a single large Perl script with variable strictness disabled, server state buried in nested data structures, and no unit tests whatsoever. When something breaks, the only tool is adding print statements and reading the output. The .NET daemon is a structured async worker service with typed event handlers, clean separation of concerns, and a full unit test suite.
• 📦
  Deployment: hand-edit source files, install Perl, cross fingers

  Getting the original running requires Apache, PHP, Perl, several CPAN modules, and credentials pasted directly into source files — which routinely end up committed to version control. The .NET rewrite ships with Docker support and an environment-variable configuration system. The full stack starts with a single command. No Apache. No Perl. No editing source files to set a password.

✨ Beyond parity — features the original never had

Rewriting from scratch isn't just about cleaning up old code — it's an opportunity to add things that were never feasible in the original architecture. These are already shipped.

🔧 Broken in the original — working again

Some features in the legacy installation are actively broken for many users today — not just outdated. These are restored in HLStatsX.NET.

🛡️ Security, integrity, and future-proof technology

The original was built in a simpler time, before modern web security practices were established. HLStatsX.NET treats security as a first-class concern, not an afterthought.

• 🔐
  SQL injection is structurally prevented

  The original mixes user input into database queries and relies on every developer remembering to sanitise every value on every code path. HLStatsX.NET uses a modern ORM — safe queries are the only option, not a discipline that must be enforced manually.
• 🔑
  Secure admin authentication

  The original admin panel uses basic password checks with no brute-force protection and no defence against cross-site request forgery. HLStatsX.NET uses modern authentication with properly hashed passwords and request forgery protection built in by the framework.
• 🛡️
  Cross-site scripting protection by default

  In the original, displaying any variable as HTML requires developers to manually escape it every time. In HLStatsX.NET, all output is safely encoded by default — unescaped output requires an explicit opt-in.
• 🚫
  Credentials are never stored in source files

  The original stores database passwords directly in configuration source files that routinely get committed to version control. HLStatsX.NET keeps all secrets outside the source tree entirely.
• 📦
  Built on a modern, actively maintained platform

  Some installations of the original still run on PHP versions that reached end-of-life years ago. HLStatsX.NET targets .NET 10 — a long-term support release with guaranteed security updates and an active development roadmap.
• 🐳
  Isolated, reproducible deployment

  The original runs in a shared server environment where any misconfiguration on the host can affect the application. HLStatsX.NET runs in a container — isolated, immutable, and consistent across every environment it's deployed to.
• 📝
  Open source — same licence as the original

  HLStatsX.NET is GPL-2.0-or-later, honouring the licence of every project it builds on. The source is published openly on GitHub — fork it, extend it, and contribute back.
• 🧪
  Changes are verified automatically

  Every contribution runs against a full automated test suite. If a change breaks anything — a page, a calculation, a daemon parser — the build fails before it can ship. The original has no automated tests of any kind.

🚀 What's still to come

Completing parity with the original

Planned improvements beyond the original

📋 Head to head

🤝 Get involved