Imagine you're halfway through your third cup of coffee, navigating through a sea of null in your codebase, and you can't help but whisper to yours...
For further actions, you may consider blocking this person and/or reporting abuse
The horrors described in this (wonderful, mind you) article only exist in TypeScript.
Oh G-d, how I hate TypeScript.
I will present the antithesis of TypeScript and say Dart, is a null-safe language, in which variables must be declared as nullable. The compiler prevents you from using a nullable value without checking if its empty first, which reduces bugs significantly and makes it so you will only use nullable variables when you have to (e.g. dynamic server response).
Most languages are not built to break like Typescript. Unfortunately people still use Typescript.. this devastating fact caused you to write this article.
When coding Javascript, I try to avoid undefined as much as I can and use null when an empty value is required. This brings Javascript up to par with nicer languages (like Dart, I love Dart, it’s truly great).
IMO using undefined (instead of null) makes TS feel more like a Null-Safe language. The compiler makes sure you check for undefined values.
Yes the compiler will force you to check for null as well, but you can't avoid undefined in JS it is everywhere, missing properties, missing arguments, everywhere.
I prefer to only use one of both, and it's definitely not null.
Just make the compiler strict and it will annoy you as much as you need to write good code.
Should be "Why null in JavaScript is an Abomination".
I'd argue that the workarounds for null are far worse than the problem. E.g. in a consistent language like Java null is far less of a problem.
I saw the title, & thought that the article was about using
"null"instead ofnull& expecting it to work likenull.Fascinatingly, I rarely struggle with
null. When I do, usually the fix is straightforward as I have an error stack, I put in aconsole.logsee what went wrong and fix it in no time. I quickly forget aboutnullrelated errors.For me the trillion dollar problem is swallowing errors.
try {} catch { // do nothing }. That is way, waaaay bigger of a problem as now everything works until it does not, but you have no error stack, no pointer, nothing where the problem occurred.The first version of
Angularinfamously made the decision to swallow any errors coming from the template, wasting thousand of hours of my colleagues and me. I still remember the pain of accidentally writingmy-value="string-value"instead ofmy-value="'string-value'"; no error messages, no warnings, nada.A good ole
nullerror? As I said, 15 minutes fix. Unless it is coming from something swallowing an error in the chain beforehand.As Tony Hoare the problem is not null which is itself perfectly fine.
The problem was that it wasn't part of the typesystem.
In a modern programming language which has null in the type system, null is great, in fact it's better than the alternatives of using an Option Monad or similar
By curiosity, why do you think it's better than the
Optionalternative?medium.com/@fatihcoskun/kotlin-nul...
I don't think it is an abomination, most developers just misuse it as it is a way to cut corners, since you can switch off strict null checks in ts and throw null into anything.
I avoid null in JS/TS. If there is an API that returns null, I immediately coalese to undefined:
From this point the compiler forces me to check if the value is undefined.
I only struggle with null/undefined values in legacy code.
The concept that "null is an abomination" I can explain with the idea that handling null values in programming can lead to errors, bugs, and unexpected behavior if not managed properly.
The problem arises when developers don't appropriately check for null values before using them, leading to exceptions that can crash programs or cause unexpected behavior. These errors can be particularly tricky to debug because they often occur at runtime rather than compile time. To avoid these issues, developers are encouraged to handle null values explicitly in their code, either by checking for null before using a variable or by using techniques like defensive programming, where methods and functions are designed to handle unexpected inputs gracefully.