4 ms·

I really wish I saw what everyone else sees in TypeScript because that language has not sold itself to me at all, even using it professionally for years now. Ev

by sli 6y ago

I really wish I saw what everyone else sees in TypeScript because that language has not sold itself to me at all, even using it professionally for years now. Even using it's primary feature can be a pain because nobody documents their types as far as I've found. It's surprisingly common for me to write code that compiles but crashes at runtime. Other, better JS-targeting languages manage to allow me to retain type-level features at runtime while also outputting leaner, faster, and safer code. The only value prop I really see is the momentum, but it feels like a huge push for the right reasons and in the worst possible direction. It's not that TypeScript hasn't helped at all, it just doesn't feel like it's this revolutionary thing that people treat it as. And I'm not even going to touch how visually noisy and distracting I find the C#-style type syntax to be.

valand 6y ago
Good at compile-time, breaks at runtime. It is because TypeScript doesn't want to diverge far from JavaScript. TypeScript compiles to JavaScript and if you give the wrong input you'll end up with runtime errors. Usually this happens with casting. Casting an `any` variable as `string` doesn't do anything other than letting the compiler knows that it must be string. It doesn't transform the variable and throw error when it is not string. This is a bit like casting struct pointer in C. This usually happens at IO: `fetch`, `localstorage`, `fs.readFileSync`, etc. It can't be solved purely with TypeScript. I used `io-ts` to mitigate this problem. This is a good paradigm to adopt in TypeScript projects https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/ https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va.... Other than data type, brutally tweaking your tsconfig (and webpack or rollup, if you use them) can also cause errors in module resolution, which is not a nice thing. TypeScript is almost revolutionary. The thing I wish to exist is a superset of TypeScript that allows Rust-like macro. It is super handful, super beautiful.
nawgz 6y ago
> I really wish I saw what everyone else sees in TypeScript > It's surprisingly common for me to wrrite code that compiles but crashes at runtime Well, is it also common for you to allow `any` in your code? TypeScript is strongest when it can type-check your entire code. If your API endpoints return data that doesn't match your type (or at any other external data load point), TypeScript clearly can't help with that. I'm actually quite sure that if you have this kind of behavior in TypeScript, your other JS-targeting languages would fail too; you have just mis-typed something. > Other, better Yes, you're not biased > JS-targeting languages manage to allow me to retain type-level features at runtime What does this mean? They compile to put a magic key `_type` on an object? > while also outputting leaner, faster, and safer code I highly dispute your claims. You're building JS still, it's not going to be magically better - this just means you write bad TS. Show me some numbers or some code to make this claim. > it feels like a huge push for the right reasons and in the worst possible direction Given that you started your complaint with "no one documents their types", I am not so inclined to listen to your opinion. Types are the documentation. Interface names, key names, types, full autocorrect interacting with any objects, generic type support, reasonably smart type solver / caster, great error messages; these are all things TypeScript offers for learning a thin extension of JS. > I'm not even going to touch how visually noisy and distracting I find the C#-style type syntax to be Why not? I would love to hear more ridiculous complaints which only make sense thru your personal lens and have no justification or empirical evidence behind them

by sli 6y ago

valand 6y ago

Good at compile-time, breaks at runtime. It is because TypeScript doesn't want to diverge far from JavaScript. TypeScript compiles to JavaScript and if you give the wrong input you'll end up with runtime errors. Usually this happens with casting. Casting an `any` variable as `string` doesn't do anything other than letting the compiler knows that it must be string. It doesn't transform the variable and throw error when it is not string. This is a bit like casting struct pointer in C. This usually happens at IO: `fetch`, `localstorage`, `fs.readFileSync`, etc. It can't be solved purely with TypeScript. I used `io-ts` to mitigate this problem. This is a good paradigm to adopt in TypeScript projects https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/ https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va.... Other than data type, brutally tweaking your tsconfig (and webpack or rollup, if you use them) can also cause errors in module resolution, which is not a nice thing. TypeScript is almost revolutionary. The thing I wish to exist is a superset of TypeScript that allows Rust-like macro. It is super handful, super beautiful.

nawgz 6y ago

> I really wish I saw what everyone else sees in TypeScript > It's surprisingly common for me to wrrite code that compiles but crashes at runtime Well, is it also common for you to allow `any` in your code? TypeScript is strongest when it can type-check your entire code. If your API endpoints return data that doesn't match your type (or at any other external data load point), TypeScript clearly can't help with that. I'm actually quite sure that if you have this kind of behavior in TypeScript, your other JS-targeting languages would fail too; you have just mis-typed something. > Other, better Yes, you're not biased > JS-targeting languages manage to allow me to retain type-level features at runtime What does this mean? They compile to put a magic key `_type` on an object? > while also outputting leaner, faster, and safer code I highly dispute your claims. You're building JS still, it's not going to be magically better - this just means you write bad TS. Show me some numbers or some code to make this claim. > it feels like a huge push for the right reasons and in the worst possible direction Given that you started your complaint with "no one documents their types", I am not so inclined to listen to your opinion. Types are the documentation. Interface names, key names, types, full autocorrect interacting with any objects, generic type support, reasonably smart type solver / caster, great error messages; these are all things TypeScript offers for learning a thin extension of JS. > I'm not even going to touch how visually noisy and distracting I find the C#-style type syntax to be Why not? I would love to hear more ridiculous complaints which only make sense thru your personal lens and have no justification or empirical evidence behind them