4 ms·

> why limit yourself to TypeScript which is a "Compile-to-JS" language? You control the stack, make another choice. Because some of us _like_ typescript, or at

> why limit yourself to TypeScript which is a "Compile-to-JS" language? You control the stack, make another choice. Because some of us _like_ typescript, or at a minimum, have invested a significant portion of our careers learning ts/js. We want an ROI, we just don't want node/npm.

diggan 1y ago
> Because some of us _like_ typescript, or at a minimum, have invested a significant portion of our careers learning ts/js. Right, makes sense. It also makes sense that most of those learnings are transferable, it's not like TypeScript is the only language with types. So your design/architecture skills can be used elsewhere too. Locking yourself into the ecosystem of one language, then asking other runtimes to adhere to your preference sounds like a sure way of getting disappointed, instead of being pragmatic and flexible to chose the right tool for the problem.
- LoganDark 1y ago
  I haven't seen any true competition with TypeScript, at least for me. Go is unsound (Go slices...), Python is too high-level (even with mypyc), Rust is too low-level (in comparison to TS), and so on. It's not just "a language with types". Also, when I was writing a frontend and backend both in TS, I could literally share the exact same type definitions between them. Then I could use a compiler plugin (`typescript-is`) to validate on the server that payloads match the appropriate type. It was amazing and worked quite well, and I can't really see that being nearly as easy and seamless with anything else.
  - skydhash 1y ago
    I don’t understand the need to share types between frontend and backend. It’s like a strong incentive to take the wrong decisions down the lines instead of using the right data model for the domain.
    - LoganDark 1y ago
      I mean JSON payload types.
  - diggan 1y ago
    > I could literally share the exact same type definitions between them. Then I could use a compiler plugin (`typescript-is`) to validate on the server that payloads match the appropriate type. It was amazing and worked quite well, and I can't really see that being nearly as easy and seamless with anything else. But isn't that benefit just because TypeScript does compile to JavaScript and is compatible with JavaScript? Remove that compatibility, and you wouldn't get that benefit anymore, right? And if you still can get that benefit, why wouldn't you be able to get that benefit with other languages too? It's not like TypeScript gives you some inherit benefit that makes it easier to convert to JavaScript, besides the fact that it's literally a "Compile-to-JS" language.
    - LoganDark 1y ago
      > But isn't that benefit just because TypeScript does compile to JavaScript and is compatible with JavaScript? Remove that compatibility, and you wouldn't get that benefit anymore, right? JavaScript does make it easier to target both the web browser and Node.js, sure. But TypeScript also has a fairly mature type system and ecosystem (flaws in `tsc` itself notwithstanding). Not to say that no novel approaches are worth exploring, though; I just haven't seen one that rivals my TS experience yet. > And if you still can get that benefit, why wouldn't you be able to get that benefit with other languages too? That depends. In many other programming languages (such as ones that compile to WASM) it's also possible to have common code shared between server and client, but it's usually pretty inconvenient to actually get the code running in both environments. It's also possible to have a common interface definition and generate types for server and client from that definition, but that's still more complicated. Anyway I don't fault anyone for being disappointed that Deno fell into the Node.js compatibility trap. Pure TypeScript without that particular cruft is also something I was excited about. I also was excited to see what looked like some fair innovation (like their import mechanism and their sandboxing) but I don't know how that'll continue if Node.js compatibility ends up being too much of a time sink. I don't have very strong opinions because I've never really used Deno and I probably won't even bother at this point, but I definitely would not agree that this is just a problem of needing to use another programming language instead.
  - foldr 1y ago
    >Go is unsound (Go slices...) What are you referring to here? Go's current slice implementation could only possibly introduce unsoundness via data races. Even there, I think you might actually need to muck around with an interface value rather than a slice to demonstrate unsoundness of the type system (rather than just memory corruption or unsafe memory access). Typescript's type system is just deliberately unsound by design (for defensible reasons). It's a whole nother level of unsoundness in comparison to Go.
    - LoganDark 1y ago
      > What are you referring to here? In this case my use of "unsound" is somewhat stretched to "particularly easy to make subtle mistakes as a programmer": https://www.reddit.com/r/golang/comments/1h5ws8e/comment/m09pzcu/ https://www.reddit.com/r/golang/comments/1h5ws8e/comment/m09... https://build-your-own.org/blog/20241125_go_slice_surprise/ https://build-your-own.org/blog/20241125_go_slice_surprise/
- rtpg 1y ago
  Typescript's type system is uniquely good for preventing types in "bog standard enterprise code". No other language comes close to it. Two words: untagged unions. And of course all the other utilities it provides. It's extremely good! Shame about it being coupled to Javascript.

diggan 1y ago

> Because some of us _like_ typescript, or at a minimum, have invested a significant portion of our careers learning ts/js. Right, makes sense. It also makes sense that most of those learnings are transferable, it's not like TypeScript is the only language with types. So your design/architecture skills can be used elsewhere too. Locking yourself into the ecosystem of one language, then asking other runtimes to adhere to your preference sounds like a sure way of getting disappointed, instead of being pragmatic and flexible to chose the right tool for the problem.

LoganDark 1y ago
I haven't seen any true competition with TypeScript, at least for me. Go is unsound (Go slices...), Python is too high-level (even with mypyc), Rust is too low-level (in comparison to TS), and so on. It's not just "a language with types". Also, when I was writing a frontend and backend both in TS, I could literally share the exact same type definitions between them. Then I could use a compiler plugin (`typescript-is`) to validate on the server that payloads match the appropriate type. It was amazing and worked quite well, and I can't really see that being nearly as easy and seamless with anything else.
- skydhash 1y ago
  I don’t understand the need to share types between frontend and backend. It’s like a strong incentive to take the wrong decisions down the lines instead of using the right data model for the domain.
  - LoganDark 1y ago
    I mean JSON payload types.
- diggan 1y ago
  > I could literally share the exact same type definitions between them. Then I could use a compiler plugin (`typescript-is`) to validate on the server that payloads match the appropriate type. It was amazing and worked quite well, and I can't really see that being nearly as easy and seamless with anything else. But isn't that benefit just because TypeScript does compile to JavaScript and is compatible with JavaScript? Remove that compatibility, and you wouldn't get that benefit anymore, right? And if you still can get that benefit, why wouldn't you be able to get that benefit with other languages too? It's not like TypeScript gives you some inherit benefit that makes it easier to convert to JavaScript, besides the fact that it's literally a "Compile-to-JS" language.
  - LoganDark 1y ago
    > But isn't that benefit just because TypeScript does compile to JavaScript and is compatible with JavaScript? Remove that compatibility, and you wouldn't get that benefit anymore, right? JavaScript does make it easier to target both the web browser and Node.js, sure. But TypeScript also has a fairly mature type system and ecosystem (flaws in `tsc` itself notwithstanding). Not to say that no novel approaches are worth exploring, though; I just haven't seen one that rivals my TS experience yet. > And if you still can get that benefit, why wouldn't you be able to get that benefit with other languages too? That depends. In many other programming languages (such as ones that compile to WASM) it's also possible to have common code shared between server and client, but it's usually pretty inconvenient to actually get the code running in both environments. It's also possible to have a common interface definition and generate types for server and client from that definition, but that's still more complicated. Anyway I don't fault anyone for being disappointed that Deno fell into the Node.js compatibility trap. Pure TypeScript without that particular cruft is also something I was excited about. I also was excited to see what looked like some fair innovation (like their import mechanism and their sandboxing) but I don't know how that'll continue if Node.js compatibility ends up being too much of a time sink. I don't have very strong opinions because I've never really used Deno and I probably won't even bother at this point, but I definitely would not agree that this is just a problem of needing to use another programming language instead.
- foldr 1y ago
  >Go is unsound (Go slices...) What are you referring to here? Go's current slice implementation could only possibly introduce unsoundness via data races. Even there, I think you might actually need to muck around with an interface value rather than a slice to demonstrate unsoundness of the type system (rather than just memory corruption or unsafe memory access). Typescript's type system is just deliberately unsound by design (for defensible reasons). It's a whole nother level of unsoundness in comparison to Go.
  - LoganDark 1y ago
    > What are you referring to here? In this case my use of "unsound" is somewhat stretched to "particularly easy to make subtle mistakes as a programmer": https://www.reddit.com/r/golang/comments/1h5ws8e/comment/m09pzcu/ https://www.reddit.com/r/golang/comments/1h5ws8e/comment/m09... https://build-your-own.org/blog/20241125_go_slice_surprise/ https://build-your-own.org/blog/20241125_go_slice_surprise/
rtpg 1y ago
Typescript's type system is uniquely good for preventing types in "bog standard enterprise code". No other language comes close to it. Two words: untagged unions. And of course all the other utilities it provides. It's extremely good! Shame about it being coupled to Javascript.