5 ms·

This is pretty much my take, too. I don't hate the idea of TS, but TS is so painful to work with, and it's owned by a company I really don't like, too.

by junon 3y ago

dmix 3y ago
OP is saying it's provides weak guarantees which is a result of the fact they made it easy to adopt and implement among legacy untyped code. It's the opposite of painful to work with for typing systems, compared to something like Rust which has stronger guaruntees and more predictable patterns but hard requirements the full stack is type. The result in TS is plenty of "any"s everywhere and in legacy code some situations where it's mostly just a thing veneer of type safety. But all of that makes plenty of sense because in the early days it was rare to work on a real life production JS project that was pure TS from day one in addition to having TS only libraries. These days it's everywhere and the work has been done to move away from rampant anys in popular libraries. The tooling is also mature and it's rare to find major JS libraries not already packaged with types or a @types import. Turbo moving away from TS was the rare exception.
- arp242 3y ago
  > The tooling is also mature these days Well: % cat a.ts console.log('Hello, world!') % time tsc a.ts tsc a.ts 2.39s user 0.10s system 232% cpu 1.066 total More than a second to compile a "hello, world" (or 2.4s in CPU time) is orders of magnitudes slower than any other compiler or interpreter that I know of. It's a ridiculous start-up time. esbuild is not an alternative as it doesn't check types. What I want is "GET /foo.js" to "just" compile TS "on the fly" in dev; it's a simple "just works" kind of setup, but not possible with TS. Or for a simple system, just "roll your own": for f in *.ts; tsc $f >|$f:r.js watch-files *.js --run tsc (for f in *.ts; tsc $f) | minify >production.js Doesn't need to be shell, can be a simple JS script or whatever. You really shouldn't need millions of lines to call a compiler even in simple scenarios. What exists now is an explosion of complexity to deal with all this and I guess these systems are "mature", kind of, but for a lot of systems it's massive overkill (and even for larger systems it's not particularly great IMO). Besides, it's really a bad fix for more fundamental problems. Personally I wouldn't call TypeScript mature until compile times are roughly within the range of literally ever other compiler that has ever seen wide-spread adoption (and with that I don't mean "parallelize to 32 cores so my threadriper over 9000 can compile things in 0.1s). It doesn't need to be fast: just not a huge outlier.
  - zdragnar 3y ago
    You can still use tsc for type checking via editor language server and quality gates (with the noEmit flag) and get stupid fast compilation with swc or esbuild. Explosion of complexity and "bad fix for fundamental problems" sounds a lot like you just have an axe to grind. Many other popular languages have multiple build systems and tools to choose from as well; it isn't a particularly novel challenge.
    - arp242 3y ago
      Points out real-world practical problems "You just have an axe to grind!" Hmkay. I just want things to compile, with errors, like literally everything else works. It's really not a huge ask. I don't want complex bespoke setups with multiple compilers and background processes and whatnot. The classic JS/TS response is "here is the happy path with all this tooling, but if you want something outside of that then there is something wrong with you". I guess the "axe" that I'm "grinding" is that I'm having a lot of difficulty using TS in a way that fits with my sensibilities and preferences. e.g. I don't like errors in my editor and prefer to explicitly call the compiler (for any environment). I suppose I could get all of this to work how I want it to with wrapper scripts or whatnot: but it's complex, time-consuming, and isn't needed for anything else. Based on previous conversations about this at least one person will say something along the lines of "zomg what kind of crusty old backend unix beard doesn't use VSCode and want errors in their editor, you just need to get with the times as you're stuck in the past!!!1" but again: it works for literally everything else (including other compile-to-JS tools), and is not that "obscure" of a work-flow, IMHO, and we're back to a few paragraphs ago: "move outside the happy path and you're screwed".
      - zdragnar 3y ago
        I mentioned using tsc with the noEmit flag for quality gating, which is the same workflow you would use. `tsc --noEmit a.ts` (possibly flipping the position of the flag, I forget if it is sensitive). That'll check the types without spending unnecessary time compiling with the slower tooling. From there, esbuild or swc binaries compile the code as desired. They use the same tsconfig file that tsc does, so no need for any extra complexity. They build so fast that you'll not mind having a separate command, I promise. You could even combine the two into a simple one-liner if you wanted. Compared to, say, java where you have to fight over maven or Gradle or ant, plus endless config options in XML or groovy or whatever, typescript really isn't much to complain about. Hell, trying to set up a clojure full stack project is a nightmare of conflicting opinions over tooling between lein and shadowjs or whatever. Of the big languages, C# is about the only one with a "one true way", and of the smaller ones, they simply haven't yet developed a big enough base to grow contentious enough to have divergent solutions.
2c2c2c 3y ago
This take is common, but personally never understood it. The typing is optional. Use it for the easy stuff and enjoy the low hanging fruit
- junon 3y ago
  If the tooling is a pain to use, slow, and owned by a crappy corporation, and I'm not going to use the types anyway, then I have even less of a reason to use it...

This is pretty much my take, too. I don't hate the idea of TS, but TS is so painful to work with, and it's owned by a company I really don't like, too.

by junon 3y ago

This is pretty much my take, too. I don't hate the idea of TS, but TS is so painful to work with, and it's owned by a company I really don't like, too.

dmix 3y ago

OP is saying it's provides weak guarantees which is a result of the fact they made it easy to adopt and implement among legacy untyped code. It's the opposite of painful to work with for typing systems, compared to something like Rust which has stronger guaruntees and more predictable patterns but hard requirements the full stack is type. The result in TS is plenty of "any"s everywhere and in legacy code some situations where it's mostly just a thing veneer of type safety. But all of that makes plenty of sense because in the early days it was rare to work on a real life production JS project that was pure TS from day one in addition to having TS only libraries. These days it's everywhere and the work has been done to move away from rampant anys in popular libraries. The tooling is also mature and it's rare to find major JS libraries not already packaged with types or a @types import. Turbo moving away from TS was the rare exception.

arp242 3y ago
> The tooling is also mature these days Well: % cat a.ts console.log('Hello, world!') % time tsc a.ts tsc a.ts 2.39s user 0.10s system 232% cpu 1.066 total More than a second to compile a "hello, world" (or 2.4s in CPU time) is orders of magnitudes slower than any other compiler or interpreter that I know of. It's a ridiculous start-up time. esbuild is not an alternative as it doesn't check types. What I want is "GET /foo.js" to "just" compile TS "on the fly" in dev; it's a simple "just works" kind of setup, but not possible with TS. Or for a simple system, just "roll your own": for f in *.ts; tsc $f >|$f:r.js watch-files *.js --run tsc (for f in *.ts; tsc $f) | minify >production.js Doesn't need to be shell, can be a simple JS script or whatever. You really shouldn't need millions of lines to call a compiler even in simple scenarios. What exists now is an explosion of complexity to deal with all this and I guess these systems are "mature", kind of, but for a lot of systems it's massive overkill (and even for larger systems it's not particularly great IMO). Besides, it's really a bad fix for more fundamental problems. Personally I wouldn't call TypeScript mature until compile times are roughly within the range of literally ever other compiler that has ever seen wide-spread adoption (and with that I don't mean "parallelize to 32 cores so my threadriper over 9000 can compile things in 0.1s). It doesn't need to be fast: just not a huge outlier.
- zdragnar 3y ago
  You can still use tsc for type checking via editor language server and quality gates (with the noEmit flag) and get stupid fast compilation with swc or esbuild. Explosion of complexity and "bad fix for fundamental problems" sounds a lot like you just have an axe to grind. Many other popular languages have multiple build systems and tools to choose from as well; it isn't a particularly novel challenge.
  - arp242 3y ago
    Points out real-world practical problems "You just have an axe to grind!" Hmkay. I just want things to compile, with errors, like literally everything else works. It's really not a huge ask. I don't want complex bespoke setups with multiple compilers and background processes and whatnot. The classic JS/TS response is "here is the happy path with all this tooling, but if you want something outside of that then there is something wrong with you". I guess the "axe" that I'm "grinding" is that I'm having a lot of difficulty using TS in a way that fits with my sensibilities and preferences. e.g. I don't like errors in my editor and prefer to explicitly call the compiler (for any environment). I suppose I could get all of this to work how I want it to with wrapper scripts or whatnot: but it's complex, time-consuming, and isn't needed for anything else. Based on previous conversations about this at least one person will say something along the lines of "zomg what kind of crusty old backend unix beard doesn't use VSCode and want errors in their editor, you just need to get with the times as you're stuck in the past!!!1" but again: it works for literally everything else (including other compile-to-JS tools), and is not that "obscure" of a work-flow, IMHO, and we're back to a few paragraphs ago: "move outside the happy path and you're screwed".
    - zdragnar 3y ago
      I mentioned using tsc with the noEmit flag for quality gating, which is the same workflow you would use. `tsc --noEmit a.ts` (possibly flipping the position of the flag, I forget if it is sensitive). That'll check the types without spending unnecessary time compiling with the slower tooling. From there, esbuild or swc binaries compile the code as desired. They use the same tsconfig file that tsc does, so no need for any extra complexity. They build so fast that you'll not mind having a separate command, I promise. You could even combine the two into a simple one-liner if you wanted. Compared to, say, java where you have to fight over maven or Gradle or ant, plus endless config options in XML or groovy or whatever, typescript really isn't much to complain about. Hell, trying to set up a clojure full stack project is a nightmare of conflicting opinions over tooling between lein and shadowjs or whatever. Of the big languages, C# is about the only one with a "one true way", and of the smaller ones, they simply haven't yet developed a big enough base to grow contentious enough to have divergent solutions.

2c2c2c 3y ago

This take is common, but personally never understood it. The typing is optional. Use it for the easy stuff and enjoy the low hanging fruit

junon 3y ago
If the tooling is a pain to use, slow, and owned by a crappy corporation, and I'm not going to use the types anyway, then I have even less of a reason to use it...