DEV Community

Cover image for Fault tolerance on the web

Fault tolerance on the web

Jordan Brennan on July 20, 2021

Months ago I wrote The reasons I don't use Typescript and one reason more than others struck a nerve with some readers. I said developers "can embr...
Collapse
greenroommate profile image
Haris Secic

JS is both the best and the worst programming language for couple of reasons, one being fault tolerance that goes both ways. Now I dislike it's comparison but it's because of "fault tolerance" that it kind of sucks (pardon my french). "Null is false in an if statement but so is undefined yet they are not equal." And I really dislike making extra steps to avoid this madness yet I love writing code that works without bothering about too much details. It's an oxymoron language for my taste

Collapse
jfbrennan profile image
Jordan Brennan Author • Edited

Haha it is a bit of an oxymoron language. Never heard someone describe it that way, but that's accurate.

The null/undefined weirdness has become invisible to me because I know when I want the more forgiving default falsy logic and when I want nullish coalescing, which is made easier with the new ?? operator. I can't think of a time I needed to check specifically for null, but that's simply ===.

Collapse
greenroommate profile image
Haris Secic

I can sadly. Sometimes I had cases like var1 == var2 and wanted -1 to be equal to "-1" which worked until it didn't. Somehow you end up with null==undefined and then you do extra steps like setting undefined to null then comparing. Anyways it's because you relay too much on things being properly verified before then doing dumb stuff. So yeah I like it until I shoot myself in the foot then I complain on JS because I can hehe. Either way I agree JS is good enough for frontend just don't be lazy with input variable checks and corrections which I mostly am being mainly bacakend dev on JVM langs or C#.

Thread Thread
joelbonetr profile image
JoelBonetR • Edited
"Sometimes I had cases like var1 == var2 and wanted -1 to be equal to "-1""

Really????

(var1).toString() === var2;
// or
var1 === parseInt(var2);

if you don't know for any reason -ehem, bad coding- which kind of value you'll get you can do

(var1).toString() === (var2).toString();

For your second concern there are good definitions so you can understand how to handle them:

null is a primitive value that represents the intentional absence of any object value. If you see null (either assigned to a variable or returned by a function), then at that place should have been an object, but for some reason, an object wasn't created.

By the other hand, the undefined property indicates that a variable has not been assigned a value, or not declared at all.

JS is quite good for backend as well, giving an amazing development speed and simplification for APIs either be REST or GraphQL while giving a huge high i/o operations performance.
It's just for high CPU demanding operations where you add a python or java or C# or Go or Rust or C++ or... API.

Thread Thread
greenroommate profile image
Haris Secic • Edited

I know null and undefined difference. If you read the post you would understand lazynes in there and no JS is not that good for me for backend but regardless .toString() is bad as well. Given the example null == undefined so it will work but if you do -1 === "-1" it won't and neither will null === undefined. But what when you have if(-1) or if (null) but -1 is not == null??? Maybe you can't grasp the full aspect of the examples as you haven't been on "superfun projects" where these things start mixing up . You shouldn't do those things as you shouldn't do ==. That toString is also abused design flaw so yeah ehm bad coding. That is the point where it's both great and horrible. That's what I like about compiled languages, you can't have undefined. And the only way to get it in JS is to work on existing code and try to cut corners. When I write JS it's usually not possible to have undefined because I avoid global variables and mostly rely on functions that use only parameters. If I want to verify object properties I do mainly local variable with null and undefined handler putting it null again. Now JS is good for small projects but those "features" become bugs once the code grows and that's because given anything to people they will abuse it

Thread Thread
joelbonetr profile image
JoelBonetR

It can happen, of course but it happen with a thing or another on any language, at the end, bugs are -most of time- someone's fault and not language's.

The only way to keep bugless is using TDD from my POV -which is agnostic to any language- so you have no fear about your code and you can refactor whatever you need when you need it, if the tests are maintained, they will tell you if your code is ok or not.

I was working on JS for 3 years (also with JS for the backend) on big applications and I'm temporarily on a Java webApp... Which is plenty of bugs... in my entire life I never saw more bugs that what I see inside Java Apps like the current one and another where I worked at about banking App... and it's a strong typed and compiled language :-V

Thread Thread
greenroommate profile image
Haris Secic • Edited

You were off topic and are right now. Point is fault-tolerance. == Is fault tolerant. Not knowing actual variable type is fault tolerant. Your examples have nothing to do with it. And since you mentioned time spent I have 10 years in JS and other languages. I've built my own frameworks when there was no Angular react or so. I've used Node.js as well. It's horrible for me. So I have much deeper knowledge about JS and what I'm talking about as well as about fault tolerance and comparing it to other languages than you might think. It's not a mistake to not know about variable type and that's the whole point of ==. Spending less time about details and more about the end goal until it breaks. Then you add more checks and such. TDD has nothing to do with fault tolerance or testing. It's a way to create architecture and again missued and misunderstood by many as a way od testing. JS is great until it's not and that's about it. There's a reason why we have a choice of languages. Elixir is fault tolerant yet a bit more reliable than JS when it comes to these things

Thread Thread
joelbonetr profile image
JoelBonetR

if you got a syntax error the Js app will break, if you expect a string and you get an integer it will probably break as well. Fault tolerance means that if something fails, the app keep running. To ensure fault tolerance you need to catch the errors -when possible-

Fault tolerance in the web is on HTML and CSS only and I can agree with some JS things that could be better, but telling that there are bugs due to the language? We've the same years of experience, do you really thing that when bugs appear is the language's fault? C'mon!

I know what TDD is and even if TDD or not, if there are tests and the tests are well written (not only for the use-case you are working currently) then poof the major part of the bugs disappear.
There's no discussion on the importance of tests on software development but we all worked/are working on companies that want us to develop features in 5 minutes and then, the first thing that is left apart is the Documentation, the second one are the Tests, does this sound familiar to you?

The main reason for "Spending less time about details and more about the end goal until it breaks." is usually this one I described you and I worked on companies that handled projects like this and others where the projects were well driven so I can ensure that the issue -if any- is not the language itself or a given tool or framework, is the lack of time, the pressure and so on.

At the end, having the option to use == instead === is good and can help on many situations, but if you are using == always is your fault.

Collapse
samuelfaure profile image
Samuel FAURE

I really like Typescript, and I can't even think of going back to weak typed JS, but I also really like your opinion.

Even if you were arguing badly (and you're not, you make convincing points) it is refreshing to see people go against trends. We need more dissonant voices.

Collapse
oenonono profile image
Junk

I agree with both of you. But also it sounds pretty darn weird that saying something that was (a) well understood by web devs in the web standards evangelism era and (b) explicitly a design goal of the stack of fundamental technologies of the web relies on is now, "a dissonant voice... against the trends." Weird because it's accurate.

Collapse
jfbrennan profile image
Jordan Brennan Author • Edited

Standards. So edgy!

Collapse
chasm profile image
Charles F. Munat

There seems to be some confusion here. TypeScript is used by many developers to provide compile-time static type checking. It also allows IDEs to provide helpful hints. It has nothing to do with run-time type checking.

Frankly, that's a sad limitation and I wish that ECMA would hurry up and add an optional Hindley-Milner type system with inferencing to JavaScript, maybe using a special comment style so that it is backwards compatible ("fault tolerant", as you call it). That's long past due.

Then we could eat our cake and have it, too.

Collapse
jfbrennan profile image
Jordan Brennan Author

No confusion here either. The second half of the article is me sharing the ~20 features of JavaScript that "help you further harden your code at runtime" and then I finished by briefly mentioning how even if you use TS and leverage these native features it's still not enough because there are many situations that demand further validation, and then I linked to a good article that talks about that in more detail.

I don't know what a Hindley-Milner type system is, but I'm all for using anything that becomes real JavaScript 👍

Collapse
chasm profile image
Charles F. Munat

I don't think you got that across very well, but maybe I'm just too used to seeing articles bashing TypeScript (or bashing anyone who doesn't see it as the best thing since sex).

Allow.js is interesting. I have essentially written the same thing and use it in my apps. One would be crazy not to. That said, I think the benefits are far outweighed by adding yet another dependency and this from something used by 17 people, written four months ago, and apparently unsupported. It would be smarter just to copy the code and refactor it to suit one's own purposes. It's one small file, after all.

But even the article you link to comes across as very anti-TS, despite the requisite "I don't hate TS". If you have to say that, then you probably do.

Personally, I am not a fan of TS and have griped about it for years. It's an M$ product, hence controlled by a big corporation, and one not known for its fairness and philanthropy. It is sadly very OOP-oriented. I don't want or need that baggage.

(The article to which you linked complains about interfaces. I never use them. They are just mutable types. But I'm not writing classes, so...).

I don't often agree with Eric Elliot, but he is right about the TypeScript Tax. I figure it adds about 30% to my dev time, and I'm not sure I get that back at the other end.

BUT, TC-39 is slower than [insert cliché here] and so TS has become a sort of de facto standard. Even Deno is based on it (though Dahl may have some regrets). Every contract I find requires me to use it. Its ascendance is essentially a fait accompli. Sorry.

So I think that it would be better to write essays that explain when to use it and when to avoid it and how to write it most effectively. Hell, I'd read them. And to put some pressure on TC-39 to do the right thing.

Hindley-Milner is the type system used in Haskell. en.wikipedia.org/wiki/Hindley%E2%8... It is a nominal type system (en.wikipedia.org/wiki/Nominal_type...) whereas TS is structural.

Thread Thread
mattferrin profile image
Matthew Ferrin

ReScript as it's now called is better looking than TypeScript (PureScript loses a bit through it's undesirably novel syntax), but I feel that TypeScript supports much of what Haskell does. Placing as const at the end of a variable declaration allows immutability (something very helpful for static configuration). Tagged unions allow most of what algebraic data types do. Switch statement are a little like pattern matching, though I suppose that's what is most missing. (Fancier compile time checks that approach proofs and compile-time TDD aren't popular enough for me to have developed the skills to use them, but those are very much missing.)

About TypeScript you've said "I don't want or need that baggage" and I guess I'm just curious where you'd look the most for what TypeScript does well? Would you prefer something else over ReScript as an alternative or have complaints about it?

Thread Thread
chasm profile image
Charles F. Munat

I'm not a fan of React (it is a bit old in the tooth), so ReScript doesn't really interest me. And decorators. Ugh.

I prefer a simple functional approach to coding. I spent years as an OO programmer, never really happy with it, before I discovered FP in 2007 with Scala. Soon, Scala wasn't FP enough for me.

One of the reasons I became a FE dev is because JS is reasonably functional. Yes, I'd like it to be more so.

"Experts" keep telling me that an FP-OO hybrid is the "best of both worlds", but I really have yet to be persuaded that there is any need for OO at all.

So that perspective influences my views on TypeScript, ReScript, etc. I would like to see JS -- not really an OO language in the way most people mean it despite the "class" sugar trying to make it look like one -- move further to the FP side. Built-in immutability, HM types, pattern matching, etc. But nobody cares what I think.

What I am waiting for (probably pointlessly) is for JS to have an optional nominal type system with inferencing a la Hindley-Milner, and with higher-kinded types. One doesn't have to use all that, but if it's there then the sky is the limit. To me, TS, RS, etc. are all hacks trying to bridge the gap until such a system becomes available.

Meanwhile, TS is all the rage and pretty much inescapable at this point (if you work in enterprise, as I do). I'm not really very good at it. I'm particularly unhappy with the tooling and so many utterly useless error messages and so many libraries and frameworks not documenting where the hell the types are. But it is what it is.

PureScript is pretty awesome, I think, but who's using it? And there was something about it that turned me off, but can't remember what it was now. Hmm.

Thread Thread
mattferrin profile image
Matthew Ferrin

ReScript is OCaml disguised to look like TypeScript more. It is a Hindley-Milner language.

Thread Thread
chasm profile image
Charles F. Munat

Yep. And the O in OCaml is for Object, as in OOP. Another (maybe the first?) hybrid language.

ReScript: from the M$ pan to the F**k fire...

App development, like life, is a series of uncomfortable compromises. The pace of change is exhausting. I am trying hard to avoid learning new things -- am a big fan of Occam's Razor. Lately, I'm wondering if it wouldn't be better, what with all the improvements to browsers, to go back to pure HTML, CSS, and vanilla JS...

Thread Thread
mattferrin profile image
Matthew Ferrin

I conceptually admire F* language, which enjoys the support of Microsoft Research. Refinement Types seem nice, but I have limited time to chase skills the larger community is oblivious to.

In my opinion OCaml and F# emphasize functional programming. I don't think Standard ML dialects use OOP for anything other than inter-op with larger OO ecosystems. It's not their fault those ecosystems are larger and I think it's merely a matter of practicality.

Mathematically speaking, Haskell and SML dialects are more responsible language designs than vanilla JS, but I understand what you are saying.

Thread Thread
chasm profile image
Charles F. Munat

Agreed, re Haskell, SML... but they don't work in the browser, sadly. I liked what I saw of F#, but like you, I can't spare the time to learn whole languages, frameworks, ecosystems that aren't -- for me -- financially rewarding. It's not even possible, currently, to get far from React.

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

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.

Collapse
joelbonetr profile image
JoelBonetR • Edited

TS is no longer what it was at the beginning.

When TS was first introduced In 2012 it had sense because it bring features like classes, still not available in JS, so it solved a real industry need.

But JS had come a long way since then and now TS is struggling to keep up. Is opinionated and bring packages or functionalities like it or not while nowadays (and since long time ago) if there's anything than you feel missing or you don't want to lose time coding it, there's a babel plugin to do it.

Something that pisses me off is how TS is defined as a "Superset" of JS.
TypeScript is a Subset of JS. Is something that compiles into JavaScript, it cannot be a superset by definition. This means it can't do a single thing that is outside of the JS boundaries while it enforces you to code on a strict way. It limits what you can do with JavaScript and obscures it's strong sides while providing a fake peace of mind.

An unneeded feature for JS is static typing by default (you can enforce it with vanilla JS) and TS does it at compile (transpile, currently) time, which breaks a strong point on interpreted languages that is fast development and no compile waits.

Moreover TS will only check types at compile time and only types that are available. Any network calls, system libraries, platform-specific APIs and non-typed third-party libraries have no way of communicating with TypeScript.
As you get used to having your types checked and not having to fully understand the code and the platform, errors and bugs will manifest themselves.

The conclusion is that if you are so bad dev that you need strong typing to avoid committing errors yourself, you may either learn from those errors or work on another career path -you will probably like java -.

Imagine how bad would be the rest of the software (specially the validations) to reach the point where you get a type error and imagine how bad would be the methodology -and lack of testing- of that project to bring this kind of errors into production.

My advice from my experience as a senior dev and tech lead is to avoid TS and enforce good methodologies such TDD and having a good tech documentation, you'll live happier and without fear of your own code while keeping all the power of JS.

Collapse
ecyrbe profile image
ecyrbe • Edited

What bold assumptions. A tool is a tool and it always fullfill a purpose.
You achieved to tell your peers that if they use typescript or even like using it, or let bugs sleep through, they are bad developers ? really?
Professional environnement ? Catch bugs early ? Keep your maintenance cost low ? Catch a phrase?

Talking about tdd vs typesystem when one is about runtime checks vs build time checks... Maybe i should throw my linter away, there's ttd!
Obviously, a type system is here for a purpose and it's indeniable success means it's usefull to some. Maybe only to those who realise they prefer climbing a building with a security belt? If that means they are bad climbers in your eyes, at least they are still alive. Meaning their project will still be maintainable and evolve 5 years from now.

Collapse
joelbonetr profile image
JoelBonetR

As long as you can check types whenever you like or need with JS and the only feature that "survived" JS evolution from TypeScript is strong typing, why would you like to have this throwbacks?

It limits what you can do with JavaScript and obscures it's strong sides while providing a fake peace of mind.
Any network calls, system libraries, platform-specific APIs and non-typed third-party libraries have no way of communicating with TypeScript

You are confusing having a security belt with always needing this security belt.
Do you need a security belt to walk through the streets from your home to the supermarket? Do you need a security belt to go from your kitchen to your bathroom?

Whenever you need it you can check it is here with typeOf.

I can understand many people that like TS is because they come from Java or C# and it looks more like what they learned, and that is difficult at the beginning to code into JS which has some things to take care of such Async, load orders, etc -depending on the project or implementation- , also being a multi-paradigm language does not help newbies.

Using JS as OO language only and with strong types using TS is most of time a lack of previous analysis of what is the best architecture, paradigm or design you can apply to your solution.

You can simply take a try and develop the same with and without TS, the result would be that in JS you end up with better third-party compatibility, ensuring your app process and in less time -that's the results from 3 iterations we did in the past to take a decision about using TS or not on a much bigger project-

I bet you feel a bit offended with my conclusion, it's not some kind of insult, it's a push for you to make some kind of deep analysis and empiric test to see if it's really a must or it's only some kind of unneeded sugar.

There's no real concern about types if you can discern whether those type checks are strictly needed.

At the end... what will you say of a man who walks it's 5 Kg dog on a flat walk-through thrice a day while wearing a security belt?

Collapse
monfernape profile image
Usman Khalil

Very valuable content. I really liked the term 'fault tolerance'. Many of the methods you mentioned prove quite effective dealing with data types.

I hope this reaches more people cause it deserves

Collapse
stojakovic99 profile image
Nikola Stojaković

How is having typeof checks all over your code base quite effective?

Collapse
jfbrennan profile image
Jordan Brennan Author

More effective than any ;)

But seriously, the point is there are like 20 of these tools at your disposal. We should be making the most of those, even if the project is in TS.
I mean, who doesn't see the power of Optional Chaining? It's like the greatest tradeoff in language history: write more ? and you practically eliminate TypeError: Cannot read property forever! It's widely supported, including Node, for more than a year!

Thread Thread
stojakovic99 profile image
Nikola Stojaković • Edited

Um, if you're going to use any there is no much point in using TS at all :D

I explicitly disable usage of the any whenever I'm working on the TS projects. It makes sense to use typeof in some places, but it's not a substitute for a type check by TSC nor static code analyzers (like Hegel).

Collapse
monfernape profile image
Usman Khalil

It doesn't and that isn't even the point of the post in my opinion. I'm big fan of typescript myself and I really liked the writing and his opinion.

Collapse
raghavmisra profile image
Raghav Misra

I liked this a lot and your analogies were quite on point lol. Fault tolerance does go both ways, but that isn't a reason to not have it. A lot of the examples against it, such as the null/undefined discrepancy that is prevalent in these comments, can be mitigated using testing, and other programs at the build step. For example, running a linter on the banana: split CSS example won't prevent your code from running when it's live to users, but you'll be able to catch it yourself in the development process.

Collapse
chasm profile image
Charles F. Munat • Edited

Also, I think you confuse sloppy with "fault tolerant". JavaScript is not fault tolerant. Neither, really, is CSS or HTML. Browsers and other user agents are fault tolerant... sometimes.

That fault tolerance is a good thing. NOT an excuse for writing shitty code.

We don't want user agents that enforce strict rules. That's the benefit of TypeScript: it works at compile time to enforce strict rules, helping us to write better code.

Yes, it is an enormous PITA, though it is slowly improving. And libraries and frameworks really need to up the quality of their documentation (well, that's always a thing). I shouldn't have to spend hours trying to figure out where a type is defined.

Collapse
jfbrennan profile image
Jordan Brennan Author • Edited

Nope, not confused (not about this subject anyways!). Perhaps you were reading too fast and didn't see this:

Does this mean we should omit tags or not bother closing tags or write nonsense? Of course not.

Or this (bold added):

Again, the point is not that the web platform tolerates sloppiness, but rather should something imperfect or unsupported slip through your quality controls, it won't completely ruin your users' experience.

Or this:

conscientiously allowing a little wiggle room

And yes, the HTML, CSS, and JavaScript (okay, "ECMAScript") languages are in fact designed with varying degrees of fault tolerance. It is very much these language specs and not the browsers that set the rules and I cited one example from the HTML spec just to drive this point home. Browsers only implement those specs.

Collapse
chasm profile image
Charles F. Munat

HTML does, yes. But other than duck typing and mostly unfortunate silent casting, I haven't seen much to indicate that JS is "fault tolerant". I would suggest that "fault making" is more accurate.

But again, I am not as concerned with what you say as how you come across. That you felt the need to put such qualifiers in your article indicates to me that you were well aware of how many (maybe most) people would perceive the article. Frankly, most people don't read, they scan, as I did.

So perhaps you're not so much confused as confusing. What really are you trying to accomplish with all this? What should the takeaway be for the reader, and why not just put that very clearly at the start of the article, so there's less confusion? If the fault tolerance is built in to the browsers and the languages, as you say, then what's left for the dev to do? I don't really see, despite your disclaimers, how this can be anything other than a call to sloppy programming.

Thread Thread
jfbrennan profile image
Jordan Brennan Author

I'm sorry if you found my writing confusing, but you did just say you only scanned through it. The answers to all of those questions are stated or implied if you want to give it a second read.

Thread Thread
chasm profile image
Charles F. Munat

I didn't find it confusing. My point is: readers don't read, they scan. If I got the wrong impression from a scan -- and I believe you when you say I did -- then my guess is that many if not most of your readers did, too. That seems counter to your intent.

But don't take my word for it. Ask other people to scan your essay and then tell you what they got from it. If they got your message, then great. My bad. But what if they didn't?

Rhetorical question. We've beat this to death, I think.

Collapse
stojakovic99 profile image
Nikola Stojaković • Edited

I'm all for the fault tolerance but not the one on the web.

Web is built on very fragile technologies. HTML is basically a broken XML. Making errors while writing CSS will bring you to hours spent debugging and banging your head against the wall. Same with JS.

You want a proper example of fault tolerance? Look at BEAM and Erlang (or any other BEAM based language). There should be a proper fault tolerance and an information available for a developer to find and fix an issue.

Collapse
jessekphillips profile image
Jesse Phillips

You do want you airplane tolerate of failure. However it would be another thing to say that you want your testing to be tolerate of failure.

"The plane blew up, but I am still talking to you so let's ship it."

Yes build the software that is tolerant to fault, but by using tools to build the software that itself is tolerate of your failure is just asking for trouble.

Clearly no language will stop you from writing incorrect logic and that can usually be a bigger problem. I just don't know why you'd choose to make the task harder.

The "native" tools you mentioned are all runtime, they can be used to create fault tolerance, but that actually creates a new layer for test coverage. Compile time checks eliminate additional testing because it is built into the language.

Collapse
jfbrennan profile image
Jordan Brennan Author

it would be another thing to say that you want your testing to be tolerate of failure

It sure would. I think there's been a misunderstanding because no one here suggested such a thing.

Collapse
jessekphillips profile image
Jesse Phillips

That is my point, those of us who support static type checking, view it as a test that we have coded to expectations.

Now Typescript isn't the greatest here as it still lives with dynamic world. And our expectations are certainly aren't always correct.

The other way in which fault tolerance has been stated is, be liberal with what you accept and strict with what you output.

You discuss one side as evidence the other should be the same. Browsers allow malformed tags because that is their input, you'll notice the rendered page puts in all of the closing tags for you.

On the other side, the browser input is your output. You said correctly that you don't want to deliberately leave out tags, but when we are discussing language I think that is not the greatest example.

I'd say the biggest challenge with typing is there are way no get around it. Trying to add a string and a number, simply ask to convert the string to a number. This does not add any additional safety over javascript. To code this for fault tolerance, one would need to handle failure in conversion, this is where static typing comes in, you are now informed of a potential failure and can take action to improve fault tolerance, Javascript unfortunately does not give you this opportunity.

Thread Thread
jfbrennan profile image
Jordan Brennan Author

"be liberal with what you accept and strict with what you output" I like that, thanks for sharing

Collapse
momander profile image
Martin Omander • Edited

Excellent article!

A good friend once said to me: "strict data types are great at solving the problems introduced by strictly typed programming languages".
I came from strictly typed languages and really disliked Javascript at first. But after a year or two I got the philosophy of the language. Nowadays I often find myself writing shorter and clearer code by using Javascript's loose typing, than I used to do in Java and C#.
Having said that, this is personal preference and developers should use the technology they are most productive with.

Collapse
w3nl profile image
Pieter Epeüs Wigboldus

I think also that TypeScript isnt always the best choise.
For node.js applications i also use: npmjs.com/package/@hckrnews/objects (and that use npmjs.com/package/@hckrnews/validator)

It can reduce a lot of manual type checking, and clean code, and readable schemas for the models.
There are a lot of people indeed that you have to use TypeScript for type checking, but there are another ways to check your types indeed.

Collapse
mattferrin profile image
Matthew Ferrin

Your argument against TypeScript is that you should do what TypeScript is designed to detect you didn't actually do?

Collapse
jfbrennan profile image
Jordan Brennan Author • Edited

Not arguing against TS in this article. Toward the end I said

Whether you're writing TypeScript or not, those 15 tools [that are part of JavaScript] should be used often, but in the end it still won't be enough.

And then I briefly explained the occasional need for even further validation and linked to another article that explains why.

The way you phrased your question got me thinking though. TypeScript detects what you didn't do and yet for the sake of runtime safety you must know to still do all these additional things with JavaScript. So TypeScript is that annoying boss who tells you you need to do the obvious tasks (the ones he knows about), but is unaware of nuances regarding the necessity of those tasks, so you give him a ts-ignore or an unknown or any and he's also ignorant of the additional tasks that matter most. Uh, thanks TS for...helping. Yeah.

Collapse
mattferrin profile image
Matthew Ferrin

I and my teammates successfully maintain a project without ts-ignore or any. Type unknown is a tool that helps enforce typing.

When I help to maintain a TypeScript code-base the compiler automates much of my coding experience. By specifying a return type on an event handler, I am walked through each line of code and nearly prove that the loading indicator is dismissed. (Exceptions in promises are a ***** so you still need a catch.) The work is quicker, easier, and safer. (A similar technique can be used to ensure Node handlers exit with a response code.)

Over and over, the work is mostly done by a tiny edit to the type system and mindless error resolution. It doesn't just help, it literally does most my job for me. The rest of my job is done by unit tests. And more of my job would be done by the compiler if dependent types and refinement types were popular and people stopped acting like they were superior to automated mathematical checks at compile time.

Thread Thread
chasm profile image
Charles F. Munat

This sounds very similar to the way I work, except I need to learn a lot more about TypeScript.