5 ms·

Typescript is great but it has its evils because it’s a superset of JavaScript. I really hope we get a modern language like c# where the types are guaranteed co

by nojvek 7y ago

Typescript is great but it has its evils because it’s a superset of JavaScript. I really hope we get a modern language like c# where the types are guaranteed compile + runtime and you can’t any-ignore problems. The more I use typescript I realize I want a more sound and stricter language. Like no prototype overriding at runtime.

hopia 7y ago
I agree but it's a big leap to lose Javascript interoperability to gain type soundness. There are many such compile-to-js languages but none nearly as popular as Typescript is.
seanmcdirmid 7y ago
I actually like the unsoundness when I thought I would hate it. It rarely turns out to be a problem for me, and allows some designs I’d never be able to get away with in C#. What I really want from typescript are operators and extension methods (monkey patching is a bad hack), but those would break JavaScript supersetting (typescript isn’t allowed to desugar).
jbob2000 7y ago
Noooo! Go away with those ideas! JavaScript is great because it’s not strict. That’s the flexibility that allows for speed. I have like 30 different APIs I implement at work, but I only pull out a few attributes from each. I don’t want to go to the moon and back creating types for all this crap, I’ll have more than a 100 different types to model because of all the nested data and convoluted structures the APIs return. I want the flexibility to incur tech debt where I want to, I don’t want the language to get in my way. That’s what makes JavaScript great!
- arusahni 7y ago
  In strongly typed languages, there are serialization/deserialization libraries that don't require you to type the entire JSON object - just the fields you care about.
  - sjy 7y ago
    I’m not a very skilled Haskell programmer, but every time I’ve tried to parse JSON in it I’ve felt a strong urge to switch back to Python or JavaScript. There are libraries that make it easier but I think it’s always going to be hardly to get started with JSON APIs in a language with a powerful and strict type system. Of course, that extra up-front effort might be worth it in the long run due to the benefits of type safety, but as the grandparent said, sometimes programmers need the freedom to incur technical debt.
    - yawaramin 7y ago
      Out of curiousity, what exactly was the difficulty with decoding JSON in Haskell/
      - june11 7y ago
        a quick search brings up a library, not sure why you would have trouble, other than maybe experience? https://github.com/bos/aeson https://github.com/bos/aeson
        yawaramin 7y ago
        I was replying to someone who said they had trouble.
      - sjy 7y ago
        I was trying to use Aeson, which as noted in this excellent tutorial [1] (which didn’t exist when I first tried it) is “hopelessly magical for people who try to learn it by looking at provided examples, and existing tutorials don’t help that much.“ The rest of the tutorial should give you some idea of why I say that parsing JSON in Haskell is complex, at least if you’re used to doing it in JavaScript. [1]: https://artyom.me/aeson https://artyom.me/aeson
        yawaramin 7y ago
        I'm interested in specifically what issues you had with JSON.
- danielnixon 7y ago
  Counterpoint: https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-type-systems-are-not-inherently-more-open/ https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-typ...
- quickthrower2 7y ago
  Typescript has the any type when you need it. You can write your code well typed but treat api returns as any if you wish. Although entering a type definition even for 100 types isn’t a big hassle, compared to day the code that has to do something with those objects. And will probably save the odd mistake so probably comes out ahead in terms of efficiency.
- gherkinnn 7y ago
  I found that by explicitly having to write types, the structures become a lot less convoluted. You split things apart, give them names, spot patterns more easily, and encode all sorts of information in a type system. And knowing that all fields are there when you need them is a relief. Of course a code review can catch it. Of course careful programming can as well. But those are external constraints. Having internal constraints greatly reduces the amount of mess one can produce. Admittedly, sometimes to a point to which you’ve typed yourself in to a corner.
- kjtekn 7y ago
  I have a library that is much like every other library in javascript. I decided to try TypeScript on it once as a test. The idea was to implement all the correct interfaces so that people couldn't call the wrong chain of methods. The interface list was almost the same size as my entire codebase. I think TypeScript is essentially for retards. It is like "we need to lock everything down so the mediocre people we have to hire on mass can't break anything".
namelosw 7y ago
> a modern language like c# where the types are guaranteed compile + runtime and you can’t any-ignore problem. Come on, Typescript is more modern than C#. It's just started to being bloated a little bit since there are advanced type operators against structural typings. Or if you have to use a modern example, languages like Scala or Rust are more like it. Also guaranteed compile + runtime is not what C# is. Probably Haskell is more closer.
- etripe 7y ago
  Typescript is certainly newer than C#. So are Scala and Rust. Modernity and novelty are two different things, though.
  - kod 7y ago
    Scala was released within a couple years of c#. Typescript and Rust were a decade later.
yawaramin 7y ago
If I point you to a language like that right now, would there be something else stopping you from using it? Like say, lack of typings? Or 'it's too niche'? Or 'I'm not comfortable with that style'? Those are the things that keep people going to TypeScript.
jillesvangurp 7y ago
I always think of it as a gateway drug that gets people into using other languages. Most fullstack developers I know are transitioning to things like Rust, Go, Swift, Kotlin, etc. Once javascript interoperability stops being a goal, there are many other languages that suddenly become attractive. The irony with the Javascript ecosystem is that most of it is now written in typescript or other languages. That includes mainstream frameworks, tools, etc. Basically anything that matters to large numbers of developers. And of course for frontend development people don't actually ship a whole lot of third party dependencies in any case (for code size reasons). So our need for interoperability with all of that is actually pretty low. Most of the dependency hell that is NPM is really about pulling in layers of tooling that fix and work around each other in very odd and convoluted ways (i.e. webpack). React is a comparatively tiny framework of which several compatible even smaller versions exist that people tend to use when they don't care about supporting obsolete versions of javascript. What it does is pretty clever but you can recreate it in your language of choice with not too much effort (and people do this for lots of different languages). There are react inspired frameworks for Kotlin, Rust, and probably Swift, C# and a few other languages. Typescript is pretty neat if you are coming from the giant Stockholm syndrome in our industry that is Javascript. It's held us captive by being the only choice for browser based development. Thankfully that wasted 2 decades of captivity is coming to an end now. So we can get back on track improving our tooling, languages, and practices. Things like refactoring and code completion are not exactly science fiction (both worked great in the nineties already). I think it's wonderful that e.g. VS Code allowed JS/TS developers to join this millennium two decades late but it's hardly the final answer in developer productivity. Time to move on. IMHO, using Javascript these days is something to avoid. It's a compilation target at best and as such a stopgap solution until we can target WASM instead, which is possible now, will become very practical soon, and a mainstream/defacto thing to do soon after (2-3 years?). Most of this is pending on some ongoing work on fleshing out features for threading, memory management, apis, etc. Languages like typescript have a transitional role in the brief period of time that remains where transpiling to and interoperating with javascript is still better/easier/more convienient than compiling to WASM. Beyond that, unless you have a lot of javascript legacy that needs to be preserved/worked around, there are probably other languages that you might prefer to use instead. And as I argue above, there isn't actually that much code to rewrite if you consider what little of the NPM ecosystem actually ends up in your application on browsers. A few thousand lines of React code don't justify being held captive by that ecosystem. Also, most frontend code doesn't actually survive its first birthday in any case. So, what legacy?
k__ 7y ago
TypeScript already feels too much like C# for my taste. But luckily with OCaml/Reason, there is a modern alternative to all these bloated C#/Java like type-systems.

by nojvek 7y ago

hopia 7y ago

I agree but it's a big leap to lose Javascript interoperability to gain type soundness. There are many such compile-to-js languages but none nearly as popular as Typescript is.

seanmcdirmid 7y ago

I actually like the unsoundness when I thought I would hate it. It rarely turns out to be a problem for me, and allows some designs I’d never be able to get away with in C#. What I really want from typescript are operators and extension methods (monkey patching is a bad hack), but those would break JavaScript supersetting (typescript isn’t allowed to desugar).

jbob2000 7y ago

Noooo! Go away with those ideas! JavaScript is great because it’s not strict. That’s the flexibility that allows for speed. I have like 30 different APIs I implement at work, but I only pull out a few attributes from each. I don’t want to go to the moon and back creating types for all this crap, I’ll have more than a 100 different types to model because of all the nested data and convoluted structures the APIs return. I want the flexibility to incur tech debt where I want to, I don’t want the language to get in my way. That’s what makes JavaScript great!

arusahni 7y ago
In strongly typed languages, there are serialization/deserialization libraries that don't require you to type the entire JSON object - just the fields you care about.
- sjy 7y ago
  I’m not a very skilled Haskell programmer, but every time I’ve tried to parse JSON in it I’ve felt a strong urge to switch back to Python or JavaScript. There are libraries that make it easier but I think it’s always going to be hardly to get started with JSON APIs in a language with a powerful and strict type system. Of course, that extra up-front effort might be worth it in the long run due to the benefits of type safety, but as the grandparent said, sometimes programmers need the freedom to incur technical debt.
  - yawaramin 7y ago
    Out of curiousity, what exactly was the difficulty with decoding JSON in Haskell/
    - june11 7y ago
      a quick search brings up a library, not sure why you would have trouble, other than maybe experience? https://github.com/bos/aeson https://github.com/bos/aeson
      - yawaramin 7y ago
        I was replying to someone who said they had trouble.
    - sjy 7y ago
      I was trying to use Aeson, which as noted in this excellent tutorial [1] (which didn’t exist when I first tried it) is “hopelessly magical for people who try to learn it by looking at provided examples, and existing tutorials don’t help that much.“ The rest of the tutorial should give you some idea of why I say that parsing JSON in Haskell is complex, at least if you’re used to doing it in JavaScript. [1]: https://artyom.me/aeson https://artyom.me/aeson
      - yawaramin 7y ago
        I'm interested in specifically what issues you had with JSON.
danielnixon 7y ago
Counterpoint: https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-type-systems-are-not-inherently-more-open/ https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-typ...
quickthrower2 7y ago
Typescript has the any type when you need it. You can write your code well typed but treat api returns as any if you wish. Although entering a type definition even for 100 types isn’t a big hassle, compared to day the code that has to do something with those objects. And will probably save the odd mistake so probably comes out ahead in terms of efficiency.
gherkinnn 7y ago
I found that by explicitly having to write types, the structures become a lot less convoluted. You split things apart, give them names, spot patterns more easily, and encode all sorts of information in a type system. And knowing that all fields are there when you need them is a relief. Of course a code review can catch it. Of course careful programming can as well. But those are external constraints. Having internal constraints greatly reduces the amount of mess one can produce. Admittedly, sometimes to a point to which you’ve typed yourself in to a corner.
kjtekn 7y ago
I have a library that is much like every other library in javascript. I decided to try TypeScript on it once as a test. The idea was to implement all the correct interfaces so that people couldn't call the wrong chain of methods. The interface list was almost the same size as my entire codebase. I think TypeScript is essentially for retards. It is like "we need to lock everything down so the mediocre people we have to hire on mass can't break anything".

namelosw 7y ago

> a modern language like c# where the types are guaranteed compile + runtime and you can’t any-ignore problem. Come on, Typescript is more modern than C#. It's just started to being bloated a little bit since there are advanced type operators against structural typings. Or if you have to use a modern example, languages like Scala or Rust are more like it. Also guaranteed compile + runtime is not what C# is. Probably Haskell is more closer.

etripe 7y ago
Typescript is certainly newer than C#. So are Scala and Rust. Modernity and novelty are two different things, though.
- kod 7y ago
  Scala was released within a couple years of c#. Typescript and Rust were a decade later.

yawaramin 7y ago

If I point you to a language like that right now, would there be something else stopping you from using it? Like say, lack of typings? Or 'it's too niche'? Or 'I'm not comfortable with that style'? Those are the things that keep people going to TypeScript.

jillesvangurp 7y ago

I always think of it as a gateway drug that gets people into using other languages. Most fullstack developers I know are transitioning to things like Rust, Go, Swift, Kotlin, etc. Once javascript interoperability stops being a goal, there are many other languages that suddenly become attractive. The irony with the Javascript ecosystem is that most of it is now written in typescript or other languages. That includes mainstream frameworks, tools, etc. Basically anything that matters to large numbers of developers. And of course for frontend development people don't actually ship a whole lot of third party dependencies in any case (for code size reasons). So our need for interoperability with all of that is actually pretty low. Most of the dependency hell that is NPM is really about pulling in layers of tooling that fix and work around each other in very odd and convoluted ways (i.e. webpack). React is a comparatively tiny framework of which several compatible even smaller versions exist that people tend to use when they don't care about supporting obsolete versions of javascript. What it does is pretty clever but you can recreate it in your language of choice with not too much effort (and people do this for lots of different languages). There are react inspired frameworks for Kotlin, Rust, and probably Swift, C# and a few other languages. Typescript is pretty neat if you are coming from the giant Stockholm syndrome in our industry that is Javascript. It's held us captive by being the only choice for browser based development. Thankfully that wasted 2 decades of captivity is coming to an end now. So we can get back on track improving our tooling, languages, and practices. Things like refactoring and code completion are not exactly science fiction (both worked great in the nineties already). I think it's wonderful that e.g. VS Code allowed JS/TS developers to join this millennium two decades late but it's hardly the final answer in developer productivity. Time to move on. IMHO, using Javascript these days is something to avoid. It's a compilation target at best and as such a stopgap solution until we can target WASM instead, which is possible now, will become very practical soon, and a mainstream/defacto thing to do soon after (2-3 years?). Most of this is pending on some ongoing work on fleshing out features for threading, memory management, apis, etc. Languages like typescript have a transitional role in the brief period of time that remains where transpiling to and interoperating with javascript is still better/easier/more convienient than compiling to WASM. Beyond that, unless you have a lot of javascript legacy that needs to be preserved/worked around, there are probably other languages that you might prefer to use instead. And as I argue above, there isn't actually that much code to rewrite if you consider what little of the NPM ecosystem actually ends up in your application on browsers. A few thousand lines of React code don't justify being held captive by that ecosystem. Also, most frontend code doesn't actually survive its first birthday in any case. So, what legacy?

k__ 7y ago

TypeScript already feels too much like C# for my taste. But luckily with OCaml/Reason, there is a modern alternative to all these bloated C#/Java like type-systems.