5 ms·
In my opinion the most important factor was that it is a superset of JS and any valid Javascript code is/was valid TS code. That allowed for gradual adoption an
by matt89 4y ago
In my opinion the most important factor was that it is a superset of JS and any valid Javascript code is/was valid TS code.
That allowed for gradual adoption and you didn't have to risk going all-in into new technology.
- ly3xqhl8g9 4y agoAlso the `any` type [1]. It makes porting an existing project ridiculously easy: just type everything as `any`, and it also gives freedom to the developer to think in code when developing, trusting that they (will) know what they are doing, instead of screaming at the smallest mis-type with annoying bright red squiggly lines. It is so liberating to type a variable as `any` when sketching new code, figuring things out, that I would venture to say that any language not having the `any` type actually actively hates the developer. [1] https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#any https://www.typescriptlang.org/docs/handbook/2/everyday-type...
- kuramitropolis 4y agoAnd then you have to contribute to a codebase with restrictive ESLint (bleurgh!) configuration, so you can't even try out whether your code works because the tooling disallows you from compiling it as long as it contains "any", and the other devs are like "but muh best practices". So not only you gotta work around TS, you gotta do it invisibly. How did people even live before VSCode's type hint popups covered up the previous line?
- wiseowise 4y ago> How did people even live before VSCode's type hint popups covered up the previous line? Same. Like normal people do when they use Visual Studio/IntelliJ/QTCreator
- kuramitropolis 4y agoI.e. cringing all the time?
- wiseowise 4y agoCringing at compile time safety or what?
- kuramitropolis 4y agoNo, cringing at some "helpful" popup appearing right over the previous line of code. If anything, they could've made it appear under the current line; code's still written top to bottom so it's less likely for "suggested relevant info" to obscure the actual relevant info.
- Tyriar 4y agoYou can press f8 to view the problem in a "peek view" under the problem line, or view on the problems panel.
- kuramitropolis 4y ago> 10542667 Aug 9 20:40 node_modules/typescript/lib/typescript.js aint fitting ten megs in a peek view... :(
- xodeus 4y agoThis comment has just triggered my PTSD from every Typescript project I've had to work on.
- kuramitropolis 4y agoTS is emphatically not a superset of JS. It rejects perfectly valid JS leaving you no recourse other than design your whole architecture around what TypeScript allows. Which is what Microsoft wants of course.
- uup 4y agoThat’s not true. You can import JS directly into TS or use ts-ignore annotations.
- kuramitropolis 4y ago
- uup 4y agoYou can directly import any valid JS module using TypeScript if you have “allowJS”: true in the compiler options of your tsconfig.json file. The comparison to FFI doesn’t make any sense. FFI requires compiling a special library that explicitly exports the C types. This is different than TS. Using TS, you can import any valid JS module without any special preparation. Also, you can’t import all compiled languages into each other using FFI. You can only import and export C-based types. There is no way to export a Go struct for consumption via FFI, for instance. All valid JS modules will work with TypeScript.
- kuramitropolis 4y ago>There is no way to export a Go struct for consumption via FFI, for instance. I hope not. >Using TS, you can import any valid JS module without any special preparation Why does the DTS ecosystem exist then (https://www.npmjs.com/package/@types/node https://www.npmjs.com/package/@types/node etc)
- uup 4y agod.ts files allow you to add types to imported JS. You’re free to import raw JS as an any type and the compiler won’t complain.