4 ms·

> 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 ce

> 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 https://news.ycombinator.com/item?id=23913294 [2] https://www.oreilly.com/library/view/javascript-the-good/9780596517748/ https://www.oreilly.com/library/view/javascript-the-good/978...

spion 6y ago
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.
- orange8 6y ago
  > 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) }
  - Vinnl 6y ago
    > 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.
    - orange8 6y ago
      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.
      - Vinnl 6y ago
        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...
        orange8 6y ago
        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.
      - spion 6y ago
        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-with-typescript-strict-null-checks-type-guards/ https://shinesolutions.com/2017/01/06/writing-safer-code-wit...
  - mekster 6y ago
    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.

spion 6y ago

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.

orange8 6y ago
> 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) }
- Vinnl 6y ago
  > 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.
  - orange8 6y ago
    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.
    - Vinnl 6y ago
      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...
      - orange8 6y ago
        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.
    - spion 6y ago
      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-with-typescript-strict-null-checks-type-guards/ https://shinesolutions.com/2017/01/06/writing-safer-code-wit...
- mekster 6y ago
  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.