Hacker News Reader

Comment by orange8 | Hacker News Reader

> I get almost as much benefit from the rigorous null checking in TS as I do from the typing. I would use it for that alone. [1]

This.

I suspect there is a certain way those who rave about TS like yourself write and structure their code (all code, regardless of language) in a way that naturally lends itself to strict typing. The "rigorous null checking" comment struck me as odd, as someone who has written JS for almost 20 years, I've just never had to think about, or use null values. I probably just use the good parts of the language and avoid the bad [2]

[1] https://news.ycombinator.com/item?id=23913294

[2] https://www.oreilly.com/library/view/javascript-the-good/978...

View on HN

You can't avoid null and undefined in your code unless you avoid almost every language feature. Two particularly common ones:

* Accessing a missing property or method results with undefined. Hope you remember the exact method names and field names of all objects in your codebase!

* Using "str".match(regex) results with null if there are no matches.

> You can't avoid null and undefined

We are speaking about just null, not "null and undefined". Believe it or not, I simply do not use null in JS. Study the concept of "truthy and falsy" in JS.

> Accessing a missing property or method results with undefined. Hope you remember the exact method names and field names of all objects in your codebase!

I don't. I do however structure my code predictably, using consistent naming conventions and patterns. I hope you do realize JS existed for over 20 years before TS, and complex apps like gmaps and google docx were built entirely in JS.

> Using "str".match(regex) results with null if there are no matches.

const match = /bar/.exec("str");

if( match ){

  // am only interested in what happens if foo returns a *truthy* result.
 
  // The exact type of a falsy result is irrelevant, it either matches (truthy) or it doesn't (falsey)

}

> We are speaking about just null, not "null and undefined".

Maybe you are, but when people are talking about using TS just for the strict null checking, they typically refer to the (default-on) `strictNullChecks` config option, that is about both null and undefined.

My point is I never use null or worry about "strict null checking" or even what that is in the first place or even how it is configured.

Well, good for you, bit you can run into the exact same problems with undefined (which you do use), and TypeScript still helps with those in the exact same way.

Which is to say: whether you use null or undefined is not really relevant to the point that was being made...

Thank you. I use undefined very rarely, usually with a hacky looking: "typeof foo === 'undefined'". I'd still rather just type that though than having to setup up TS. Don't get me wrong, TS is great for the eco-system, for examples it powers the intellisense behind vscode which I use daily. I just do not need to use it directly, so good for me indeed.

Next time you get a "Cannot read property <x> of undefined" error at runtime, take a moment to trace why it happened, then read https://shinesolutions.com/2017/01/06/writing-safer-code-wit...

null and undefined are very different. Not sure how you leave null out of your code.

You never interact with database? You're not supposed to pass undefined as NULL value.

And a variable that is waiting to be defined is very different from a value that received null as a result.

Dealing all those mixed up as falsy is a bad design.

I've already mentioned this above, please look up falsy and truthy values in JS. Null, false, 0, undefined and "" can be treated pretty much the same in 99% of your JS code. JS is after-all still a dynamic language, and there is nothing stopping you from making use of its dynamic features.

> complex apps like gmaps and Google docs were written entirely in JS

I always assumed complex Google apps from that era were built with GWT, which would mean Java.

No, but they were written using the Closure Compiler type annotations. So closer to TS than plain JS.

Closure compiler was released in 2009, google maps in 2005. So no, you've got it all wrong. The only thing limiting you from using the full power of JS is your mindset. And Google maps is just one example, others include nodejs, electron, react, vue, svelte....

> We are speaking about just null, not "null and undefined". Believe it or not, I simply do not use null in JS. Study the concept of "truthy and falsy" in JS.

I'm anti-TS, but there is a meaningful difference between null and undefined. Most of the time it's enough to check for falsy values, but there are times when you will want a distinction between a missing value and a value of null.

https://i.stack.imgur.com/T9M2J.png

Do you have a concrete example of such a time?

Undefined represents the absence of information altogether. In JavaScript any key can be called on any object and if it doesn't exist it will return undefined. If you put a typo in the key name, you get undefined. If you've never set it, you get undefined.

Null, on the other hand, is not a lack of information. It's an absolute value just as much so as any number or string or array.

They're both falsey values, but so is the number zero. An item with a price of zero dollars is not the same as an item with an undefined price, nor is it the same as an item that explicitly has no price, i.e. null. You may not choose to model your data that way, but the terms are still meaningful, and your UI might have to change to reflect the different falsey values.

Most common case I could think of, would be in making a request from a server, using something like Apollo. `const [ data ] = useQuery(SomeQuery)` The data that comes from the server is undefined until you make the request, but null could be a valid response.

If you forget to do the check, you will get a falsy value. Hope you remember to do it every single time, and hope all your team members remember!

If a team member writes

  function extractEmail(text) {
    return x.match(/someregex/);
  }

and you call extractEmail(x), you might get a null value.

If you assume you can't get a null value, you might try to do further processing:

  let [name, host] = extractEmail(x).split('@')

and get a type error thrown. That is, if you're lucky.

In the more common situation, you will actually save that to a database and that database will happen to accept null values by default, and then all hell will break loose in another totally distant bit of the code that naively fetches a list of emails from the table, grouped by host name. And you will have to chase down the bit of code that inserted that null in.

This is approximately what development without types looks like. When this happens to you, I hope you remember the following bit of advice: It doesn't have to be this way :) Alternatively you can start doing paranoid validation everywhere. That works too, except the nice thing about a type system is that it can properly track whether you need to do that or not (see https://github.com/spion/branded-types for one TS technique on how to do that)

Reply on news.ycombinator.com