4 ms·

> After years of being resistant to “extra layers of complexity that slows me down” I adopted TS and now I can’t live without it. TS isn't an extra layer of co

> After years of being resistant to “extra layers of complexity that slows me down” I adopted TS and now I can’t live without it. TS isn't an extra layer of complexity. Walking through the entire path an object takes through a library's source code to find out what fields the object has is an extra layer of complexity. Having to rely on looking at unit tests to have some idea of what to pass to a function is an extra layer of complexity. Hoping documentation is kept up to date (hint: it isn't) is an extra layer of complexity. Having code break after updating to a point release because some field got renamed or removed and there is no safety mechanism to keep chaos from happening, is an extra layer of complexity. Typescript makes you pay up front to remove a LOT of complexity down the line.

IggleSniggle 3y ago
I had the great joy of learning a massive "legacy" nodejs project a few years ago. The author had used function "arguments" as a bucket all over the place mixed with named parameters. Lots of indirection and "facade" patterns. A few high level integration tests. And to top it all off, none of it worked in isolation, lots of very loose coupling with no documentation that the coupling existed. Took me months to digest it all. TypeScript hurts to write for people who write code like that. But also, these days, it enables it: you can write that, you just need to leave an actual trail outlining the shape of those dependencies. And if you REALLY like writing lots of flexible dynamic code, typescript can enable that too, and have fun defining those complex generics. You won't. I understand the pain of typescript. It's the pain that you can either eat yourself in working through exactly what you want the shape of your dynamic things to be; it's the pain that every other developer following you will need to eat if you do the same thing in js without types. OR- You could just write your code without those "clever" features in the first place, and get the job done in less time to boot.
acdha 3y ago
I mostly agree with the general trend of your post but TypeScript is definitely an extra layer of complexity. You no longer edit the code which your browser runs, you have another toolchain to maintain, and you need to deal with things like source maps everywhere. Now, there’s a strong argument that this is more than balanced out by the things you mentioned. I personally agree with some of them but I do think that’s a legitimate point. I’ve seen every mitigating factor for TypeScript’s complexity fail so I’m not going to say it doesn’t happen.
- rezo2 3y ago
  Also you don't write code that your processor executes and, at best, you use a layer of complexity known as assembly language. That's a shame!
  - zogrodea 3y ago
    I could copy and paste JS code into a REPL/browser console to find bugs/REPL-basee development, but that won't work for Typescript. Debuggers take some more time to set up too. More complex than other typed OOP languages like C# or Java which don't have these steps.
    - com2kid 3y ago
      I got sick and tired of running code in the debugger just so I could see what fields an object even has. Or even worse, what fields an object has, at what points in time, as fields can of course be added and removed whenever. Just, like, no. Also Typescript debugging is no harder than JS debugging, setup the source maps once and it works, same as setting up debugging symbols in C#, except Visual Studio typically does that for you. If you want to debug C# code running on a web server (which you can totally do! It is an amazing feature!) you'll need to provide Visual Studio with a link to the symbol files yourself, no different than Typescript and source mappings.
  - acdha 3y ago
    … and that's why decades of work went into things like making better debugging and analysis tools, things like symbol files, etc. One of the appeals of the web was that you didn't need to deal with that but using a compiler of some sort makes that necessary again. It mostly works, most of the time, but it's never been that hard to run into some case where it doesn't. I don't think it's a deal breaker but I do consider it legitimate for someone to say they don't get enough benefit to be worth it.
    - rezo2 3y ago
      Modern web requires compiler/bundler/minimizer for js code any way, whether you use typescript or not. And this will probably never change. Rather, the web will move to use of something like webassembly.

IggleSniggle 3y ago

I had the great joy of learning a massive "legacy" nodejs project a few years ago. The author had used function "arguments" as a bucket all over the place mixed with named parameters. Lots of indirection and "facade" patterns. A few high level integration tests. And to top it all off, none of it worked in isolation, lots of very loose coupling with no documentation that the coupling existed. Took me months to digest it all. TypeScript hurts to write for people who write code like that. But also, these days, it enables it: you can write that, you just need to leave an actual trail outlining the shape of those dependencies. And if you REALLY like writing lots of flexible dynamic code, typescript can enable that too, and have fun defining those complex generics. You won't. I understand the pain of typescript. It's the pain that you can either eat yourself in working through exactly what you want the shape of your dynamic things to be; it's the pain that every other developer following you will need to eat if you do the same thing in js without types. OR- You could just write your code without those "clever" features in the first place, and get the job done in less time to boot.

acdha 3y ago

I mostly agree with the general trend of your post but TypeScript is definitely an extra layer of complexity. You no longer edit the code which your browser runs, you have another toolchain to maintain, and you need to deal with things like source maps everywhere. Now, there’s a strong argument that this is more than balanced out by the things you mentioned. I personally agree with some of them but I do think that’s a legitimate point. I’ve seen every mitigating factor for TypeScript’s complexity fail so I’m not going to say it doesn’t happen.

rezo2 3y ago
Also you don't write code that your processor executes and, at best, you use a layer of complexity known as assembly language. That's a shame!
- zogrodea 3y ago
  I could copy and paste JS code into a REPL/browser console to find bugs/REPL-basee development, but that won't work for Typescript. Debuggers take some more time to set up too. More complex than other typed OOP languages like C# or Java which don't have these steps.
  - com2kid 3y ago
    I got sick and tired of running code in the debugger just so I could see what fields an object even has. Or even worse, what fields an object has, at what points in time, as fields can of course be added and removed whenever. Just, like, no. Also Typescript debugging is no harder than JS debugging, setup the source maps once and it works, same as setting up debugging symbols in C#, except Visual Studio typically does that for you. If you want to debug C# code running on a web server (which you can totally do! It is an amazing feature!) you'll need to provide Visual Studio with a link to the symbol files yourself, no different than Typescript and source mappings.
- acdha 3y ago
  … and that's why decades of work went into things like making better debugging and analysis tools, things like symbol files, etc. One of the appeals of the web was that you didn't need to deal with that but using a compiler of some sort makes that necessary again. It mostly works, most of the time, but it's never been that hard to run into some case where it doesn't. I don't think it's a deal breaker but I do consider it legitimate for someone to say they don't get enough benefit to be worth it.
  - rezo2 3y ago
    Modern web requires compiler/bundler/minimizer for js code any way, whether you use typescript or not. And this will probably never change. Rather, the web will move to use of something like webassembly.