By all accounts, TypeScript has been a big success for Microsoft. I've seen loads of people sparkle with joy from dousing JavaScript with explicit types that can be checked by a compiler. But I've never been a fan. Not after giving it five minutes, not after giving it five years. So it's with great pleasure that I can announce we're dr...

By all accounts, TypeScript has been a big success for Microsoft. I’ve seen loads of people sparkle with joy from dousing JavaScript with explicit types that can be checked by a compiler. But I’ve never been a fan. Not after giving it five minutes, not after giving it five years. So it’s with great pleasure that I can announce we’re dropping TypeScript from the next big release of Turbo 8.

  • @[email protected]
    14•1 year ago

    Honestly, having used both extensively at different points for years I can say that I understand his approach for smaller projects, but Typescript coupled with coding standards, makes working with large teams and large code bases 1000x better. Being able to immediately know what data is being passed where at a glance is invaluable.

  • @asdfasdfasdf
    14•1 year ago

    My thoughts on this are:

    1. Static typing is objectively better for any non-trivial project / script. I don’t have any idea why anyone who has any degree of experience with this doesn’t understand it.
    2. TypeScript does suck, and I almost understand moving away to JS. JS is like a friend with benefits; it makes no promises, and there are no false hopes between you. Well designed statically types languages like Rust are like marriage; you trust it, and respect it a lot for that. It’s more complex but in a way that gives you confidence. TypeScript, on the other hand, makes promises but lies to you. It also makes you do shitty things to uphold those promises. In a way, that’s worse than making none at all.
    • noughtnaut
      4•1 year ago

      I appreciate the imagery you bring here, but I’m quite interested in concrete examples of how TS “makes promises but lies”. Don’t shoot me (just yet), I’m not a TS developer, just a curious person wanting to become wiser.

      • magic_lobster_party
        3•1 year ago

        Not OP, but my experience with TS is that the promises of type safety only works if all you’re doing is to interact with other TS code. As soon you need to interact with vanilla JS, which is often, all the type safety guarantees you were promised goes through the window.

        So it’s some kind of weird hybrid. I prefer statically typed languages myself, but TS is not really it. It’s nice when it works though.

      • @asdfasdfasdf
        3•1 year ago

        Sure! Here’s an example: https://www.youtube.com/watch?v=u1WmiqlrqL0

        IMO one of the most fundamental, important aspects of type systems is the invariants defined in your model; if I say a field is an array, that needs to be the source of truth and enforced throughout the program. That’s the whole point. Same with if something is immutable or other aspects of the type.

    • v_krishnaEnglish
      5•1 year ago

      There’s likely a lot of reasons one wouldn’t want to work with DHH. It’s unfortunate because he is clearly really brilliant but seemingly fails to realize that a huge amount of software engineering involves working together with other people, many of whom aren’t that brilliant.

  • @[email protected]English
    5•1 year ago

    Fuck DHH. Fuck his shitty racist blog posts that he inter mixes with inflammatory bullshit that he does to the rails community.

    Rails needs him gone desperately

  • ShustOne
    5•1 year ago

    I think the best take on this is from Rich Harris at Svelte. They are dropping it for internal Dev because they get the same feature set from JSDoc and have no build step, but they keep it for Svelte users who want TS.

      • ShustOne
        1•1 year ago

        True but ideally a PR should be loaded on your machine for proper review. Otherwise you are just blindly trusting the written types anyway and don’t know if it’s correct.