5 ms·

Why don't you like it? Personally, I don't like it either. Firstly - entirely irrationally - because I don't like Microsoft. I grew up with them acting incredi

by fhd2 2y ago

Why don't you like it? Personally, I don't like it either. Firstly - entirely irrationally - because I don't like Microsoft. I grew up with them acting incredibly hostile towards the open source community and the rest of the industry, and I find that hard to forget. I know that has nothing to do with the merits of TypeScript, but I can't say it's not there. Secondly, I don't like the complexity incurred by any compile-to-JS language. For Figma I bet it's worth it, I bet they did their homework. But the amount of tiny projects I've seen that are an unreasonable maintenance burden because of all the packages and toolchains they use, it'd be funny if it wasn't sad. I might still use TypeScript, but for me it's more of a "give me a reason to use it" than a "give me a reason not to use it" kind of situation.

cranberryturkey 2y ago
I also hate microsoft. I worked with their piece of shit browser for 20 years. From ie3 onward they all sucked and lagged behind. Their OS was complete garbage and somehow they managed to penetrate like 90% of the desktop market. but beyond that typescript i find is cognitive overload for someone who considers themselves an expert at vanilla javascript. It more than doubles the development time. I rarely use the inflections because 50% of the time it points to "any" so its utterly useless...and these kids who claim "but you won't get an undefined error!" is just well fix your fucking undefined error when you see it...is my response. WHy do I need to 3x my dev time and hurt my brain in the process so some jackass doesn't have to worry about an undefined variable. I also think the reason MS released TS is because they were unable to find good devs who knew JS. ALl that typeshit in other languages (most enterprise crap like java and .net/c#) could now all be converted to ts devs without having to rehire. TS is for offshore teams imo. That being said I will say on a team of 50+ devs on the same codebase I would vote for typescript becuase you will get a shit load of js spaghetti otherwise from these people who can't be bothered to understand js.
- fhd2 2y ago
  Yeah, I think that's a good point. I'm actually quite on the fence about dynamic and static typing - I like both. With a small team that knows what they're doing, I tend to go dynamic. With a larger team, it does tend to become a bit of a mess and weird workarounds to not having static typing (like some mystical 100% test coverage) start to surface. I love the approach Python and MyPy took there: Python supports but ignores type annotations. You can add them to any part you want and check it with MyPy, but you can truly do it gradually, and you can always decide not to do it. An approach like that would fit JavaScript beautifully, I think.
  - gregplaysguitar 2y ago
    > supports but ignores type annotations That’s how TS works too though - compilation just strips the types via babel etc, with type checking a separate process. You opt in file by file by switching .js to .ts
    - fhd2 2y ago
      Well, the nice thing with Python types is that the _only_ difference to untyped Python is the type annotations. Last time I worked with TypeScript (two and a half years ago), it felt more like a different language _similar_ to JS. In my experience it was quite... viral. With MyPy I've genuinely seen just specific parts of a code base become typed and didn't notice any friction. I wonder what would happen if that proposal for type comments in JS went through. Would TypeScript become just a type checker / optimizing compiler? Google's Closure had an (IMHO) nicer approach (using doc comments for type annotations, see: https://github.com/google/closure-compiler/wiki/Types-in-the-Closure-Type-System https://github.com/google/closure-compiler/wiki/Types-in-the...), but I don't get the impression it'll ever catch on outside Google.
      - goeiedaggoeie 2y ago
        Closure team have also deprecated a lot of the old tooling. Closue was ahead of it's time for sure and as someone who heavily used the Closure Library and Closure compiler in advanced mode, it is sad that it did not catch on. However using TSickle you can transpile Typescript into javascript which closure compiler uses for advanced optimisations.
  - Quothling 2y ago
    I'm not absolutely certain, but doesn't Typescript work exactly the same way Python does if you set it up to do so? I think the reason you may think you can't have dynamic types in Typescript is because it's generally recommended not to do so. Sort of because that if you're using dynamic types, then you might as well be using pure JavaScript with JSDoc. Having a couple of decades of experience with dynamic and static typing, I tend to prefer static typing because it's just "easier" (more maintainable, lets you onboard people faster, lets you do a lot less code-reviewing, and other advantages all of which are more on the "managing people" side of things). Dynamic typing can be good and it certainly lets you prototype faster, but to do it well over a 5 year period you're going to need some serious governance. One thing I never liked about Python is that sometimes it "guesses" the types wrong behind the scenes. This is sort of an issue with most "magic" that you'll also see in some of the parts where Java, C# and others, lets you skip writing a lot of boring code by "guessing" your intentions. But where it's relatively easy to tell the runtime environment how to do it the way you want it in something like C#, it's not in Python. It's also often a lot less obvious unless something fails in a manner you've taken steps to expect. With JavaScript (and this includes Typescript) you have another set of issues. Since classes, types and so on are all abstractions of object and since Javascript will happily pass "nothing, but not null" around. Well... It's just so easy to make spaghetti or even code which isn't very performant. Things like classes have very little function in Typescript, I'm not saying you should never use them, because you should never be religious about these things. For the most part it's typically better to use a type/interface and a stand alone non-hoisting functions. Personally I prefer rather opinionated languages like Go, or very strict languages like Rust where everything is very locked down and unmutable until you specifically tells it not to be. Of course Rust comes with it's own "interesting" things like the borrow checker.
- Quothling 2y ago
  I'd argue that if you ever use a single "any" then you're not using Typescript but simply writing JavaScript with more steps and a compile time. Any can be useful during development, but it should never reach production. I think the reason you see so much of it in a lot of open source packages is that they've only really adopted Typescript because their consumers expect it and it was just easier for them to do it this way. We use very strict Typescript, but a lot of our internal utility packages are actually written in pure JavaScript because of the way the Node package environment works. Like our date tool, our helper API package for odata, and, our fascist linting extension package. They're all pure JS with provided types. This is because the handful of people, and the handful of times we work on these libraries it's always people who know exactly what they are doing while they do it. These same people (myself included) won't necessary be in similar positions when we write Typescript, which is why we don't use JavaScript in our day-to-day development. Since our strict Typescript setup protects us from ourselves. I'm not personally a big fan of Microsoft. Professionally I do think they are one of the absolute best IT-business partners for organisations either enterprise-sized or approaching, because of how they run their support for operations. That being said, I do think what they've done with both Typescript and C# where they sort of mix the best from both languages, has been really good for both languages. At least until you look at something like Blazor which is basically just rebranded web-forms. But I guess that's what happens with large organisations, and at least as far as Typescript is concerned, they seem to be making the "right" decisions.
- louis-lau 2y ago
  I felt the same about typescript early on. Now I really like it as I can easily program logic for hours without running the app once. I'm not sure I could do that without typing. It also makes reading code a lot easier. I can see where something is used, where it's defined, etc etc. It's much easier to get around.
- parasti 2y ago
  I use JSDoc instead of TypeScript on a codebase where I am the sole developer. It skyrockets autocompletion, helps memory recall after off time and helps prevent stupid human errors that I am bound to make unconsciously. That's IMO what type systems are designed to do - reduce the error rate of human driven development.
ayuhito 2y ago
You may like JSDoc[1] if you just want some type-safety from the IDE without the compilation overhead. It’s done wonders when I’ve had to wrangle poorly commented legacy JavaScript codebases where most of the overhead is tracing what type the input parameters are. Otherwise it’s just nice when writing a small library where you don’t want to setup a bunch of build tools. Personally, I’m impartial to TypeScript or JSDoc at this point. But I’d rather have either over plain JavaScript. [1] https://jsdoc.app/ https://jsdoc.app/
danielvaughn 2y ago
I finally kinda came around to it after a decade of writing JavaScript. It took me a while because I’d spent about a year converting Coffeescript back into JavaScript after it fell out of favor at a company I worked at. I told myself I’d never work on another js-transpiled language. I do love strong typing, but what I don’t love is a language that mimics strong typing over a loosely typed system. Every single time I’ve used it, I’ve run into some weird problems. A third party package might not have a types file, or it might have an incorrectly-defined type, etc. It can be extremely frustrating in my experience.

by fhd2 2y ago

cranberryturkey 2y ago

I also hate microsoft. I worked with their piece of shit browser for 20 years. From ie3 onward they all sucked and lagged behind. Their OS was complete garbage and somehow they managed to penetrate like 90% of the desktop market. but beyond that typescript i find is cognitive overload for someone who considers themselves an expert at vanilla javascript. It more than doubles the development time. I rarely use the inflections because 50% of the time it points to "any" so its utterly useless...and these kids who claim "but you won't get an undefined error!" is just well fix your fucking undefined error when you see it...is my response. WHy do I need to 3x my dev time and hurt my brain in the process so some jackass doesn't have to worry about an undefined variable. I also think the reason MS released TS is because they were unable to find good devs who knew JS. ALl that typeshit in other languages (most enterprise crap like java and .net/c#) could now all be converted to ts devs without having to rehire. TS is for offshore teams imo. That being said I will say on a team of 50+ devs on the same codebase I would vote for typescript becuase you will get a shit load of js spaghetti otherwise from these people who can't be bothered to understand js.

fhd2 2y ago
Yeah, I think that's a good point. I'm actually quite on the fence about dynamic and static typing - I like both. With a small team that knows what they're doing, I tend to go dynamic. With a larger team, it does tend to become a bit of a mess and weird workarounds to not having static typing (like some mystical 100% test coverage) start to surface. I love the approach Python and MyPy took there: Python supports but ignores type annotations. You can add them to any part you want and check it with MyPy, but you can truly do it gradually, and you can always decide not to do it. An approach like that would fit JavaScript beautifully, I think.
- gregplaysguitar 2y ago
  > supports but ignores type annotations That’s how TS works too though - compilation just strips the types via babel etc, with type checking a separate process. You opt in file by file by switching .js to .ts
  - fhd2 2y ago
    Well, the nice thing with Python types is that the _only_ difference to untyped Python is the type annotations. Last time I worked with TypeScript (two and a half years ago), it felt more like a different language _similar_ to JS. In my experience it was quite... viral. With MyPy I've genuinely seen just specific parts of a code base become typed and didn't notice any friction. I wonder what would happen if that proposal for type comments in JS went through. Would TypeScript become just a type checker / optimizing compiler? Google's Closure had an (IMHO) nicer approach (using doc comments for type annotations, see: https://github.com/google/closure-compiler/wiki/Types-in-the-Closure-Type-System https://github.com/google/closure-compiler/wiki/Types-in-the...), but I don't get the impression it'll ever catch on outside Google.
    - goeiedaggoeie 2y ago
      Closure team have also deprecated a lot of the old tooling. Closue was ahead of it's time for sure and as someone who heavily used the Closure Library and Closure compiler in advanced mode, it is sad that it did not catch on. However using TSickle you can transpile Typescript into javascript which closure compiler uses for advanced optimisations.
- Quothling 2y ago
  I'm not absolutely certain, but doesn't Typescript work exactly the same way Python does if you set it up to do so? I think the reason you may think you can't have dynamic types in Typescript is because it's generally recommended not to do so. Sort of because that if you're using dynamic types, then you might as well be using pure JavaScript with JSDoc. Having a couple of decades of experience with dynamic and static typing, I tend to prefer static typing because it's just "easier" (more maintainable, lets you onboard people faster, lets you do a lot less code-reviewing, and other advantages all of which are more on the "managing people" side of things). Dynamic typing can be good and it certainly lets you prototype faster, but to do it well over a 5 year period you're going to need some serious governance. One thing I never liked about Python is that sometimes it "guesses" the types wrong behind the scenes. This is sort of an issue with most "magic" that you'll also see in some of the parts where Java, C# and others, lets you skip writing a lot of boring code by "guessing" your intentions. But where it's relatively easy to tell the runtime environment how to do it the way you want it in something like C#, it's not in Python. It's also often a lot less obvious unless something fails in a manner you've taken steps to expect. With JavaScript (and this includes Typescript) you have another set of issues. Since classes, types and so on are all abstractions of object and since Javascript will happily pass "nothing, but not null" around. Well... It's just so easy to make spaghetti or even code which isn't very performant. Things like classes have very little function in Typescript, I'm not saying you should never use them, because you should never be religious about these things. For the most part it's typically better to use a type/interface and a stand alone non-hoisting functions. Personally I prefer rather opinionated languages like Go, or very strict languages like Rust where everything is very locked down and unmutable until you specifically tells it not to be. Of course Rust comes with it's own "interesting" things like the borrow checker.
Quothling 2y ago
I'd argue that if you ever use a single "any" then you're not using Typescript but simply writing JavaScript with more steps and a compile time. Any can be useful during development, but it should never reach production. I think the reason you see so much of it in a lot of open source packages is that they've only really adopted Typescript because their consumers expect it and it was just easier for them to do it this way. We use very strict Typescript, but a lot of our internal utility packages are actually written in pure JavaScript because of the way the Node package environment works. Like our date tool, our helper API package for odata, and, our fascist linting extension package. They're all pure JS with provided types. This is because the handful of people, and the handful of times we work on these libraries it's always people who know exactly what they are doing while they do it. These same people (myself included) won't necessary be in similar positions when we write Typescript, which is why we don't use JavaScript in our day-to-day development. Since our strict Typescript setup protects us from ourselves. I'm not personally a big fan of Microsoft. Professionally I do think they are one of the absolute best IT-business partners for organisations either enterprise-sized or approaching, because of how they run their support for operations. That being said, I do think what they've done with both Typescript and C# where they sort of mix the best from both languages, has been really good for both languages. At least until you look at something like Blazor which is basically just rebranded web-forms. But I guess that's what happens with large organisations, and at least as far as Typescript is concerned, they seem to be making the "right" decisions.
louis-lau 2y ago
I felt the same about typescript early on. Now I really like it as I can easily program logic for hours without running the app once. I'm not sure I could do that without typing. It also makes reading code a lot easier. I can see where something is used, where it's defined, etc etc. It's much easier to get around.
parasti 2y ago
I use JSDoc instead of TypeScript on a codebase where I am the sole developer. It skyrockets autocompletion, helps memory recall after off time and helps prevent stupid human errors that I am bound to make unconsciously. That's IMO what type systems are designed to do - reduce the error rate of human driven development.

ayuhito 2y ago

You may like JSDoc[1] if you just want some type-safety from the IDE without the compilation overhead. It’s done wonders when I’ve had to wrangle poorly commented legacy JavaScript codebases where most of the overhead is tracing what type the input parameters are. Otherwise it’s just nice when writing a small library where you don’t want to setup a bunch of build tools. Personally, I’m impartial to TypeScript or JSDoc at this point. But I’d rather have either over plain JavaScript. [1] https://jsdoc.app/ https://jsdoc.app/

danielvaughn 2y ago

I finally kinda came around to it after a decade of writing JavaScript. It took me a while because I’d spent about a year converting Coffeescript back into JavaScript after it fell out of favor at a company I worked at. I told myself I’d never work on another js-transpiled language. I do love strong typing, but what I don’t love is a language that mimics strong typing over a loosely typed system. Every single time I’ve used it, I’ve run into some weird problems. A third party package might not have a types file, or it might have an incorrectly-defined type, etc. It can be extremely frustrating in my experience.