8 ms·

TypeScript is a funny one. I love the language, but at the same time, I totally agree with the premise that it is unnecessary complexity! And yet I swear by it.

TypeScript is a funny one. I love the language, but at the same time, I totally agree with the premise that it is unnecessary complexity! And yet I swear by it. I can't explain why there's not more cognitive dissonance there. JavaScript taught me to love async, then functional programming, and TypeScript taught to me to love static types. I'm now desperately wishing for a world of OCaml/Haskell, but where are you going to find teammates using those? And so I'm back at TypeScript. I think all of these "higher order" languages that do transpiling (including Scala, Closure, Kotlin, Groovy, etc) fit this same scenario. Increased toolchain complexity for a decrease in development/test/maintenance complexity. With any toolchain, though, it can be hard to know where to draw the line for "worth it for this project" until you're already an expert in using the toolchain, at which point, why wouldn't you use it?

deleuze 6y ago
All the JVM languages you list aren't transpiled. They target JVM bytecode just like Java. They're first class, even if Java obviously gets the overwhelming amount of VM level support. Engineers working on the JVM are definitely aware of and want to support non-Java langs.
- IggleSniggle 6y ago
  Scala can target JavaScript. Kotlin is usually used with the JVM, but can target native machine code (and JavaScript too I think?). Transpile was the wrong word for me to use.
  - deleuze 6y ago
    Ah, I wasn't thinking of the JavaScript flavors. I think "hosted" is how Clojure describes itself.
- kelnos 6y ago
  I think the parent meant that all of those have things (like scala.js) that allow you to write in the JVM language and compile to Javascript.
nudpiedo 6y ago
> I'm now desperately wishing for a world of OCaml/Haskell, but where are you going to find teammates using those? Having walked that way I can recommend you to look at F#, and if you aren't a solo developer (or you want to get real regarding jobs and colleagues) make sure you do not have allergy to C# interop.
Gibbon1 6y ago
You hit the nail on the head with tool chain complexity. Transpiling adds yet another layer in a stack that's already deep. Web isn't my field but it looks like from the outside that obsevability[1] is also lacking. Some friends that are in web programming mention a lot of younger engineers don't realize how bad it is.
flatline 6y ago
What is unnecessarily complex about TypeScript? It's JavaScript, with static typing plus type inference, and pretty nice generics. The ecosystem of modern JS surrounding it is horribly complex but TypeScript itself seems like a fairly straightforward programming language.
- zaphirplane 6y ago
  There is complexity in the type system with signatures like ``` function partialCall<T extends Arr, U extends Arr, R>(f: (...args: [...T, ...U]) => R, ...headArgs: T) { `
  - kelnos 6y ago
    It's funny that you consider that complex; I consider that a pretty normal, expressive type signature that gives the compiler critical information about how I expect to use that function, which in turn allows it to completely squash several classes of bugs I might write. But I love strong type systems; people who prefer weak type systems would likely consider things like this to get in their way.
    - melq 6y ago
      Could you elaborate on this point for someone who isn't familiar with typescript (or javascript, for that matter). I'm no stranger to strongly typed languages but that function signature seems pretty complex to me. By elaborate I mean explain what's going on in that signature, and what the critical information it supplies is?
      - flatline 6y ago
        I would say, there is some complexity in reading (and writing) the thing. But there is probably not as much complexity in using it. And you are explicitly codifying the complexity in one place, that would presumably still exist in a dynamically typed language, just implicitly, and likely spread out across the code. This looks pretty nice to me at a glance, just like anything once you write a few of them and come across a few in the wild and take the time to pick them apart they no longer seem so scary.
munchbunny 6y ago
You choose the tool chain to fit the anticipated team. If that team is just you, then who cares? Pick the easiest thing for you. But if you’re an expert in the tool chain and you anticipate new people hopping on, then the on-boarding process should definitely be one of your considerations. The argument for simpler tool chains for simpler projects is that the time it takes to on-board should not outweigh the time saved by the toolchain’s amenities. So the argument for TypeScript despite its complexities is that you believe its approach to type decorations on top of JS strikes the right balance for ease of on-boarding (IMO fairly straightforward) and supporting code maintainability (IMO a big improvement in 99% of the cases) despite the extra complexity of lengthening the toolchain (IMO it has some counterintuitive parts but you can mostly just forget about it once you find a working setup.) I won’t use TypeScript if I’m whipping something up quickly, but if I anticipate open sourcing, adding unit tests and CI, etc., then TypeScript feels like a useful addition.
- gavinray 6y ago
  I used to make the same argument, about not using TS for prototyping, but the tooling is so good that at this point, I generally just change the file extension to ".ts" and write no manual types for the mistakes and type-hints + intellisense the compiler and language server provide.
- markus_zhang 6y ago
  Yeah exactly, and we can also pick the features we need in a language. E.g. C++ is super complex after C++/11, but we can still just pick a small subset to make it easier.
  - MaxBarraclough 6y ago
    > we can still just pick a small subset Unless you have to work with legacy code or libraries.
    - munchbunny 6y ago
      Then some poor soul gets to wrap the old patterns into the new patterns! But seriously, if modern C++ has one thing going for it, it has a great backwards compatibility and forward refactoring story. I'm not a huge fan of the "evolved" syntax, and I rarely use C++ anymore, but I like modern C++ substantially more than C++03, which was where I first cut my teeth as a programmer.
chrisjarvis 6y ago
Typescript makes reading JS infinitely easier for me, I would always use for a large codebase given the option.

deleuze 6y ago

All the JVM languages you list aren't transpiled. They target JVM bytecode just like Java. They're first class, even if Java obviously gets the overwhelming amount of VM level support. Engineers working on the JVM are definitely aware of and want to support non-Java langs.

IggleSniggle 6y ago
Scala can target JavaScript. Kotlin is usually used with the JVM, but can target native machine code (and JavaScript too I think?). Transpile was the wrong word for me to use.
- deleuze 6y ago
  Ah, I wasn't thinking of the JavaScript flavors. I think "hosted" is how Clojure describes itself.
kelnos 6y ago
I think the parent meant that all of those have things (like scala.js) that allow you to write in the JVM language and compile to Javascript.

nudpiedo 6y ago

> I'm now desperately wishing for a world of OCaml/Haskell, but where are you going to find teammates using those? Having walked that way I can recommend you to look at F#, and if you aren't a solo developer (or you want to get real regarding jobs and colleagues) make sure you do not have allergy to C# interop.

Gibbon1 6y ago

You hit the nail on the head with tool chain complexity. Transpiling adds yet another layer in a stack that's already deep. Web isn't my field but it looks like from the outside that obsevability[1] is also lacking. Some friends that are in web programming mention a lot of younger engineers don't realize how bad it is.

flatline 6y ago

What is unnecessarily complex about TypeScript? It's JavaScript, with static typing plus type inference, and pretty nice generics. The ecosystem of modern JS surrounding it is horribly complex but TypeScript itself seems like a fairly straightforward programming language.

zaphirplane 6y ago
There is complexity in the type system with signatures like ``` function partialCall<T extends Arr, U extends Arr, R>(f: (...args: [...T, ...U]) => R, ...headArgs: T) { `
- kelnos 6y ago
  It's funny that you consider that complex; I consider that a pretty normal, expressive type signature that gives the compiler critical information about how I expect to use that function, which in turn allows it to completely squash several classes of bugs I might write. But I love strong type systems; people who prefer weak type systems would likely consider things like this to get in their way.
  - melq 6y ago
    Could you elaborate on this point for someone who isn't familiar with typescript (or javascript, for that matter). I'm no stranger to strongly typed languages but that function signature seems pretty complex to me. By elaborate I mean explain what's going on in that signature, and what the critical information it supplies is?
    - flatline 6y ago
      I would say, there is some complexity in reading (and writing) the thing. But there is probably not as much complexity in using it. And you are explicitly codifying the complexity in one place, that would presumably still exist in a dynamically typed language, just implicitly, and likely spread out across the code. This looks pretty nice to me at a glance, just like anything once you write a few of them and come across a few in the wild and take the time to pick them apart they no longer seem so scary.

munchbunny 6y ago

You choose the tool chain to fit the anticipated team. If that team is just you, then who cares? Pick the easiest thing for you. But if you’re an expert in the tool chain and you anticipate new people hopping on, then the on-boarding process should definitely be one of your considerations. The argument for simpler tool chains for simpler projects is that the time it takes to on-board should not outweigh the time saved by the toolchain’s amenities. So the argument for TypeScript despite its complexities is that you believe its approach to type decorations on top of JS strikes the right balance for ease of on-boarding (IMO fairly straightforward) and supporting code maintainability (IMO a big improvement in 99% of the cases) despite the extra complexity of lengthening the toolchain (IMO it has some counterintuitive parts but you can mostly just forget about it once you find a working setup.) I won’t use TypeScript if I’m whipping something up quickly, but if I anticipate open sourcing, adding unit tests and CI, etc., then TypeScript feels like a useful addition.

gavinray 6y ago
I used to make the same argument, about not using TS for prototyping, but the tooling is so good that at this point, I generally just change the file extension to ".ts" and write no manual types for the mistakes and type-hints + intellisense the compiler and language server provide.
markus_zhang 6y ago
Yeah exactly, and we can also pick the features we need in a language. E.g. C++ is super complex after C++/11, but we can still just pick a small subset to make it easier.
- MaxBarraclough 6y ago
  > we can still just pick a small subset Unless you have to work with legacy code or libraries.
  - munchbunny 6y ago
    Then some poor soul gets to wrap the old patterns into the new patterns! But seriously, if modern C++ has one thing going for it, it has a great backwards compatibility and forward refactoring story. I'm not a huge fan of the "evolved" syntax, and I rarely use C++ anymore, but I like modern C++ substantially more than C++03, which was where I first cut my teeth as a programmer.

chrisjarvis 6y ago

Typescript makes reading JS infinitely easier for me, I would always use for a large codebase given the option.