1. 16
  1.  

  2. 40

    For reference, this is by Eric Elliott, whom I remember best as a passionate advocate against class syntax in ES6 and who instead advocated for dev teams to use a combination of bespoke factory functions, mixins, and traditional-at-the-time inheritance via dynamic prototype modification; for an example of his earlier writing on the ES6 class keyword, feel free to peruse this post, which also links to some of his other posts on the subject. I find myself disagreeing with pretty much all of his hand-wringing on any topic.

    To save you the click for this current TypeScript post, the bulk of his argument is a claim that TypeScript falls short of positive ROI because in his view:

    1. Static type safety provides a 0.1 out of 10 benefit.
    2. Writing out the types in your code is “syntax noise” that has a 3 out of 10 cost.

    There are some other questionable cost/benefit numbers he’s got down, but those numbers would swing his analysis in the opposite direction were they swapped (TypeScript would have 7 points of benefit vs 6.1 points of cost), and I’ve found that most engineers already have relatively set notions of these kinds of tradeoffs regardless of which side of the fence they’re on in terms of static vs dynamic typing. Your reaction to his blog post will likely mirror your reaction to those two points.

    FWIW, he backs up point #1 by linking to one of his own blog posts on the subject, which itself contains a dead link to a supposedly formal study that claims static types result in fewer bugs than dynamic types but the effects are quite small (he doesn’t say what “quite small” means or what that measurement is relative to), and a link to a fairly haphazard blog post that “analyzed” the benefit of static vs dynamic typing by looking at what percentage of issues were tagged as bugs on Github for different languages, controlling for no factors. In both this article and in other posts he’s written about TypeScript he claims that it doesn’t support higher-order functions or composition (???), and in a previous essay on his views on TypeScript he described discovering dynamic typing as:

    I come from a background using statically typed languages including C/C++ and Java. JavaScript’s dynamic types were hard to adjust to at first, but once I got used to them, it was like coming out of a long, dark tunnel and into the light.

    And, rereading his current post, he actually copied that expression verbatim into this post. Go figure.

    If your experience with JavaScript’s dynamic type system was like coming out of a long, dark tunnel and into the light, and if you view type safety as an almost-meaningless feature with high cost, I can see why TypeScript wouldn’t feel like a win: the whole point of TypeScript is to add static type checking to JavaScript. If your experience with the JS dynamic type system and with static typing in general differs, I imagine so too would your reactions to using TypeScript instead of JavaScript.

    Personally I like my arrays to stay arrays.

    1. 3

      And, rereading his current post, he actually copied that expression verbatim into this post.

      I wonder what that light would be? Converting compile time errors into run time errors doesn’t seem like one to me.

      Sure, you can do more with untyped languages, which is true by definition but I have yet to see a compelling thing possible with untyped languages that is impossible or very complicated in languages with a somewhat decent type system. Clojure was touting transducers, but even in Clojure I never saw them that useful.

    2. 23

      Take anything Eric Elliott said with a block of salt. He’s faked sources before.

      1. 11

        On the basis of this post I decided to read the paper he linked to in the article with the claim:

        TypeScript is only capable of addressing a theoretical maximum of 20% of “public bugs”, where public means that the bugs survived past the implementation phase and got committed to the public repository, according to Zheng Gao and Earl T. Barr from University College London, and Christian Bird from Microsoft Research.

        And… Wow. He completely misconstrued the findings, to the extent that I’d consider his source here faked as well; the underlying research instead showed that type annotations were able to catch 15% of public bug reports on GitHub, which the paper firmly states is an undercount of its value, since many bugs go unreported. There is no theoretical maximum mentioned at all (and honestly, how could there be? You’d need to make proofs about how actual users write code, which seems difficult to say the least) and the paper comes out strongly in favor of adding type annotations to reduce bugs.

      2. 7

        From my part, after using TypeScript for a small project, I realized that while it does have some benefits over plain ES6, the underlying semantics are still those of JavaScript and therefore the ROI is never going to be high. Which is why I turned to research ReasonML and ClojureScript as languages that compile to efficient JavaScriot but also bring different semantics to the table.

        1. 4

          This is always the problem with retrofitting type systems into untyped languages. While somewhat possible, it makes the type system very complicated, slow and complex. Implementing basic ML-style type checking is a simple task that already nets you a somewhat usable language. Whereas the effort for solutions like core.typed is way larger, requiring PhD students and in the case of TypeScript and Flow, multiple man-years.

          So I somewhat agree with the blog post but for completely different reasons. If I were to write JavaScript code these days I would probably compile it out of OCaml with js_of_ocaml. Or maybe PureScript.

          1. 2

            I can’t really argue for pros/cons of dynamic vs static types as I’ve never used a “proper” static type language “in anger”. My argument against using TypeScript is that it (by design) doesn’t try to address the biggest pains of JavaScript - equality semantics and a standard library.

            On the topic of Clojure, I know that the ClojureScript compiler does do some type inferencing to generate more efficient JS code (remove a bunch of guards etc), and also gives you some warnings if you try to add an int to a string, for example. I’m interested to see where that goes…

          2. 2

            I have found pretty much the same thing. I prefer writing plain JavaScript myself (but I’ve been doing it for a LONNNNNG time and have so much familiarity that it never bothers me anymore). I can understand why someone would switch to something like ClojureScript or ReasonML (or Haxe or…), but TypeScript doesn’t really offer that much back given the investment.

          3. 6

            I originally posted this aware that anti TypeScript opinions were unpopular. But I wasn’t aware quite how much people dislike Eric Elliot.

            It is a shame if Eric is misconstruing data to make an argument. But I think there are valid considerations in the article. Namely:

            • There is an overhead to using typescript. Such as additional complexity to debug and dealing with @types libraries that not up to date.
            • tooling exists that gives you much of the same developer experience in JavaScript
            • hiring experienced typescript developers is hard (especially if you’re in a market with a developer shortage already)

            I’ve enjoyed writing typescript in the past. But what I take from reading this is the reminder that a team should assess and be aware of the cost of implementing typescript.

            1. 4

              hiring experienced typescript developers is hard (especially if you’re in a market with a developer shortage already)

              This is a weird concept to me, I wouldn’t really look to explicitly hire for somebody ‘experienced with Typescript’. I mean, I wouldn’t even think about it. Sure there are certain things which are trickier to apply types to but those are honestly usually pretty rare. If you’re handling hiring like that, you’re going to create your own developer shortage.

              1. 2

                There is an overhead to using typescript. Such as additional complexity to debug and dealing with @types libraries that not up to date.

                The overhead is mostly in upfront setups costs, and these days it’s pretty minimal. It’s quite rare to find outdated type definitions - I think it’s happened once in the ~4 years I’ve been using TS. In terms of debugging, it’s (all-but) invisible these days.

                tooling exists that gives you much of the same developer experience in JavaScript

                Not in my experience. The tools can guess at what you mean when you try to refactor, but it really has nothing on what can be done using types. I’d hate to go through a web framework upgrade without the benefit of compilation errors.

                hiring experienced typescript developers is hard (especially if you’re in a market with a developer shortage already)

                Again, not in my experience. Hire a C# + JS dev and they’ll likely pick up typescript in a week and be highly productive in a month. TS itself doesn’t require any special knowledge and is easy to learn.

                1. 2

                  How can there be valid considerations in the article if he is falsifying evidence? How can we take it that they’re valid? Do we take it on trust? Doesn’t his actively presenting false evidence erode your trust in his argument? If not, why not?

                  1. 2

                    It is a shame if Eric is misconstruing data to make an argument. But I think there are valid considerations in the article.

                    This is one of those cases where I realize my value system might not be universal for people. For me, “misconstruing data but valid considerations” is incompatible: intentionally warping data is deeply wrong, and making up sources is unforgivable.

                    1. 1

                      Unfortunately. I think this is pretty much the root cause of the current replication crisis we’re seeing in many of the sciences.

                      1. 1

                        I was having a conversation about software choices. Not moral value systems. I agree with you to be clear. That’s why the 3 points I came up with were all based on subjective elements of the article and not part of the contensious data. The points I choose were also generally known frictions with adopting typescript.

                        While I appreciate and agree with your passion for ethical writing, it really was not the conversion I was originally trying to have. Clearly in the future I will think twice before citing an Eric Elliot article.

                    2. 6

                      My most meaningful experience with TypeScript has been to create a library for a server side API that I wrote a couple of years back(basically set and get some stuff over http). I know the type checker found a bug in the callbacks to the http request and fixing it made me correct the logic. If i had a test for that at that point it didn’t clarify how it was going wrong (again callbacks and http), but the types did. So, YMMV but a better type system definitely can be a good tool to get the job done.

                      1. 5

                        I’m not going to get into his character or his sources or anything like that. I’ll simply say that I’ve been in the same spot as him and I’ve found more or less the same results. I personally avoid TypeScript when possible because the investment in it is non-trivial and the return on that investment is negligible at best (again, in my experience).

                        1. 1

                          He doesn’t even understand how to limit “spec errors” with types. Clearly the only types he’s using is string and number.