Skip Navigation

How do you feel about TypeScript?

Specifically, do you worry that Microsoft is going to eventually do the Microsoft thing and horribly fuck it up for everyone? I've really grown to appreciate the language itself, but I'm wary of it getting too ingrained at work only to have the rug pulled out from under us when it's become hard to back out.

Edit: not really "pulling the rug", but, you know, doing the Microsoft classic.

67 comments
  • do you worry that Microsoft is going to eventually do the Microsoft thing and horribly fuck it up for everyone?

    I'm not really sure what you have against Microsoft, or what "Microsoft classic" you'd be referring to...

    In the last 10 years or so they pretty much moved everything C# related to Core, cross platform and open source. Even the decision making for the language is "Open source" - Microsoft is not really behaving the same as the Microsoft from 2000...

    Soo, I don't really know how they could possibly fuck it up. They might add more and more features you might not like, but you could just choose to stick to an older version of the language

  • I'm not concerned about the Microsoft's involvement. TypeScript shows an immature tooling ecosystem even on its own merits.

    I posted some of my concerns earlier, along with a basic problem challenge (that I can easily do in many other languages) that nobody managed to solve: https://programming.dev/comment/2734178

    • This comment just seems weird no matter which angle I try to approach it from.

      immature tooling ecosystem

      It's over a decade old now. I wouldn't call that immature.

      Looking at your linked comment...

      following a basic tutorial somehow ended up spending multiple seconds just to transpile and run “Hello, World!”.

      1. Install deno
      2. Create hello.ts containing: console.log("hello world");
      3. deno run hello.ts (time taken to run command: 0.037s)

      [...] 3 different ways of specifying the files and settings you want to use [...] 3 incompatible ways to define and use a “module”

      Yes, that tends to happen as ecosystems evolve over time. Typescript allows developers to use modern standards-compliant modules, while maintaining backwards compatibility for older code.

      embracing duck typing means [...]

      One of typescript's strengths is that its type system isn't all or nothing. Typescript will support duck typers, but it isn't forced or limited to that. You can add as much or as little typing as you want. In theory, this means that the language supports simple beginners up to experts creating turing-complete theorem solvers at compile time. In practice, this means a much smoother onboarding and porting experience.

      Have a “generalized fibonacci” module taking 3 inputs [...]

      I'm not sure if this is the basic problem challenge or the hello world example was. It seems a bit ambiguous as to what you really want, but it's easy to create a module that takes inputs and produces outputs while running on backend servers, in browsers, and in CLIs.

      • Obviously the actual programs are trivial. The question is, how are the tools supposed to be used?

        So you say to use deno? Out of all the tutorials I found telling me what tools to use, that wasn't one of them (I really thought this "typescript" package would be the thing I was supposed to use; I just checked again on a hot cache and it was 1.7 seconds real time, 4.5 seconds cpu time, only 2.9 seconds if I pin everything to a single core). And I swear I just saw this week, people saying "seriously, don't use deno". It also doesn't seem to address the browser use case at all though.

        In other languages I know, I know how to write 4 files (the fib library and 3 frontends), and compile and/or execute them separately. I know how to shove all of them into a single blob with multiple entry points selected dynamically. I know how to shove just one frontend with the library into a single executable. I know how to separately compile the library and each frontend, producing 4 separate artifacts, with the library being dynamically replaceable. I even know how to leave them as loose files and execute them directly (barring things like C). I can choose between these things all in a single codebase, since there are no hard-coded project filenames.

        I learned these things because I knew I wanted the ability from previous languages I'd learned, and very quickly found how the new language's tools supported that.

        I don't have that for TS (JS itself seems to be fine, since I have yet to actually need all the polyfill spam). And every time I try to find an answer, I get something that contradicts everything I read before.

        That is why I say that TS is a hopelessly immature ecosystem.

67 comments