DEV Community 👩‍💻👨‍💻

Discussion on: Fault tolerance on the web

Collapse
oenonono profile image
Junk

Except run time type checking isn't fault tolerant and will impact users, as this post clearly articulates. UI !== backend.

Collapse
chasm profile image
Charles F. Munat

I have no clue what you're talking about. Type checking, whether run-time or compile-time, only checks that types are correct. At compile-time, you fix the issues and run the compiler again, repeating until there are no type issues. This ensures that the compiled code has no type issues, but does not ensure that there will be no run-time issues or that the code is correct. That's what testing is for.

Run-time type checking checks for bad input. What my code does with this information is up to me. I could let it crash. I could silently ignore errors (which is essentially what browsers do, when possible). I could attempt to massage the input into the correct format. I could ask the user (note: machines are users, too) to change the input.

I'm not sure what planet you live on, but on mine, backend issues often impact users. I'd love to hear how your 500 errors don't impact the user. What's your secret?

But run-time type checking is simply another tool for the programmer to use to ensure that run-time errors DON'T impact the user any more than necessary. This is quite the opposite of what you suggest.

The fault-tolerance built into browsers is an attempt to mitigate the damage done by faulty code, and to provide for graceful degradation. But it does not eliminate those errors, it simply ensures that a small error isn't a show-stopper. It is still up to the programmer to write error-free code.

The way the article is written, as I've explained elsewhere, doesn't appear to me to account for the tendency of most readers to skim rather than read attentively, and further gives the impression on a skim that it is advocating for sloppy code, hence that JS is better than TS because TS is "too picky". I don't believe that was the author's intent, but I am fairly certain that for a significant number of readers, that that was the takeaway.

Thread Thread
jfbrennan profile image
Jordan Brennan Author • Edited on

The way this article is written?! Advocating for sloppy code?!
There is a big bold heading right in the middle of the article that says "Leverage JavaScript's tools when necessary" in order to "increase the strictness and ensure correctness of your code, including type checking" then a comprehensive list of all the things JavaScript provides to "harden your code". I've never seen anyone highlight and categorize these anti-slop language features this way. I should get a cookie for doing this!

Based on all of your comments, I'm convinced you didn't even skim and just went straight to the comment section after seeing the title...

Thread Thread
oenonono profile image
Junk

I'm not sure if this is pedantic of me, a misunderstanding of mine about the vocabulary, or maybe it's just a different way of thinking about what is (or could be) the same thing depending on how TC39 designed such a thing...

But type checking and input validation seem like very different things to me. One is about program verifiability and developer experience, which are improved by explicit contracts between different parts of the code. But the other is about users and user experience.

Is it a failure of imagination on my part? I know that programmers would love to treat human beings as part of a program that operates perfectly, but they're... human. And not that. So type errors don't seem like quite the right approach.