In this article, I’ll tell you what annoys me the most about JavaScript and why I sometimes prefer to build an application in C# with .NET and… Blazor, which lets me avoid many of JavaScript’s pain points. But more on that later.
Type Chaos and Bizarre Conversions
1. Comparing Values
The biggest nightmare? Equality and type coercion. In JavaScript, '==' and '===' live in completely different universes.
• '==' compares values with automatic (and sometimes absurd) type conversion.
• '===' checks equality of both value and type.
Example in JavaScript
[] == false /* true */
[] == ![] /* true */It doesn’t look like much, but “weird stuff” like this really exists. No wonder it’s so easy to introduce bugs.
How does this look in C#?
In C#, there are no such “surprises.” Type comparison is always explicit, and conversions must be performed intentionally.
int x = 5;
string y = "5";Comparison requiring conversion
bool result = x == int.Parse(y); // trueIt’s simple and readable: if I want to compare a number with a string, I have to take care of the conversion myself.
2. NaN Is a Number
Another example? In JavaScript, 'NaN' (Not a Number)… is of type 'number'.
• 'typeof NaN' returns 'number'.
• On top of that, 'NaN != NaN', so 'NaN' isn’t even equal to itself.
In C# we also have `double.NaN`, but there it behaves much more predictably. You don’t run into such bizarre cases in everyday comparisons.
Lack of Strict Typing
JavaScript is, by design, a dynamically typed language. On the one hand, that gives flexibility; on the other, it breeds chaos. You can assign a number to a variable, then later assign a string to the same variable, which in larger projects makes it easy to slip up.
In C#, we have static types, and if we want flexibility, we can use the 'dynamic' keyword. But that’s our choice, and we do it only when it really makes sense. Thanks to this, our .NET applications are more readable and less prone to bugs caused by unexpected type changes.
The 'this' Context – Sometimes I Don’t Know Who I Am
If you’ve programmed in JavaScript, you know that 'this' can depend on how a function is called, not where it is defined. Hence all those 'bind', 'call', and 'apply' littering JS code.
In C#, `this` always refers to the current instance of the class we’re in. No room for strange surprises. It just behaves the way you’d expect.
Hoisting and Variables Without Declarations
In JavaScript, variables defined with 'var' are subject to hoisting – you can reference them before they are declared (though they’ll have the value 'undefined'). And if you accidentally omit 'var'/'let'/'const' in a declaration, you silently create a global variable!
In C#, you either declare a variable or you get a compile-time error. And honestly – that’s a good thing. This kind of discipline protects us from a lot of silly mistakes.
Why Do We (Sometimes) Love JavaScript Anyway?
To be fair:
• JavaScript is everywhere – in browsers, on servers (Node.js), and in automation tools.
• It has a gigantic ecosystem of libraries and frameworks.
• It becomes likable once you learn its traps and quirks.
However, if you’re a C# developer, you’ve probably wondered more than once:
Is it possible to write web applications without “pure” JavaScript?
Yes – Blazor on .NET lets you build interactive SPAs without touching JavaScript nearly as much as in traditional front-end projects.
What If We Could… Avoid JavaScript?
Since the topic here is “what annoys me most in JavaScript,” I wouldn’t be myself if I didn’t mention an alternative that lets you keep the front-end nature of the app – but in C#.
Enter Blazor – a framework from Microsoft that allows you to write front-end logic in C#. On top of that, you can run the code directly in the browser thanks to WebAssembly (Blazor WebAssembly) or on the server (Blazor Server).
And for people who want to reduce the number of potentially dangerous JavaScript “features” in their projects, I’ve created a complete online course – Blazor School. You’ll find practical examples of building applications without wrestling with dozens of JS oddities. In short – less frustration, more productivity.
Summary
JavaScript – despite being so ubiquitous – can drive developers up the wall with its paradoxes, inconsistencies, and excess freedom. Compared to C#, where we have strictly defined types and predictable syntax, JavaScript can feel like a kingdom of chaos.
Fortunately, for .NET fans there are alternatives like Blazor, where we can use our beloved C# to build web applications and reduce the need for classic JavaScript to a minimum. If you’d like to see how this works in practice, I encourage you to check out the complete course Blazor School.
