1. 17
  1.  

  2. 3

    I’m a majority JavaScript developer, so I may as well throw my 2¢ in here.

    TypeScript looks fine. But it’s still another layer. Another dependency. Another “oh they just bumped versions and it has breaking changes.” There are already SO MANY of those in JS because of the lack of a real common library. I understand the desire to have type safety, but I’ve written an incredible amount of large JS apps without type issues.

    The TypeScript fever reminds me of the CoffeeScript fever from a few years back. It was “just better” so everyone got on it (including myself). Then they started standardizing those things into ES6. That will end up happening with TypeScript, too.

    It’s not a huge deal to have a preprocessor transpiling your code every time you save, but it sure is better not having the extra config and dependencies when you don’t use a transpiler. That goes for ES6/Babel on the front end as well.

    Then again, I don’t think plain old vanilla JS is bad.

    1. 23

      Another “oh they just bumped versions and it has breaking changes.”

      I’ve been using TypeScript extensively at my day job for almost two years. In that time, TypeScript hasn’t made a single change that broke any existing code. The closest thing was when better type inference came along and caught type errors that it couldn’t catch before.

      I realize that doesn’t address all your concerns, but I think it’s worth emphasizing that the TypeScript language is developed with a sense of professionalism and caution that is all too rare in the JavaScript ecosystem.

      I understand the desire to have type safety, but I’ve written an incredible amount of large JS apps without type issues.

      I’m not sure what you mean by that. I find it hard to imagine that you’ve never shipped a runtime bug to production because you misspelled an object property, forgot a config value, called a non-existing function, or similar. I don’t think that’s what you mean. But I’m not sure what you actually do mean.

      1. 1

        In that time, TypeScript hasn’t made a single change that broke any existing code.

        https://github.com/Microsoft/TypeScript/wiki/Breaking-Changes#typescript-23

        Of course it has. Every library does.

        I find it hard to imagine that you’ve never shipped a runtime bug to production because you misspelled an object property, forgot a config value, called a non-existing function, or similar

        Bugs get through, but testing eliminates most of what you just said. My tests run every time I commit, so things like misspelled object properties or non-existent functions being called are not real issues I run into.

        My point is that type safety isn’t a cure-all. Just having it doesn’t make your app automatically bug-free. The fact that the Slack guys are saying they had multiple errors like that throughout their app makes me wonder what kind of testing they even use.

        I don’t see the benefit of TypeScript over vanilla JS in a production environment unless you only have something like Java devs who are trying to figure out JS.

        1. 20

          I’ve always considered static typing to be a kind of test you get for free (And less of a hassle to refactor)

          1. 13

            Of course it has. Every library does.

            Bah. I phrased that poorly. I meant to indicate that it never broke any of our code, except when it caught actual bugs that were already in production.

            Bugs get through, but testing eliminates most of what you just said. My tests run every time I commit, so things like misspelled object properties or non-existent functions being called are not real issues I run into.

            I have a similar setup, and additionally require 95%+ test coverage before a branch can be merged. Nevertheless, TypeScript consistently catches bugs that the (decent, but not brilliant) unit tests don’t.

            I don’t see the benefit of TypeScript over vanilla JS in a production environment unless you only have something like Java devs who are trying to figure out JS.

            Well, our team consists of three JavaScript specialists and a dozen backend developers with a variety of language backgrounds. Literally every developer on the team who has used TypeScript has found it superior in terms of productivity, safety, and pleasantness.

            YMMV, but that’s been our experience.

            1. 6

              I don’t see the benefit of TypeScript over vanilla JS in a production environment unless you only have something like Java devs who are trying to figure out JS.

              Plenty of people who’ve figured out JS still like typed programming – it’s not a matter of being ignorant.

              1. 1

                That’s not really what I’m getting at. I like typed programming in typed languages, just not where it’s another dependency on top.

          2. 4

            Then again, I don’t think plain old vanilla JS is bad.

            I was with you up until this point. Vanilla JS is terrible, but I’m not convinced that transpilers are the cure for the disease. I think TypeScript demonstrates some nice ideas that should migrate into core JS (and honestly, the biggest wins in TypeScript are in ES2015 as well), but the additional layers are a worthwhile concern.