4 ms·

Is typescript really that great? Every implementation I have seen has 1 - Work-arounds for interoperability with non typescript / legacy third party dependenci

by dnndev 5y ago

Is typescript really that great? Every implementation I have seen has 1 - Work-arounds for interoperability with non typescript / legacy third party dependencies. (issue: ugly, non consistent code) 2 - Turn off strict type checking due to third party component compatibility. (issue: isn't the purpose of typescript type checking?) 3 - Is type checking really needed for most applications? (assuming some flavor of CRUD with the occasional special sauce). (issue: seems a bit academic unless your working on a webapp for the mars rover) This is coming from someone who programmed in java, .net, strongly typed languages for years and then feels like javascript is being held back with typescript. I love programming in vanilla javascript using frameworks (in this order) vuejs, reactjs, and charge extra to work on angular.

Toadtoad 5y ago
I like TypeScript just because it makes it easier to know what you're writing, due to features like autocomplete with types, even if I don't strictly follow it.
k__ 5y ago
I started a new project with TypeScript a few weeks ago and I kinda like it. Many libraries come with TS support out of the box and the autocomplete and automatic renaming across files is quite nice. I'm using strict mode and didn't have issues yet, but I'm just at the beginning, so let's see how it goes.
ckaygusu 5y ago
Doing Typescript for a living. 2 out of 3 of the items you wrote down has to deal with old baggage, so whatever form of language you are dealing with those, you aren't going to have a good time. You can either bite the bullet and write the type definitions yourself, or just disable the type system altogether, which, if you can isolate it to a certain area in the code, you are fine. If you are writing code that some other person is going to read and/or you are interested in having it behave reliably in the long run, I think a static type system is a must. Coupled with good unit tests, if the type checker does not complain, you can be very confident the code you wrote is working and will work for a vast majority of the cases. Typescript is especially great because, unlike some other statically typed languages, you can choose not do use it in some cases (e.g., setting up mocks for tests, writing a small script to see how stuff works, etc), which is liberating. I went from Python to Typescript. Python is still my go-to language for random tasks, though unless I have a good reason to do otherwise, I don't want to deal with a production codebase that does not do static type analysis anymore. I don't know others, but I just get more done in less amount of time in this way.
- dnndev 5y ago
  “If you are writing code that some other person is going to read and/or you are interested in having it behave reliably in the long run, I think a static type system is a must.” Can’t this be accomplished with JavaScript? Assuming your interested in clean code and best practices. “Coupled with good unit tests” Can’t you also write unit tests in JavaScript? “if the type checker does not complain, you can be very confident the code you wrote is working and will work for a vast majority of the cases.” This is a false sense of security. “Compiling” without errors just tells me I did not do something dumb like assign a string to an int. Is this really the main issue devs have? From what I have seen no… Devs usually need to chase down and understand the code regardless of type checking. Thanks for your perspective!
  - Orphis 5y ago
    I don't have that much experience migrating codebases from JS to TS, but I do have experience converting codebases from C to C++. The corollary is that C++ is typesafe while C isn't. So you can call a function taking a point to an int with a pointer to a double, and the compiler won't complain (too much). Word on the street says that C programmers are usually expert engineers that know what they're doing. Yet, I had to deal with those conversion errors all the time. That C code isn't a random CRUD application on a simple website. That can be software embedded in controllers in sensitive equipment, or equipment that will be harder to update. So it's even more important to get it right. And yet...
    - fanf2 5y ago
      In C if you pass a pointer to double to a function expecting a pointer to int, that is a constraint violation (see 6.5.16.1 in the standard), and the compiler is required to emit a diagnostic.
  - ckaygusu 5y ago
    > Can’t this be accomplished with JavaScript? Assuming your interested in clean code and best practices. There's nothing that prevents you from swimming against a stream, but we know swimming with the stream is faster. Same thing here. It's not impossible in javascript, but typescript makes code maintenance much more easier. > Can’t you also write unit tests in JavaScript? "Being more than sum of its parts" and all that. > This is a false sense of security. “Compiling” without errors just tells me I did not do something dumb like assign a string to an int. Is this really the main issue devs have? From what I have seen no… Devs usually need to chase down and understand the code regardless of type checking. Typescript does not solve all the software engineering problems. It makes common problems and annoyances much more easy to handle.
bilalq 5y ago
> 1 - Work-arounds for interoperability with non typescript / legacy third party dependencies. (issue: ugly, non consistent code) These "workarounds" are typically to use third-party or hand-rolled type defs. The other common case is to write and use typeguard functions that do runtime type checking but can contextually narrow types inside conditional blocks that use them. It's a little extra work, but the ROI is there, in my experience. > 2 - Turn off strict type checking due to third party component compatibility. (issue: isn't the purpose of typescript type checking?) I've never seen this done. I'd always take one of the approaches I mentioned above. > 3 - Is type checking really needed for most applications? (assuming some flavor of CRUD with the occasional special sauce). (issue: seems a bit academic unless your working on a webapp for the mars rover) The productivity gains alone make it worth it, IMO. Refactoring without worry that you forgot to maybe update one place is just so freeing. Amazing auto-complete and intellisense makes it so much easier to work with third party libs you're unfamiliar with. And the best part is of course that many simple mistakes get caught before you even run your code at all. It takes me less time to write TS code than it does to write the equivalent JS in even simple projects. A higher likelihood of writing correct code is valuable in just about any setting, not just space projects.
- dnndev 5y ago
  I am glad to hear your more productive in TS. Personally takes me longer to keep all my proper interfaces and models up to date than rename variables (which does not happen all that often that is out of the scope of a function or let alone a file.)
  - bilalq 5y ago
    Your interfaces rarely change in isolation though, right? If they're changing, so are a lot of the places you're interacting with the fields of objects of those types. A "Refactor>Rename Symbol" flow on the interface field would also update all places you used it. I think it may take a little bit of time for things to "click", but once they do, it's usually much faster/easier/safer to work in TS.
wffurr 5y ago
Funnily enough, almost none of that applies to Google. 1 - there is very little third-party JS at Google due to historical issues interoperating with the Closure compiler, as documented in the post. 2 - Strict type checking is used and continually made stricter. 3 - Yes, when you have thousands of engineers contributing to the same code base for some quite sophisticated web applications, type checking is extremely useful.
Scooty 5y ago
I use TS every day on multiple projects. 1 is almost a non issue. Most libraries have decent types and TS has features for adding types yourself in your project. 2 - I've never had to disable strict mode to get a library working. Worst case you can use things like `any` as an escape hatch out of TS but it is usually tucked away in a black box that is nicely typed. Do you have examples? 3 - Correctness is important for most professional software not just billion dollar NASA projects. Runtime errors cause crashes which wrecks UX.
pjmlp 5y ago
As language on itself, it is a great achivement. For programming in it on anger, only when the underlying framework is also written in Typescript. It is so liberating to just code in JavaScript with a plain <script/> include, without the pleothora of FE build tools. Maybe one day browsers will actually replace JavaScript with Typescript.

by dnndev 5y ago

Toadtoad 5y ago

I like TypeScript just because it makes it easier to know what you're writing, due to features like autocomplete with types, even if I don't strictly follow it.

k__ 5y ago

I started a new project with TypeScript a few weeks ago and I kinda like it. Many libraries come with TS support out of the box and the autocomplete and automatic renaming across files is quite nice. I'm using strict mode and didn't have issues yet, but I'm just at the beginning, so let's see how it goes.

ckaygusu 5y ago

Doing Typescript for a living. 2 out of 3 of the items you wrote down has to deal with old baggage, so whatever form of language you are dealing with those, you aren't going to have a good time. You can either bite the bullet and write the type definitions yourself, or just disable the type system altogether, which, if you can isolate it to a certain area in the code, you are fine. If you are writing code that some other person is going to read and/or you are interested in having it behave reliably in the long run, I think a static type system is a must. Coupled with good unit tests, if the type checker does not complain, you can be very confident the code you wrote is working and will work for a vast majority of the cases. Typescript is especially great because, unlike some other statically typed languages, you can choose not do use it in some cases (e.g., setting up mocks for tests, writing a small script to see how stuff works, etc), which is liberating. I went from Python to Typescript. Python is still my go-to language for random tasks, though unless I have a good reason to do otherwise, I don't want to deal with a production codebase that does not do static type analysis anymore. I don't know others, but I just get more done in less amount of time in this way.

dnndev 5y ago
“If you are writing code that some other person is going to read and/or you are interested in having it behave reliably in the long run, I think a static type system is a must.” Can’t this be accomplished with JavaScript? Assuming your interested in clean code and best practices. “Coupled with good unit tests” Can’t you also write unit tests in JavaScript? “if the type checker does not complain, you can be very confident the code you wrote is working and will work for a vast majority of the cases.” This is a false sense of security. “Compiling” without errors just tells me I did not do something dumb like assign a string to an int. Is this really the main issue devs have? From what I have seen no… Devs usually need to chase down and understand the code regardless of type checking. Thanks for your perspective!
- Orphis 5y ago
  I don't have that much experience migrating codebases from JS to TS, but I do have experience converting codebases from C to C++. The corollary is that C++ is typesafe while C isn't. So you can call a function taking a point to an int with a pointer to a double, and the compiler won't complain (too much). Word on the street says that C programmers are usually expert engineers that know what they're doing. Yet, I had to deal with those conversion errors all the time. That C code isn't a random CRUD application on a simple website. That can be software embedded in controllers in sensitive equipment, or equipment that will be harder to update. So it's even more important to get it right. And yet...
  - fanf2 5y ago
    In C if you pass a pointer to double to a function expecting a pointer to int, that is a constraint violation (see 6.5.16.1 in the standard), and the compiler is required to emit a diagnostic.
- ckaygusu 5y ago
  > Can’t this be accomplished with JavaScript? Assuming your interested in clean code and best practices. There's nothing that prevents you from swimming against a stream, but we know swimming with the stream is faster. Same thing here. It's not impossible in javascript, but typescript makes code maintenance much more easier. > Can’t you also write unit tests in JavaScript? "Being more than sum of its parts" and all that. > This is a false sense of security. “Compiling” without errors just tells me I did not do something dumb like assign a string to an int. Is this really the main issue devs have? From what I have seen no… Devs usually need to chase down and understand the code regardless of type checking. Typescript does not solve all the software engineering problems. It makes common problems and annoyances much more easy to handle.

bilalq 5y ago

> 1 - Work-arounds for interoperability with non typescript / legacy third party dependencies. (issue: ugly, non consistent code) These "workarounds" are typically to use third-party or hand-rolled type defs. The other common case is to write and use typeguard functions that do runtime type checking but can contextually narrow types inside conditional blocks that use them. It's a little extra work, but the ROI is there, in my experience. > 2 - Turn off strict type checking due to third party component compatibility. (issue: isn't the purpose of typescript type checking?) I've never seen this done. I'd always take one of the approaches I mentioned above. > 3 - Is type checking really needed for most applications? (assuming some flavor of CRUD with the occasional special sauce). (issue: seems a bit academic unless your working on a webapp for the mars rover) The productivity gains alone make it worth it, IMO. Refactoring without worry that you forgot to maybe update one place is just so freeing. Amazing auto-complete and intellisense makes it so much easier to work with third party libs you're unfamiliar with. And the best part is of course that many simple mistakes get caught before you even run your code at all. It takes me less time to write TS code than it does to write the equivalent JS in even simple projects. A higher likelihood of writing correct code is valuable in just about any setting, not just space projects.

dnndev 5y ago
I am glad to hear your more productive in TS. Personally takes me longer to keep all my proper interfaces and models up to date than rename variables (which does not happen all that often that is out of the scope of a function or let alone a file.)
- bilalq 5y ago
  Your interfaces rarely change in isolation though, right? If they're changing, so are a lot of the places you're interacting with the fields of objects of those types. A "Refactor>Rename Symbol" flow on the interface field would also update all places you used it. I think it may take a little bit of time for things to "click", but once they do, it's usually much faster/easier/safer to work in TS.

wffurr 5y ago

Funnily enough, almost none of that applies to Google. 1 - there is very little third-party JS at Google due to historical issues interoperating with the Closure compiler, as documented in the post. 2 - Strict type checking is used and continually made stricter. 3 - Yes, when you have thousands of engineers contributing to the same code base for some quite sophisticated web applications, type checking is extremely useful.

Scooty 5y ago

I use TS every day on multiple projects. 1 is almost a non issue. Most libraries have decent types and TS has features for adding types yourself in your project. 2 - I've never had to disable strict mode to get a library working. Worst case you can use things like `any` as an escape hatch out of TS but it is usually tucked away in a black box that is nicely typed. Do you have examples? 3 - Correctness is important for most professional software not just billion dollar NASA projects. Runtime errors cause crashes which wrecks UX.

pjmlp 5y ago

As language on itself, it is a great achivement. For programming in it on anger, only when the underlying framework is also written in Typescript. It is so liberating to just code in JavaScript with a plain <script/> include, without the pleothora of FE build tools. Maybe one day browsers will actually replace JavaScript with Typescript.