I’ll point to how many functional languages handle it. You create a type Maybe a
, where a
can be whatever type you wish. The maybe type can either be Just x
or Nothing
, where x
is a value of type a
(usually the result). You can’t access the x
value through Maybe
: if you want to get the value inside the Maybe
, you’ll have to handle both a case where we have a value(Just x
) and don’t(Nothing
). Alternatively, you could just pass this value through, “assuming” you have a value throughout, and return the result in another Maybe
, where you’ll either return the result through a Just
or a Nothing
. These are just some ways we can use Maybe
types to completely replace nulls. The biggest benefit is that it forces you to handle the case where Maybe
is Nothing
: with null, it’s easy to forget. Even in languages like Zig, the Maybe
type is present, just hiding under a different guise.
If this explanation didn’t really make sense, that’s fine, perhaps the Rust Book can explain it better. If you’re willing to get your hands dirty with a little bit of Rust, I find this guide to also be quite nice.
TLDR: The Maybe
monad is a much better alternative to nulls.
Yeah I mean if you really want a UI with no JavaScript you can still use one, it’s really just a case of better defaults here (and I totally agree).