4 ms·

I've worked with my fair share of vanilla JS devs who refuse to acknowledge the benefit of more statically typed variants of the language. Most of them bemoan t

I've worked with my fair share of vanilla JS devs who refuse to acknowledge the benefit of more statically typed variants of the language. Most of them bemoan the upfront cost of typing everything without realizing the benefits of it. I absolutely think less of them as developers.

giraffe_lady 3y ago
Not liking typescript is not the same thing as denying that types are valuable. TS has a very complex type system in exchange for relatively weak guarantees about correctness. That's a tradeoff you can choose to take or leave depending on the problem at hand, and holding that position is not the same as believing types have no value. Unless you're talking about elm or rescript or something then sure sure. But usually when people say things like this they mean typescript.
- junon 3y ago
  This is pretty much my take, too. I don't hate the idea of TS, but TS is so painful to work with, and it's owned by a company I really don't like, too.
  - dmix 3y ago
    OP is saying it's provides weak guarantees which is a result of the fact they made it easy to adopt and implement among legacy untyped code. It's the opposite of painful to work with for typing systems, compared to something like Rust which has stronger guaruntees and more predictable patterns but hard requirements the full stack is type. The result in TS is plenty of "any"s everywhere and in legacy code some situations where it's mostly just a thing veneer of type safety. But all of that makes plenty of sense because in the early days it was rare to work on a real life production JS project that was pure TS from day one in addition to having TS only libraries. These days it's everywhere and the work has been done to move away from rampant anys in popular libraries. The tooling is also mature and it's rare to find major JS libraries not already packaged with types or a @types import. Turbo moving away from TS was the rare exception.
    - arp242 3y ago
      > The tooling is also mature these days Well: % cat a.ts console.log('Hello, world!') % time tsc a.ts tsc a.ts 2.39s user 0.10s system 232% cpu 1.066 total More than a second to compile a "hello, world" (or 2.4s in CPU time) is orders of magnitudes slower than any other compiler or interpreter that I know of. It's a ridiculous start-up time. esbuild is not an alternative as it doesn't check types. What I want is "GET /foo.js" to "just" compile TS "on the fly" in dev; it's a simple "just works" kind of setup, but not possible with TS. Or for a simple system, just "roll your own": for f in *.ts; tsc $f >|$f:r.js watch-files *.js --run tsc (for f in *.ts; tsc $f) | minify >production.js Doesn't need to be shell, can be a simple JS script or whatever. You really shouldn't need millions of lines to call a compiler even in simple scenarios. What exists now is an explosion of complexity to deal with all this and I guess these systems are "mature", kind of, but for a lot of systems it's massive overkill (and even for larger systems it's not particularly great IMO). Besides, it's really a bad fix for more fundamental problems. Personally I wouldn't call TypeScript mature until compile times are roughly within the range of literally ever other compiler that has ever seen wide-spread adoption (and with that I don't mean "parallelize to 32 cores so my threadriper over 9000 can compile things in 0.1s). It doesn't need to be fast: just not a huge outlier.
      - zdragnar 3y ago
        You can still use tsc for type checking via editor language server and quality gates (with the noEmit flag) and get stupid fast compilation with swc or esbuild. Explosion of complexity and "bad fix for fundamental problems" sounds a lot like you just have an axe to grind. Many other popular languages have multiple build systems and tools to choose from as well; it isn't a particularly novel challenge.
        arp242 3y ago
        Points out real-world practical problems "You just have an axe to grind!" Hmkay. I just want things to compile, with errors, like literally everything else works. It's really not a huge ask. I don't want complex bespoke setups with multiple compilers and background processes and whatnot. The classic JS/TS response is "here is the happy path with all this tooling, but if you want something outside of that then there is something wrong with you". I guess the "axe" that I'm "grinding" is that I'm having a lot of difficulty using TS in a way that fits with my sensibilities and preferences. e.g. I don't like errors in my editor and prefer to explicitly call the compiler (for any environment). I suppose I could get all of this to work how I want it to with wrapper scripts or whatnot: but it's complex, time-consuming, and isn't needed for anything else. Based on previous conversations about this at least one person will say something along the lines of "zomg what kind of crusty old backend unix beard doesn't use VSCode and want errors in their editor, you just need to get with the times as you're stuck in the past!!!1" but again: it works for literally everything else (including other compile-to-JS tools), and is not that "obscure" of a work-flow, IMHO, and we're back to a few paragraphs ago: "move outside the happy path and you're screwed".
  - 2c2c2c 3y ago
    This take is common, but personally never understood it. The typing is optional. Use it for the easy stuff and enjoy the low hanging fruit
    - junon 3y ago
      If the tooling is a pain to use, slow, and owned by a crappy corporation, and I'm not going to use the types anyway, then I have even less of a reason to use it...
- deleted 3y ago
  [deleted]
- rafaelmn 3y ago
  Typescript can be very complex - it can also be incredibly simple - it's up to you how far you want to take it. Sure it can be an adventure to express something fully in it - but this is true for any type system I've seen. And I haven't seen another type system that's integrated into a dynamic ecosystem as well (IMO python is 5 years behind in terms of type checking experience) and that lets you chose the level of type sophistication that makes sense. Static typing, code analysis, automated testing, etc. are all great tools that become counterproductive past a certain point. Where that point is highly depends on what you're doing and typescript is one of the most flexible type systems at letting you make that choice. I'd say a lot of people are terrible at recognizing when they went too far with it for no practical gain. My only problem with it is that they can't fix the shit JS semantics.
  - giraffe_lady 3y ago
    I am professionally familiar with typescript and explicitly not making a concrete argument for or against it right now. I'm just pointing out that having an opinion about typescript is not the same thing as having an opinion about types. Something I think people are (intentionally?) conflating in these comments.
    - rmilejczz 3y ago
      I think it’s just a path a lot of developers have traveled, starting with JavaScript and moving to TypeScript. If you’ve gone through that pipeline than you probably feel very strongly about the benefits that TypeScript provides and it’s the fulcrum for your opinion on static vs dynamic typing Too many web developers, basically, I don’t think the conflation is intentional
      - PH95VuimJjqBqy 3y ago
        I think you have to give typescript a bit of a pass in terms of types. MS had unique constraints when designing it originally, so it's never going to meet the expectations of more hardcore "typists", but I think they've done a great job given the unique challenges. Not perfect for sure, but it's one of the few newer technologies where I think it's a clear win.
- smallerfish 3y ago
  Typescript's typing system is great and (for me) makes frontend development tolerable. It's annoying that it's optional. tsconfig and the related ecosystem is a disaster. I still have hopes that Kotlinjs can fix the distribution size and the tooling around binding to js libraries.
arp242 3y ago
Are these people who used types but didn't like it, or people who never really used it and refuse to even try it? IMHO these are markedly different scenarios: the first is essentially just a difference of opinion, the second is a rather myopic attitude.
lo_zamoyski 3y ago
Have they considered languages with type inference?
digging 3y ago
> bemoan the upfront cost This applies to much more than static typing as well. Anything built, can be built well or it can be built quickly. Although I often have to make trade-offs for immediate gain at work, there is a big difference between the quality of my work over time vs the quality of other devs who default to immediate returns. I will say in their defense, they play a role in the team. But I wouldn't want to work on a team where avoiding upfront costs was the expectation rather than the exception.
waffletower 3y ago
And I definitely think less of you as you as a developer as you openly admit to dogmatic and myopic prejudice regarding the nuances of typing systems and the complexity of software development contexts.
- lijok 3y ago
  Interesting. Would you have had the same response if GP stated: "I've worked with my fair share of vanilla JS devs who refuse to acknowledge the benefit of testing. Most of them bemoan the upfront cost of testing everything without realizing the benefits of it. I absolutely think less of them as developers."
  - waffletower 3y ago
    Again another binary dichotomy that doesn't neatly fit reality. I imagine the number of developers that would unilaterally dismiss all testing practices is very small.
- halfmatthalfcat 3y ago
  I mean, I'm not going to say it to someone's face but I'll definitely be judging them. Most of those who have pushed back against typescript have done so for similarly dogmatic reasons or even straight ignorance (I dont want to learn something new), so I'm not sure who is really the winner or loser in this situation.
leptons 3y ago
I absolutely realize the benefits of it, and I also recognize it doesn't cure all. Everything has trade-offs. There were plenty of amazingly complex and large projects written in vanilla JS before typescript ever existed, and somehow they aren't falling apart and crippled. It really depends on the developers involved more than the language or the dogma.
ecshafer 3y ago
This sounds like its just Typescript evangelizing. But while I love types, Typescript kind of sucks and sucks the fun out of writing Javascript. If I am going to add a compilation step to get types, I would rather write Scala or F# and compile to JS, then you also get rid of all of the warts of JS that Typescript doesn't get rid of.
- IshKebab 3y ago
  I agree Typescript doesn't solve all the warts. But it does solve a lot. The really issue with compile-to-Javascript languages is debugging. Have fun stepping through your incomprehensible generated code in dev tools. (Except Dart which has really good Dev tools support; I guess they can poke the right people to make it work.)
manicennui 3y ago
The problems with JS go far beyond its dynamic typing.

giraffe_lady 3y ago

Not liking typescript is not the same thing as denying that types are valuable. TS has a very complex type system in exchange for relatively weak guarantees about correctness. That's a tradeoff you can choose to take or leave depending on the problem at hand, and holding that position is not the same as believing types have no value. Unless you're talking about elm or rescript or something then sure sure. But usually when people say things like this they mean typescript.

junon 3y ago
This is pretty much my take, too. I don't hate the idea of TS, but TS is so painful to work with, and it's owned by a company I really don't like, too.
- dmix 3y ago
  OP is saying it's provides weak guarantees which is a result of the fact they made it easy to adopt and implement among legacy untyped code. It's the opposite of painful to work with for typing systems, compared to something like Rust which has stronger guaruntees and more predictable patterns but hard requirements the full stack is type. The result in TS is plenty of "any"s everywhere and in legacy code some situations where it's mostly just a thing veneer of type safety. But all of that makes plenty of sense because in the early days it was rare to work on a real life production JS project that was pure TS from day one in addition to having TS only libraries. These days it's everywhere and the work has been done to move away from rampant anys in popular libraries. The tooling is also mature and it's rare to find major JS libraries not already packaged with types or a @types import. Turbo moving away from TS was the rare exception.
  - arp242 3y ago
    > The tooling is also mature these days Well: % cat a.ts console.log('Hello, world!') % time tsc a.ts tsc a.ts 2.39s user 0.10s system 232% cpu 1.066 total More than a second to compile a "hello, world" (or 2.4s in CPU time) is orders of magnitudes slower than any other compiler or interpreter that I know of. It's a ridiculous start-up time. esbuild is not an alternative as it doesn't check types. What I want is "GET /foo.js" to "just" compile TS "on the fly" in dev; it's a simple "just works" kind of setup, but not possible with TS. Or for a simple system, just "roll your own": for f in *.ts; tsc $f >|$f:r.js watch-files *.js --run tsc (for f in *.ts; tsc $f) | minify >production.js Doesn't need to be shell, can be a simple JS script or whatever. You really shouldn't need millions of lines to call a compiler even in simple scenarios. What exists now is an explosion of complexity to deal with all this and I guess these systems are "mature", kind of, but for a lot of systems it's massive overkill (and even for larger systems it's not particularly great IMO). Besides, it's really a bad fix for more fundamental problems. Personally I wouldn't call TypeScript mature until compile times are roughly within the range of literally ever other compiler that has ever seen wide-spread adoption (and with that I don't mean "parallelize to 32 cores so my threadriper over 9000 can compile things in 0.1s). It doesn't need to be fast: just not a huge outlier.
    - zdragnar 3y ago
      You can still use tsc for type checking via editor language server and quality gates (with the noEmit flag) and get stupid fast compilation with swc or esbuild. Explosion of complexity and "bad fix for fundamental problems" sounds a lot like you just have an axe to grind. Many other popular languages have multiple build systems and tools to choose from as well; it isn't a particularly novel challenge.
      - arp242 3y ago
        Points out real-world practical problems "You just have an axe to grind!" Hmkay. I just want things to compile, with errors, like literally everything else works. It's really not a huge ask. I don't want complex bespoke setups with multiple compilers and background processes and whatnot. The classic JS/TS response is "here is the happy path with all this tooling, but if you want something outside of that then there is something wrong with you". I guess the "axe" that I'm "grinding" is that I'm having a lot of difficulty using TS in a way that fits with my sensibilities and preferences. e.g. I don't like errors in my editor and prefer to explicitly call the compiler (for any environment). I suppose I could get all of this to work how I want it to with wrapper scripts or whatnot: but it's complex, time-consuming, and isn't needed for anything else. Based on previous conversations about this at least one person will say something along the lines of "zomg what kind of crusty old backend unix beard doesn't use VSCode and want errors in their editor, you just need to get with the times as you're stuck in the past!!!1" but again: it works for literally everything else (including other compile-to-JS tools), and is not that "obscure" of a work-flow, IMHO, and we're back to a few paragraphs ago: "move outside the happy path and you're screwed".
- 2c2c2c 3y ago
  This take is common, but personally never understood it. The typing is optional. Use it for the easy stuff and enjoy the low hanging fruit
  - junon 3y ago
    If the tooling is a pain to use, slow, and owned by a crappy corporation, and I'm not going to use the types anyway, then I have even less of a reason to use it...
deleted 3y ago
[deleted]
rafaelmn 3y ago
Typescript can be very complex - it can also be incredibly simple - it's up to you how far you want to take it. Sure it can be an adventure to express something fully in it - but this is true for any type system I've seen. And I haven't seen another type system that's integrated into a dynamic ecosystem as well (IMO python is 5 years behind in terms of type checking experience) and that lets you chose the level of type sophistication that makes sense. Static typing, code analysis, automated testing, etc. are all great tools that become counterproductive past a certain point. Where that point is highly depends on what you're doing and typescript is one of the most flexible type systems at letting you make that choice. I'd say a lot of people are terrible at recognizing when they went too far with it for no practical gain. My only problem with it is that they can't fix the shit JS semantics.
- giraffe_lady 3y ago
  I am professionally familiar with typescript and explicitly not making a concrete argument for or against it right now. I'm just pointing out that having an opinion about typescript is not the same thing as having an opinion about types. Something I think people are (intentionally?) conflating in these comments.
  - rmilejczz 3y ago
    I think it’s just a path a lot of developers have traveled, starting with JavaScript and moving to TypeScript. If you’ve gone through that pipeline than you probably feel very strongly about the benefits that TypeScript provides and it’s the fulcrum for your opinion on static vs dynamic typing Too many web developers, basically, I don’t think the conflation is intentional
    - PH95VuimJjqBqy 3y ago
      I think you have to give typescript a bit of a pass in terms of types. MS had unique constraints when designing it originally, so it's never going to meet the expectations of more hardcore "typists", but I think they've done a great job given the unique challenges. Not perfect for sure, but it's one of the few newer technologies where I think it's a clear win.
smallerfish 3y ago
Typescript's typing system is great and (for me) makes frontend development tolerable. It's annoying that it's optional. tsconfig and the related ecosystem is a disaster. I still have hopes that Kotlinjs can fix the distribution size and the tooling around binding to js libraries.

arp242 3y ago

Are these people who used types but didn't like it, or people who never really used it and refuse to even try it? IMHO these are markedly different scenarios: the first is essentially just a difference of opinion, the second is a rather myopic attitude.

lo_zamoyski 3y ago

Have they considered languages with type inference?

digging 3y ago

> bemoan the upfront cost This applies to much more than static typing as well. Anything built, can be built well or it can be built quickly. Although I often have to make trade-offs for immediate gain at work, there is a big difference between the quality of my work over time vs the quality of other devs who default to immediate returns. I will say in their defense, they play a role in the team. But I wouldn't want to work on a team where avoiding upfront costs was the expectation rather than the exception.

waffletower 3y ago

And I definitely think less of you as you as a developer as you openly admit to dogmatic and myopic prejudice regarding the nuances of typing systems and the complexity of software development contexts.

lijok 3y ago
Interesting. Would you have had the same response if GP stated: "I've worked with my fair share of vanilla JS devs who refuse to acknowledge the benefit of testing. Most of them bemoan the upfront cost of testing everything without realizing the benefits of it. I absolutely think less of them as developers."
- waffletower 3y ago
  Again another binary dichotomy that doesn't neatly fit reality. I imagine the number of developers that would unilaterally dismiss all testing practices is very small.
halfmatthalfcat 3y ago
I mean, I'm not going to say it to someone's face but I'll definitely be judging them. Most of those who have pushed back against typescript have done so for similarly dogmatic reasons or even straight ignorance (I dont want to learn something new), so I'm not sure who is really the winner or loser in this situation.

leptons 3y ago

I absolutely realize the benefits of it, and I also recognize it doesn't cure all. Everything has trade-offs. There were plenty of amazingly complex and large projects written in vanilla JS before typescript ever existed, and somehow they aren't falling apart and crippled. It really depends on the developers involved more than the language or the dogma.

ecshafer 3y ago

This sounds like its just Typescript evangelizing. But while I love types, Typescript kind of sucks and sucks the fun out of writing Javascript. If I am going to add a compilation step to get types, I would rather write Scala or F# and compile to JS, then you also get rid of all of the warts of JS that Typescript doesn't get rid of.

IshKebab 3y ago
I agree Typescript doesn't solve all the warts. But it does solve a lot. The really issue with compile-to-Javascript languages is debugging. Have fun stepping through your incomprehensible generated code in dev tools. (Except Dart which has really good Dev tools support; I guess they can poke the right people to make it work.)

manicennui 3y ago

The problems with JS go far beyond its dynamic typing.