To type or not to type: quantifying detectable bugs in JavaScript

As we have recently adopted TypeScript, this is a nice affirmation, but preventing bugs is only part of the benefit and I&#x27;m not sure it&#x27;s the most important part.<p>TypeScript, in conjunction with a code editor that supports it, significantly improves the code editing experience. Sometimes I still have to chase down documentation, examples, etc. to figure out how to use something, but it happens far less often. In general, I feel like I can code faster and with more confidence.<p>I assume all this is also true of Flow, though I&#x27;ve never used it.

My team is in the process of switching a React app to TypeScript and an interesting issue popped up just today.<p>I was refactoring some component to be able to implement a new feature. At some point of the process I managed to break the component so that it would not render, only complained about an object not being a proper React component and that I was probably trying to render a bunch of items that should be put in an array. The error was reported by something deep inside React so I couldn&#x27;t tell from the stack trace where the issue was. After trying to find the problematic bit by trial and error (lots of undo&#x2F;redo there) I finally decided to just move the whole file to TypeScript. 20 minutes later I was done and the error was gone. I don&#x27;t even know what I did to fix it but obviously I had to change quite a few things here and there to get the file to compile cleanly with decent typing and one of those type errors must have been the key.

Type systems aren&#x27;t just about adding static type annotations to your otherwise dynamically typed code to catch a few bugs.<p>If you embrace the type system and start modeling your domain types with the natural invariants in mind you start seeing the real benefit. Once you enforce the invariants of your data in the types you&#x27;ll notice entire categories of bugs will impossible to introduce. Abstraction barriers between different parts of your codebase will become more clear and impossible to break. Otherwise complicated architectures will become easy to express.<p>Types change everything.

It&#x27;s great to see the wealth of data we have thanks to open-source being used for such studies, and we should have more. More concretely, I can see why actual benefit could be either greater or smaller than the reported result:<p><i>Greater</i>: One of the advantages of types is that they impose a certain discipline and organization on the code. This global quality may have a significant impact that isn&#x27;t measured in this study, which focuses on a very local effect, and so the actual effect may be significantly greater.<p><i>Smaller</i>: Not all bugs are created equal, and there&#x27;s actually a huge variability in both the effort bugs require to fix and in their impact on total product quality. If the 15% reduction is mostly in &quot;cheap&quot; bugs, then the actual effect may be significantly smaller.<p>We should try to create a taxonomy of bugs, classified by kind, domain, project size, cost to fix and impact. This would help us get a better picture of the overall effect of various techniques.

This premise of many bugs being &quot;type errors&quot; is overblown and certainly very recent, for i&#x27;ve never heard such a claim on the internet until only recently (1 or two years ago). And the world was using dynamic languages for decades on the internet (old ASP, old Actionscript, old JS, PHP4 anyone?)<p>If the 15% of your bugs are simple <i>type</i> errors, then I&#x27;d suspect the quality and experience of your development team.<p>The big white elephant in the room that javascript users don&#x27;t want to acknowledge.<p>Mind you, static type checks are nice stuff, but to claim that 15% of bugs are type bugs, is another thing altogether.<p>I speak from experience, having managed development teams for years. Junior coders need (and deserve) to be <i>trained</i> first doing stuff without hurry to allow for mistake, not used immediately or thrown into critical (or rushed) projects.

The next 5% of bugs can be taken care of by a handful of goodl tslint rules.<p>- missing awaits<p>- using &#x27;this&#x27; in the wrong context<p>- shadowing variables<p>Those errors make for valid code that&#x27;s wrong in many cases.

And it prevents 100% of the time wasted on testing something in a browser (or generally at runtime) only for it to fail for some trivial type mismatch.<p>These things don&#x27;t typically make it as bugs into production code but are a big time sink with dynamic languages.

As someone whose background is mostly in statically typed languages, who has been using Ruby and Rails for the past year, the biggest issue for me is when refactoring&#x2F;making big changes to central parts of the app, the many repercussions of these changes often take a long time to track down, and subtle bugs are often introduced. By comparison, similar changes in a statically typed language are are usually much less scary, and less prone to having subtle breakage going unnoticed. A big test suite helps, but it&#x27;s not a replacement for all the help a static type system will give you.

I feel like I&#x27;m on a completely different wavelength with those who offer up &quot;full test coverage&quot; as a desirable alternative to a type system&#x27;s assistance. Or a desirable situation period.<p>I&#x27;m all for tests as a tool, but not full coverage as its own goal. One of my favorite tools is Visual Studio Code. As far as I can determine from the github repo it is very far away from the full coverage end of the spectrum. And yet, it works pretty darn good. Maybe I just haven&#x27;t found the unit test hoard, but it appears they have taken a more strategic, moderate approach.

I&#x27;m a big TypeScript fan but at times it just doesn&#x27;t work &amp; needs to be ignored. Like all things, you get to a point when you know what rules are okay to ignore. You can&#x27;t do default props in React very nicely for example. Functional programming like pipes can also be a pain.<p>That said, TypeScript (and Flow) offers other huge benefits than the 15% of bugs mentioned.<p>* Improved documentation<p>* Better code hinting in the editor &amp; better editor experience<p>* Teaches better JavaScript &amp; prevents browser bugs. Some browsers are very forgiving when you incorrectly use JavaScript with DOM elements. Others are not.<p>Types slow down beginners a lot but that&#x27;s a good thing. When learning a new language, a type system can act like a pair programmer or a teacher helping guide you in learning the types of the language. Each type has things you can &amp; cannot do. People who learned JavaScript using JQuery &amp; then try to type JavaScript without JQuery run into many of these issues. After using types for a while, the time investment is very minimal especially compared with having to come back &amp; find the error later.

I actually use Typescript to speed up development. Having the type-system looking over your shoulder is great for reducing the code-test cycle.

The TC39 has to step up their game and introduce static typing to JavaScript.<p>I don&#x27;t buy the bugs argument, but I firmly believe it would make the development experience considerably better. Not only because of tooling, but specially because code would be more way more expressive.<p>Also in my almost 20 or so years writing Javascript and other dynamic languages I&#x27;ve never once changed the type of a variable. Changing a var from string to int or object is just wrong.

The author over looked flow-typed which I believe is an analog of DefinitelyTyped.

This seems sorta silly. Better tooling prevents more bugs. That is the Crux of the claim. Yes. It should.<p>Better static analysis is almost certainly going to prevent bugs. Type checking is the fashionable static analysis nowdays.<p>My bed with it is that it requires rewriting. Which, itself, will introduce bugs. Or just be expensive. Using other tools are likely to give similar benefits. With the side benefit of keeping the working code you have.

I feel there should be a counter-article along the lines of &quot;Unit testing and static code analysis conservatively prevent 80% of the bugs&quot;. I&#x27;ve used both Flow and Typescript and imho they&#x27;re both frequently more trouble than they&#x27;re worth. They catch the simplest of newbie bugs that are rare in modular, linted, unit-tested codebases. There are static code analyzers (eg. tern.js) that provide hinting without requiring a transpiler. With Flow and Typescript you have transpiler overhead, but when it comes to places you might need them the most - checking and sanitizing data interchange that&#x27;s so common in modular, service-oriented architecture - they fall flat. Flow or Typescript could have been more useful if the annotations truly were <i>annotations</i> in the form of comments, unfortunately they went the transpiler way.

My vision of it is Flow and TS and stuff prevent 15% of bugs that the beginner and intermediate level developers typically make, but engineers on the advanced and higher levels avoid these bugs by just writing a good code in any language they use.