4 ms·

I don't mind TypeScript as a language that much these days. I mean, Java basically won and we're programming in it, no matter whether the files end in .java, .p

by mhd 6y ago

I don't mind TypeScript as a language that much these days. I mean, Java basically won and we're programming in it, no matter whether the files end in .java, .php, .cs or .ts, what matters is the UbiquitousDomainLanguageTermInjectedAbstractionFactory before that extension. This greases the wheels for you with excellent IDE support and a plethora of bootcamped developers/interns. But there are two things that still bother me: First, it's the usual language-as-a-product release cycle we have these days. I'm not saying that you should have a new language version including ECMA/ANSI spec every decade or so, but new features coming in every few months/weeks causes some friction. Especially in a language that tries to play catchup with free-form argument passing by trying to encase all that in semi-proper types. And the second and major one: There's a certain kind of "smell" that use of TypeScript causes for me. On the frontend, it often means that it's way too complex, needlessly isolated and probably should be replaced by other techniques. And on the backend -- why are you using TS there in the first place? Compatibility with JS shouldn't be an issue there, you're not running this in your clients browser. Just because the frontend bloat I just mentioned caused Google to tackle this by throwing all the SmallTalk VM writers on this peculiar sacrificial pyre and you got a speedy runtime out of it?

corytheboyd 6y ago
I think you would opt to use typescript on the backend for the same reason you would use it anywhere. You do end up with this awkward transpilation step to turn it into JS for production use, which is very fair to argue, but I hope nobody is running nodejs services in production directly from typescript source.
striking 6y ago
Type checking doesn't necessarily make your code look like Java. TypeScript enhances refactoring regardless of whether you're OOP or functional. Your comments about frontend TS don't seem super coherent to me, but if my read is correct you just don't like that there's a bunch of code on the frontend. What does TS have to do with that? Even a short program will benefit from type checking. Your comments about TS on the backend make even less sense to me. It's a language with a fast runtime, but it's also easy to develop with and has some really delightful tooling. If you don't like it, you're not required to use it. If you don't like JS, what does that have to do with the type checking of TS? Either I'm misreading your comment or the comment is incoherent; either way, I don't get it.
- mhd 6y ago
  > TypeScript enhances refactoring regardless of whether you're OOP or functional. I've just seen way more TS code that looks like Java than code that's C-styled Haskell (and we have/had transpiled languages that were more aimed at this, like Elm or Purescript). And also way more programmers that can do the former than the latter. This really isn't my major area of complaint here, if at all. You have large projects with plenty of programmers, so you both want to express the common micro- and macro-patterns and have solid IDE support to help you analyze and refactor that. This isn't a bad thing. I sometimes wish it would be different, but that's my "spare time philosophical meandering" part, not the part of me that gets me paid. The whole shebang of TS add-ons, its ES20xx underpinnings and the tooling surrounding it is well suited to bigger programs. I enjoy programming it it more than some other languages. The ambivalency of my initial paragraph isn't a reflection of TS's specific weaknesses or strengths, but with some organizational paradigms. And yes, type-checking can get you something even for small programs, and all the people doing it to make their laser-focused progressive UI elements bullet-proof can be happy and proud about it, but I doubt that TS would've been written just for those lucky few. As it is -- and that's why we got blog posts like this -- TS is often a step for bigger frontend projects, either from the start, or migrating ones that grew a bit too much. Again, a good way to use the language, and better than plenty of alternatives. Is it better than not having a lot of those problems in the first place because might not always need a SPA or heavy-weight components? >It's a language with a fast runtime, but it's also easy to develop with and has some really delightful tooling. Compared to Java/C#, if you're doing orthodox enterprise, or Elixir/Rust/etc if you're not? I mean, with esbuild etc., it's not as bad as it was a few years ago, but without the argument of "full-stack", I wouldn't see myself picking it in a clean room situation.
  - striking 6y ago
    I hear that, and I don't disagree with much of it. Just here to say that I work with a codebase that's typechecked and functional :)

by mhd 6y ago

corytheboyd 6y ago

I think you would opt to use typescript on the backend for the same reason you would use it anywhere. You do end up with this awkward transpilation step to turn it into JS for production use, which is very fair to argue, but I hope nobody is running nodejs services in production directly from typescript source.

striking 6y ago

Type checking doesn't necessarily make your code look like Java. TypeScript enhances refactoring regardless of whether you're OOP or functional. Your comments about frontend TS don't seem super coherent to me, but if my read is correct you just don't like that there's a bunch of code on the frontend. What does TS have to do with that? Even a short program will benefit from type checking. Your comments about TS on the backend make even less sense to me. It's a language with a fast runtime, but it's also easy to develop with and has some really delightful tooling. If you don't like it, you're not required to use it. If you don't like JS, what does that have to do with the type checking of TS? Either I'm misreading your comment or the comment is incoherent; either way, I don't get it.

mhd 6y ago
> TypeScript enhances refactoring regardless of whether you're OOP or functional. I've just seen way more TS code that looks like Java than code that's C-styled Haskell (and we have/had transpiled languages that were more aimed at this, like Elm or Purescript). And also way more programmers that can do the former than the latter. This really isn't my major area of complaint here, if at all. You have large projects with plenty of programmers, so you both want to express the common micro- and macro-patterns and have solid IDE support to help you analyze and refactor that. This isn't a bad thing. I sometimes wish it would be different, but that's my "spare time philosophical meandering" part, not the part of me that gets me paid. The whole shebang of TS add-ons, its ES20xx underpinnings and the tooling surrounding it is well suited to bigger programs. I enjoy programming it it more than some other languages. The ambivalency of my initial paragraph isn't a reflection of TS's specific weaknesses or strengths, but with some organizational paradigms. And yes, type-checking can get you something even for small programs, and all the people doing it to make their laser-focused progressive UI elements bullet-proof can be happy and proud about it, but I doubt that TS would've been written just for those lucky few. As it is -- and that's why we got blog posts like this -- TS is often a step for bigger frontend projects, either from the start, or migrating ones that grew a bit too much. Again, a good way to use the language, and better than plenty of alternatives. Is it better than not having a lot of those problems in the first place because might not always need a SPA or heavy-weight components? >It's a language with a fast runtime, but it's also easy to develop with and has some really delightful tooling. Compared to Java/C#, if you're doing orthodox enterprise, or Elixir/Rust/etc if you're not? I mean, with esbuild etc., it's not as bad as it was a few years ago, but without the argument of "full-stack", I wouldn't see myself picking it in a clean room situation.
- striking 6y ago
  I hear that, and I don't disagree with much of it. Just here to say that I work with a codebase that's typechecked and functional :)