10 ms·

I much prefer TypeScript than JavaScript, but TS can still allow shitty code, such as: * Using the type 'any'. * Using the immediate value `undefined` (JS is

by knocte 8y ago

I much prefer TypeScript than JavaScript, but TS can still allow shitty code, such as: * Using the type 'any'. * Using the immediate value `undefined` (JS is mental in the fact that it has two kinds of null... and with TS there's really no excuse for using this one, however TS compiler doesn't complain). * Using very ugly, or very easy to be misleading, typeguards (granted, TS doesn't have decent typeguards, see https://github.com/Microsoft/TypeScript/issues/28337 https://github.com/Microsoft/TypeScript/issues/28337 ...). For these reasons, I applaud JS people moving to TS. But I will not recommend any other people (non-JS) to use TS at all.

aphextron 8y ago
>* Using the type 'any'. This is easily enforced in your tsconfig.json
- knocte 8y ago
  Yeah but a decent tsc configuration is not default, so many people are still writing shitty typescript.
  - 59nadir 8y ago
    `"strict": true` is turned on by default when you run `tsc --init` and is recommended in every talk by everyone, including the TypeScript team... So I'm afraid the defaults are indeed sane and exactly what you want. I'm not sure much of what you've said in these threads really gels with reality so far. For anyone confused: `"strict": true` in `tsconfig.json` just blanket enables all type checks, including future ones. You can then opt out of specific ones of your choosing if there's too much pain caused by the original authors, but none of those things are added by default. The TS team wants you to leave strict mode on.
    - Rapzid 8y ago
      To add to this, flow control analysis requires certain stict features. To be a bit obtuse; you want flow control analysis ergo you want strict :)
  - jrockway 8y ago
    You are grasping at straws at this point. TypeScript is not the end all and be all of programming languages. It tweaks Javascript to be a little bit more sane, that's all. The kinds of people that seek out this sort of thing probably know whether or not to enable "any", and did so for their configurations. Either decision paves the way towards a cleaner future; those that started from zero and had "any" disabled on day 1, or those that are cleaning up a large codebase and are slowly making progress cleaning it up. TypeScript lets you be either person and lets you make your own decision. It is clear to someone with even cursory knowledge of Javascript and TypeScript what options are available in this regard. Whatever the default is, people can probably make the right decision for their application. It's not hard and it's not hidden.
- kevsim 8y ago
  Have a pointer to a sane default tsconfig.json people could build upon?
  - peterkelly 8y ago
    Here's what I use: { "compilerOptions": { "target": "es6", "module": "commonjs", "outDir": "../dist", "declaration": false, "strict": true, "resolveJsonModule": true, "noImplicitAny": true, "noImplicitThis": true, "noImplicitReturns": true, "noUnusedLocals": true, "jsx": "react", "lib": [ "es2017", "dom" ] }, "compileOnSave": false, "buildOnSave": false }
  - cageface 8y ago
    Just turning on the --strict flag gets you most of the checks you want in a clean codebase. https://www.typescriptlang.org/docs/handbook/compiler-options.html https://www.typescriptlang.org/docs/handbook/compiler-option...
eropple 8y ago
I very rarely see TypeScript developers actually use `any` (usually to reflect something like something parsed from arbitrary JSON that needs to be interrogated rather than just type-asserted) and in my experience it's a rare shop that doesn't use `strict` for everything to at least force it to be called out and checked in code review. `undefined` and `null` seem conventionally used to mean different things amongst the TypeScript developers I know. `null` is typically used to denote something that is consciously known to be nonexistent; `undefined` is not rarely, in my experience, used at all except as a check against something coming in from untyped modules. I'm sure there are people who honor this more in the breach than the observance, but this is pretty consistent in my experience. Personally, I've moved to TypeScript for most of my personal projects, away from both Ruby and C#, and it's fantastic. (Some things remain more appropriate for the JVM, typically Kotlin, but that's OK, too.)
- knocte 8y ago
  > I very rarely see TypeScript developers actually use `any` whoaboy, I guess you only work with people convinced about the value of TS (or types in general), but if your colleagues are a bunch of javascript fanboys, the only thing they will do is rename their .js files to .ts files and be done... "tada!!!" (this is not a fucking joke, TS allows this madness, just rename and compiles!)
  - nrb 8y ago
    What's madness about this? TypeScript is a superset of Javascript, meaning any valid Javascript is automatically valid TypeScript. If you want to force type declarations, enable strict mode.
  - ovao 8y ago
    The ability to incrementally adopt strict static type checks is a feature of TypeScript, without which TypeScript wouldn’t have seen much adoption. Without adoption, you’d not see library typings and TS-native projects, rendering it fairly useless.
    - 8y ago
cromantin 8y ago
I moved our projects to ts in early 2013. Back then there where no strict null checks (imo main feature of any modern language) and typesystem was in infancy, but still it was totally worth it - our team could reason about code and nothing broke at runtime. Now ts come long way. If your start any js project - start in on ts. And by god - enable full strict mode.
bcherny 8y ago
This hasn’t been accurate for at least 2 years. - Use the —noImplicitAny flag to prevent implicitly using any (and if you really want — I don’t think you do, but you can — completely ban any with TSLint) - Use the —strictNullChecks flag to promote null and undefined to explicit types Or, use —strict to do both of those and more. Example tsconfig.json: https://github.com/bcherny/json-schema-to-typescript/blob/master/tsconfig.json https://github.com/bcherny/json-schema-to-typescript/blob/ma... Btw, what specifically is indecent about TS’s type guards?
- knocte 8y ago
  > Use the —noImplicitAny flag Welcome to reality! When you do this in any decently-sized TS codebase, you want to kill yourself, because the "smart" devs that started the project didn't do it at the beginning, and fixing it now would take you a man month, in order to be able to enforce it moving forward. > Use the —strictNullChecks flag My previous reply also applies to this one, plus: you can still compare against undefined when using this flag (we're talking about unreadable code... even if comparing it with undefined wouldn't make any sense in a codebase with structNullChecks enabled, it's not a compiler error). > Or, use —strict to do both of those and more. My gripes above would only be solved if these strict modes were the default. Otherwise shitty and unfixable (read again: man months for a normal project) typescript code keeps being written. > what specifically is indecent about TS’s type guards? How about you read the link I posted?
  - PudgePacket 8y ago
    You point out issues that are already solved. It's a people problem you have now :) no amount of configuration is going to fix that. Also strict has been the default for quite a while!
    - knocte 8y ago
      > Also strict has been the default for quite a while! That would prevent anyone to rename a .js file to .ts and compile successfully. Which I think is not the case today. Prove otherwise please.
manigandham 8y ago
>> but TS can still allow shitty code No programming language can stop this. Your issue is with bad devs creating bad code. >> Using the type 'any'. Using 'any' is either for prototyping, truly dynamic data, or edge-case scenarios, but Typescript is still far better than having no types at all.
- knocte 8y ago
  > No programming language can stop this. Thankyou captain obvious! But if you're choosing one language over another, you know that there are languages that can prevent you to do it more than others. > but it's still far better than having no types at all. Using 'any' everywhere is like having no types at all.
  - manigandham 8y ago
    Yes, Typescript prevents you from making errors more than Javascript, that's definitely obvious. And nobody uses 'any' everywhere, that is an example of a bad dev doing bad code. It seems you're saying some people don't understand or use Typescript badly so it's somehow bad itself? Those people would make a mess in any codebase. I'm not sure you have a coherent argument here.
mcv 8y ago
I find 'any' useful as a temporary placeholder for third-party data while I figure out what I've got. I wouldn't mind if linters throw errors at it, though.
- Cthulhu_ 8y ago
  In what little TS experience I have, third party dependencies that didn't yet have proper typings was the primary motivation for using any - and even then, you can provide a placeholder / temporary type definition for 3rd party libraries yourself. Which is an annoying chore, but you can't expect every JS library to invest time in adding TS / typing support because you would like it. With that in mind though, a lot of JS libraries did add it, and the people running the @types repository did a lot of work on volunteering to add it even when the maintainers of the library didn't want it.
stareatgoats 8y ago
> But I will not recommend any other people (non-JS) to use TS at all JavaScript, and increasingly in the Typescript flavor, is the language of the web. What real alternatives are there presently, that additionally gives a developer decent career opportunities? TS vastly improves on JS in most aspects, while keeping a 100% compatibility with pure JS, i.e. you can just change the extension of a working .js file to .ts and instantly get access to the TS goodies. You seem to complain about this compatibility, but a serious TS developer will not maintain such compatibility for long (will typically start restricting 'any' type, etc). This compatibility is the effect of the TS onboarding strategy, a crucial one at that. The typeguards problem you mention is just one of the problems a JS/TS developer deals with as a matter of course, and will usually have solved by creating/using a utility library, something which JS notoriously requires, and something TS doesn't aspire to help you with, for the same above mentioned compatibility reasons.
- lmm 8y ago
  > JavaScript, and increasingly in the Typescript flavor, is the language of the web. What real alternatives are there presently, that additionally gives a developer decent career opportunities? As a Scala developer who realised the writing was on the wall for server-side rendering, I spent a good few months trying to use Typescript. It's decent, but the type system was still a huge step down from what I was used to. A month or so ago I got around to trying Scala.js, and it was... nice, and oh so easy. Facades available for all the big-name javascript libraries. Write ordinary Scala code with the advanced type system and full IDE support that I was used to, and get the same ability to rule out huge classes of errors that I have on the server side. So, Scala? It's controversial for many but it supports a lot of development styles, uses a runtime that already has a lot of enterprise backing (and will be able to interoperate with your existing libraries if you're a Java shop), and is also used for various bits of exciting newish technology (Kafka, Spark and the like). So it definitely has decent career opportunities.

by knocte 8y ago

aphextron 8y ago

>* Using the type 'any'. This is easily enforced in your tsconfig.json

knocte 8y ago
Yeah but a decent tsc configuration is not default, so many people are still writing shitty typescript.
- 59nadir 8y ago
  `"strict": true` is turned on by default when you run `tsc --init` and is recommended in every talk by everyone, including the TypeScript team... So I'm afraid the defaults are indeed sane and exactly what you want. I'm not sure much of what you've said in these threads really gels with reality so far. For anyone confused: `"strict": true` in `tsconfig.json` just blanket enables all type checks, including future ones. You can then opt out of specific ones of your choosing if there's too much pain caused by the original authors, but none of those things are added by default. The TS team wants you to leave strict mode on.
  - Rapzid 8y ago
    To add to this, flow control analysis requires certain stict features. To be a bit obtuse; you want flow control analysis ergo you want strict :)
- jrockway 8y ago
  You are grasping at straws at this point. TypeScript is not the end all and be all of programming languages. It tweaks Javascript to be a little bit more sane, that's all. The kinds of people that seek out this sort of thing probably know whether or not to enable "any", and did so for their configurations. Either decision paves the way towards a cleaner future; those that started from zero and had "any" disabled on day 1, or those that are cleaning up a large codebase and are slowly making progress cleaning it up. TypeScript lets you be either person and lets you make your own decision. It is clear to someone with even cursory knowledge of Javascript and TypeScript what options are available in this regard. Whatever the default is, people can probably make the right decision for their application. It's not hard and it's not hidden.
kevsim 8y ago
Have a pointer to a sane default tsconfig.json people could build upon?
- peterkelly 8y ago
  Here's what I use: { "compilerOptions": { "target": "es6", "module": "commonjs", "outDir": "../dist", "declaration": false, "strict": true, "resolveJsonModule": true, "noImplicitAny": true, "noImplicitThis": true, "noImplicitReturns": true, "noUnusedLocals": true, "jsx": "react", "lib": [ "es2017", "dom" ] }, "compileOnSave": false, "buildOnSave": false }
- cageface 8y ago
  Just turning on the --strict flag gets you most of the checks you want in a clean codebase. https://www.typescriptlang.org/docs/handbook/compiler-options.html https://www.typescriptlang.org/docs/handbook/compiler-option...

eropple 8y ago

I very rarely see TypeScript developers actually use `any` (usually to reflect something like something parsed from arbitrary JSON that needs to be interrogated rather than just type-asserted) and in my experience it's a rare shop that doesn't use `strict` for everything to at least force it to be called out and checked in code review. `undefined` and `null` seem conventionally used to mean different things amongst the TypeScript developers I know. `null` is typically used to denote something that is consciously known to be nonexistent; `undefined` is not rarely, in my experience, used at all except as a check against something coming in from untyped modules. I'm sure there are people who honor this more in the breach than the observance, but this is pretty consistent in my experience. Personally, I've moved to TypeScript for most of my personal projects, away from both Ruby and C#, and it's fantastic. (Some things remain more appropriate for the JVM, typically Kotlin, but that's OK, too.)

knocte 8y ago
> I very rarely see TypeScript developers actually use `any` whoaboy, I guess you only work with people convinced about the value of TS (or types in general), but if your colleagues are a bunch of javascript fanboys, the only thing they will do is rename their .js files to .ts files and be done... "tada!!!" (this is not a fucking joke, TS allows this madness, just rename and compiles!)
- nrb 8y ago
  What's madness about this? TypeScript is a superset of Javascript, meaning any valid Javascript is automatically valid TypeScript. If you want to force type declarations, enable strict mode.
- ovao 8y ago
  The ability to incrementally adopt strict static type checks is a feature of TypeScript, without which TypeScript wouldn’t have seen much adoption. Without adoption, you’d not see library typings and TS-native projects, rendering it fairly useless.
  - 8y ago

cromantin 8y ago

I moved our projects to ts in early 2013. Back then there where no strict null checks (imo main feature of any modern language) and typesystem was in infancy, but still it was totally worth it - our team could reason about code and nothing broke at runtime. Now ts come long way. If your start any js project - start in on ts. And by god - enable full strict mode.

bcherny 8y ago

This hasn’t been accurate for at least 2 years. - Use the —noImplicitAny flag to prevent implicitly using any (and if you really want — I don’t think you do, but you can — completely ban any with TSLint) - Use the —strictNullChecks flag to promote null and undefined to explicit types Or, use —strict to do both of those and more. Example tsconfig.json: https://github.com/bcherny/json-schema-to-typescript/blob/master/tsconfig.json https://github.com/bcherny/json-schema-to-typescript/blob/ma... Btw, what specifically is indecent about TS’s type guards?

knocte 8y ago
> Use the —noImplicitAny flag Welcome to reality! When you do this in any decently-sized TS codebase, you want to kill yourself, because the "smart" devs that started the project didn't do it at the beginning, and fixing it now would take you a man month, in order to be able to enforce it moving forward. > Use the —strictNullChecks flag My previous reply also applies to this one, plus: you can still compare against undefined when using this flag (we're talking about unreadable code... even if comparing it with undefined wouldn't make any sense in a codebase with structNullChecks enabled, it's not a compiler error). > Or, use —strict to do both of those and more. My gripes above would only be solved if these strict modes were the default. Otherwise shitty and unfixable (read again: man months for a normal project) typescript code keeps being written. > what specifically is indecent about TS’s type guards? How about you read the link I posted?
- PudgePacket 8y ago
  You point out issues that are already solved. It's a people problem you have now :) no amount of configuration is going to fix that. Also strict has been the default for quite a while!
  - knocte 8y ago
    > Also strict has been the default for quite a while! That would prevent anyone to rename a .js file to .ts and compile successfully. Which I think is not the case today. Prove otherwise please.

manigandham 8y ago

>> but TS can still allow shitty code No programming language can stop this. Your issue is with bad devs creating bad code. >> Using the type 'any'. Using 'any' is either for prototyping, truly dynamic data, or edge-case scenarios, but Typescript is still far better than having no types at all.

knocte 8y ago
> No programming language can stop this. Thankyou captain obvious! But if you're choosing one language over another, you know that there are languages that can prevent you to do it more than others. > but it's still far better than having no types at all. Using 'any' everywhere is like having no types at all.
- manigandham 8y ago
  Yes, Typescript prevents you from making errors more than Javascript, that's definitely obvious. And nobody uses 'any' everywhere, that is an example of a bad dev doing bad code. It seems you're saying some people don't understand or use Typescript badly so it's somehow bad itself? Those people would make a mess in any codebase. I'm not sure you have a coherent argument here.

mcv 8y ago

I find 'any' useful as a temporary placeholder for third-party data while I figure out what I've got. I wouldn't mind if linters throw errors at it, though.

Cthulhu_ 8y ago
In what little TS experience I have, third party dependencies that didn't yet have proper typings was the primary motivation for using any - and even then, you can provide a placeholder / temporary type definition for 3rd party libraries yourself. Which is an annoying chore, but you can't expect every JS library to invest time in adding TS / typing support because you would like it. With that in mind though, a lot of JS libraries did add it, and the people running the @types repository did a lot of work on volunteering to add it even when the maintainers of the library didn't want it.

stareatgoats 8y ago

> But I will not recommend any other people (non-JS) to use TS at all JavaScript, and increasingly in the Typescript flavor, is the language of the web. What real alternatives are there presently, that additionally gives a developer decent career opportunities? TS vastly improves on JS in most aspects, while keeping a 100% compatibility with pure JS, i.e. you can just change the extension of a working .js file to .ts and instantly get access to the TS goodies. You seem to complain about this compatibility, but a serious TS developer will not maintain such compatibility for long (will typically start restricting 'any' type, etc). This compatibility is the effect of the TS onboarding strategy, a crucial one at that. The typeguards problem you mention is just one of the problems a JS/TS developer deals with as a matter of course, and will usually have solved by creating/using a utility library, something which JS notoriously requires, and something TS doesn't aspire to help you with, for the same above mentioned compatibility reasons.

lmm 8y ago
> JavaScript, and increasingly in the Typescript flavor, is the language of the web. What real alternatives are there presently, that additionally gives a developer decent career opportunities? As a Scala developer who realised the writing was on the wall for server-side rendering, I spent a good few months trying to use Typescript. It's decent, but the type system was still a huge step down from what I was used to. A month or so ago I got around to trying Scala.js, and it was... nice, and oh so easy. Facades available for all the big-name javascript libraries. Write ordinary Scala code with the advanced type system and full IDE support that I was used to, and get the same ability to rule out huge classes of errors that I have on the server side. So, Scala? It's controversial for many but it supports a lot of development styles, uses a runtime that already has a lot of enterprise backing (and will be able to interoperate with your existing libraries if you're a Java shop), and is also used for various bits of exciting newish technology (Kafka, Spark and the like). So it definitely has decent career opportunities.