9 ms·

The JS ecosystem has its flaws, but one has to appreciate the speed at which momentum shifts, making clear winners obvious. The move towards TypeScript 'winnin

by yaseer 8y ago

The JS ecosystem has its flaws, but one has to appreciate the speed at which momentum shifts, making clear winners obvious. The move towards TypeScript 'winning' has been fast, and to everyone's benefit.

ianwalter 8y ago
Maybe it's a benefit when moving from Flow, but personally, I would rather have JS projects spend that time adding more tests than converting to static typing. Edit: changed strong to static.
- janpot 8y ago
  sounds like their primary goal is 'attract more contributions' rather than 'strengthen the type system'.
- jakelazaroff 8y ago
  Static types are a form of test!
  - lucisferre 8y ago
    They are a compile time contract at best, they are nothing like a test.
    - mort96 8y ago
      A lot of tests end up testing things which would've been caught by the type system. Static and strong typing doesn't make tests in general unnecessary, but it does mean you don't need quite so many trivial tests.
    - azangru 8y ago
      They are checking the shape of inputs and outputs, making it unnecessary to test that a function returns a value of a particular type or that this value has particular fields. They make sure you don't make stupid mistakes, leaving it up to you to test really valuable bits of logic.
    - Sammi 8y ago
      Half the tests I write for Javascript code are type tests. Typescript does that much better.
    - coldtea 8y ago
      Test and compile time contracts both check invariants. Abstractly speaking, there's no big conceptual chasm that separates a test in a test suite from a test the compiler makes.
  - enraged_camel 8y ago
    They aren’t, and it’s detrimental to think of them that way.
    - aylmao 8y ago
      Why do you think so? I think they're better than equivalent tests, and in fact help bring about better testing. A lot of unit tests will revolve around checking types. If you don't have to runtime-check this, you can focus unit tests on semantics and integrations assuming the underlying data structures are correct.
  - starefossen 8y ago
    Static types most definitely do not replace the need for tests!
    - asnrk 8y ago
      Your statement and the one you're responding to are wholly compatible.
    - jakelazaroff 8y ago
      Agreed! They replace the need for specific kinds of unit tests, e.g. making sure your functions accept and return the correct shapes. You still need to test the actual logic, and should be doing some sort of integration test on the application as a whole. In retrospect, my original response was too terse. Static typing and testing serve the same purpose, which is to make sure your application runs according to some measure of correctness. We shouldn't be setting up one-or-the-other dichotomies — we can have both!
      - ianwalter 8y ago
        But it misses the point I was originally making. I was not suggesting they are mutually exclusive.
        jakelazaroff 8y ago
        My interpretation of your point was that unit tests are more valuable than static types, and I don't think that's necessarily true. They're both forms of testing, and it's important to recognize their strengths and weaknesses. Static types won't help with your application logic, but they will (for example) ensure your function inputs and outputs are the correct types, help document your code and ensure consumers call your code correctly. Unit tests can only do the first one, and it's more verbose and brittle.
- mason55 8y ago
  The two are completely unrelated. When I was writing vanilla JS it felt like half my tests were just focused on ensuring that everything remained the type it was supposed to be. Not in a static type sense but in a duck type sense at least - does this object still have field X? Can I still call function Y on this object? Is this variable still defined? All those kinds of tests can be eliminated with static typing. It's true that a lot of those types of errors would get picked up in functional tests, but at least from my perspective it's not great practice to rely on a functional test to catch that kind of change. If your functional test changes it's easy to lose coverage of your basic unit tests that were only happening implicitly.
  - ianwalter 8y ago
    Funny how you say the two are completely unrelated and then go on to show how they are related with your personal experience.
    - eyelidlessness 8y ago
      While you're technically correct, this misses the value of static type checking vs type checking in tests. Tests must be written manually, must check every code path and must be updated whenever the underlying implementation changes, in order to achieve the results of static type checking. But types are declarative and will be checked automatically for every code path called.
      - amikazmi 8y ago
        1. If you dob't have tests covering code, sure type checks are better than nothing. but if you do, why do you also need type checks? 2. If the tests must be updated whenever the underlying implementation changes it might be testing too much- it's better to test behaviour, not implementation.
        eyelidlessness 8y ago
        I was addressing the above comments about tests that specifically check types. My position is that declarative types and a type checker are better because each code path is checked automatically without writing additional tests, and because the type checker automatically adapts without changing or writing new tests when the implementation changes. Testing behavior is another thing entirely.
- fingerlocks 8y ago
  Just a nitpick, but Typescript adds static typing, not strong typing. The types are still weak because implicit type conversions still exist: const x = "one two" + 3;
  - mevile 8y ago
    I think you can make either your typescript or tslint config error out on this at compile time. I think this is configurable.
bouncing 8y ago
Do people typically prefer TypeScript over ES6?
- BMorearty 8y ago
  From what I've seen, yes. I'm a big fan of ES6 and I haven't been a fan of typed languages for a long time but I'm liking using TypeScript. So are my coworkers.
  - dak1 8y ago
    Since we all tend to live in bubbles to some extent, do we have any numbers to back this up (like, # of repos/commits in each language on GitHub, or questions on StackOverflow)? I tend to view TypeScript similar to CoffeeScript — it brings to JavaScript some features from other languages that are convenient and preferred by a subset of frontend developers. It allows for experimentation in the language, and helps inform TC39 proposals. In time, I suspect support will coalesce around a specific TC39 process proposal to add type support, it will graduate to stage 3 or 4, get integrated into browsers and Babel, and enthusiasm around TypeScript will wane.
    - dangoor 8y ago
      A flexible type system like that of TypeScript is pretty big and complex. It would take considerable time and effort to get that through TC39, I think. It could happen, but seems far off to me. For data, 46% of npm's survey respondents used TypeScript: https://blog.npmjs.org/post/180868064080/this-year-in-javascript-2018-in-review-and-npms https://blog.npmjs.org/post/180868064080/this-year-in-javasc...
- chaostheory 8y ago
  Coming from a background of being comfortable with Ruby, Python, and Java; I started with ES6 a few years ago and moved over to Typescript last year. While ES6 makes Javascript much nicer, Typescript makes it way better and easier to maintain especially with a decent IDE. I already had a lot of respect for Javascript developers previously, but when I started developing node apps with ES6 it grew even more. I can only imagine the discipline needed to maintain large Javascript apps before ES6 and Typescript
mort96 8y ago
One huge thing we're giving up when moving from JS to TS is iteration speed though. The typescript compiler is not only an additional step, it's also ridiculously slow compared to other languages' compilers.
- jchw 8y ago
  Disagree. The TypeScript compiler is quite fast even on large projects. Build systems that are unable to properly parallelize builds are common in the JS world these days so you are probably experiencing tsc much slower than it is. That said, Babel now supports TypeScript so you should get nearly the same performance with TypeScript as you did with Flow or even just plain ES transpilation. That way you can do typechecking as a separate step like you would have done with Flow.
  - mort96 8y ago
    I haven't really ever seriously used flow or babel transpilation. My experience with compiled languages is mostly gcc which has initialized and started compiling in microseconds, or just writing plain JS which doesn't need transpilation. "Nearly the same performance as Flow/ES in Babel" isn't the benchmark I use.
    - jchw 8y ago
      Apples to oranges. You can use TypeScript without ES* -> ES5/ES3 transpilation. The compilation process may not be as fast as not having one, but it will be similar in speed to running a few sed commands over your source code. GCC startup time is going to be faster than Node.JS startup time, but that's irrelevant. We don't need to restart the compiler on each iteration. You can just use an auto reloader for that. And since we're real developers writing real apps, hello world is not important to us. We want to organize our code into modules and bundle those to a single JS file that is minified in production. So we're going to process the source code one way or another. C++ is a funny example to mention because it scales pretty poorly in the compilation time aspect, because it lacks modules. Compiler startup times are good... But it's not really that fun burning all 16 cores trying to compile Qt and still having it take forever. Compare to Go where compilation is so fast most people don't even talk about compilation speed. All languages compile eventually anyways, even JS. It just compiles in the browser. If you really want a "zero compilation step" experience, you can just load the TypeScript compiler directly in the browser. It's been done in the past for demos.
wanted2 8y ago
> , and to everyone's benefit. Why? I've worked on large codebases in Coffeescript, ES6 and Typescript. Whatever this whole community sings and believes, but Coffeescript still wins for me. ES6 is still trying to catch up but will probably never reach the beauty and ease of Coffeescript. Both are transpilers, only ES6 with Babel is a total horror to manage (just upgraded a large codebase to Babel 7..). Typescript takes about 2x the time to write if you want to create all your typings properly. I hear you say; only in the beginning, later it will speed up the development process. I've never seen that in reality! I've actually never seen a proper codebase in Typescript. Show me a Typescript codebase not using the type 'any'! In a decent system language you can't get away with that, it's just a fake sense of security. A good codebase should not be dependant at all by Typescript or whatever hype comes next. Writing a good codebase is IMHO a craft and should not depend on the language or a bunch of tooling. If Typescript is way to go, what about Python, Ruby, abandon it, deprecated? Are those inferior languages compared to Typescript? Typescript is just another hype, very smart play by Microsoft btw.
- ex3ndr 8y ago
  We are doing backend and frontend in Typescript and have very limited 'any' usage. Mostly for some hacky library for some small isolated need. I can the same way cast value to an Object in Java of NSObject in Swift.
- yaseer 8y ago
  There are multiple benefits from having TypeScript a clear winner. 1. One standard typed version of JS (As appose to flow and TypeScript) is a better use of open-source developer time. It also reduces decision fatigue when architecturing new JS projects. 2. TypeScript tooling is fantastic. Using VSCode or Webstorm spoils you. 3. TypeScript is a testing ground for experimental language features. It can shape the direction of future versions of JS. 4. Finally, the language is clearly well liked, in addition to being popular. We can debate the pros and cons of its quirks, but overall, the stats say developer satisfaction is high. https://hub.packtpub.com/4-key-findings-from-the-state-of-javascript-2018-developer-survey/ https://hub.packtpub.com/4-key-findings-from-the-state-of-ja...
- ng12 8y ago
Waterluvian 8y ago
I agree with your sentiment but I find the location of it almost ironic. One thing I hate is when I go into a language and it's full of, "oh don't use the built-in, use this thing over here...". If we want a clear winner to everyone's benefit, wouldn't we want Yarn to go away and for npm to gain whatever it's missing that makes Yarn relevant? To be fair, I haven't touched Yarn in years. I switched to it, loved it, and then npm got the package-lock and some performance fixes and I suddenly didn't understand why I'd want to use Yarn. I'm conflicted because on one hand I strongly believe that we're all better off using the same tools so we can help each other more easily. But that suggests that alternatives shouldn't exist, which stymies innovation.
- s_tec 8y ago
  I get what you are saying, but the two cases are different. Typescript is a whole different language from Flow, so they can't interoperate. Every package that migrates to Typescript deprives the Flow ecosystem of compatibility and mindshare, so a win for one is always a loss for the other. Nobody wants to be a loser, so this will eventually resolve itself into a single dominant choice. NPM and Yarn don't have this problem, since they are pretty much drop-in replacements for each other. As long as `yarn install` and `npm install` both get the job done equally well, picking one becomes a personal choice. Every project that adopts a standard package.json is a win for both NPM and Yarn. There doesn't need to be a loser in this case, and diversity is good.
  - Waterluvian 8y ago
    That's a really good point. Thanks for sharing. Drop in alternatives can be healthy and not that harmful. It's not like we are locked into two separate camps.

by yaseer 8y ago

ianwalter 8y ago

Maybe it's a benefit when moving from Flow, but personally, I would rather have JS projects spend that time adding more tests than converting to static typing. Edit: changed strong to static.

janpot 8y ago
sounds like their primary goal is 'attract more contributions' rather than 'strengthen the type system'.
jakelazaroff 8y ago
Static types are a form of test!
- lucisferre 8y ago
  They are a compile time contract at best, they are nothing like a test.
  - mort96 8y ago
    A lot of tests end up testing things which would've been caught by the type system. Static and strong typing doesn't make tests in general unnecessary, but it does mean you don't need quite so many trivial tests.
  - azangru 8y ago
    They are checking the shape of inputs and outputs, making it unnecessary to test that a function returns a value of a particular type or that this value has particular fields. They make sure you don't make stupid mistakes, leaving it up to you to test really valuable bits of logic.
  - Sammi 8y ago
    Half the tests I write for Javascript code are type tests. Typescript does that much better.
  - coldtea 8y ago
    Test and compile time contracts both check invariants. Abstractly speaking, there's no big conceptual chasm that separates a test in a test suite from a test the compiler makes.
- enraged_camel 8y ago
  They aren’t, and it’s detrimental to think of them that way.
  - aylmao 8y ago
    Why do you think so? I think they're better than equivalent tests, and in fact help bring about better testing. A lot of unit tests will revolve around checking types. If you don't have to runtime-check this, you can focus unit tests on semantics and integrations assuming the underlying data structures are correct.
- starefossen 8y ago
  Static types most definitely do not replace the need for tests!
  - asnrk 8y ago
    Your statement and the one you're responding to are wholly compatible.
  - jakelazaroff 8y ago
    Agreed! They replace the need for specific kinds of unit tests, e.g. making sure your functions accept and return the correct shapes. You still need to test the actual logic, and should be doing some sort of integration test on the application as a whole. In retrospect, my original response was too terse. Static typing and testing serve the same purpose, which is to make sure your application runs according to some measure of correctness. We shouldn't be setting up one-or-the-other dichotomies — we can have both!
    - ianwalter 8y ago
      But it misses the point I was originally making. I was not suggesting they are mutually exclusive.
      - jakelazaroff 8y ago
        My interpretation of your point was that unit tests are more valuable than static types, and I don't think that's necessarily true. They're both forms of testing, and it's important to recognize their strengths and weaknesses. Static types won't help with your application logic, but they will (for example) ensure your function inputs and outputs are the correct types, help document your code and ensure consumers call your code correctly. Unit tests can only do the first one, and it's more verbose and brittle.
mason55 8y ago
The two are completely unrelated. When I was writing vanilla JS it felt like half my tests were just focused on ensuring that everything remained the type it was supposed to be. Not in a static type sense but in a duck type sense at least - does this object still have field X? Can I still call function Y on this object? Is this variable still defined? All those kinds of tests can be eliminated with static typing. It's true that a lot of those types of errors would get picked up in functional tests, but at least from my perspective it's not great practice to rely on a functional test to catch that kind of change. If your functional test changes it's easy to lose coverage of your basic unit tests that were only happening implicitly.
- ianwalter 8y ago
  Funny how you say the two are completely unrelated and then go on to show how they are related with your personal experience.
  - eyelidlessness 8y ago
    While you're technically correct, this misses the value of static type checking vs type checking in tests. Tests must be written manually, must check every code path and must be updated whenever the underlying implementation changes, in order to achieve the results of static type checking. But types are declarative and will be checked automatically for every code path called.
    - amikazmi 8y ago
      1. If you dob't have tests covering code, sure type checks are better than nothing. but if you do, why do you also need type checks? 2. If the tests must be updated whenever the underlying implementation changes it might be testing too much- it's better to test behaviour, not implementation.
      - eyelidlessness 8y ago
        I was addressing the above comments about tests that specifically check types. My position is that declarative types and a type checker are better because each code path is checked automatically without writing additional tests, and because the type checker automatically adapts without changing or writing new tests when the implementation changes. Testing behavior is another thing entirely.
fingerlocks 8y ago
Just a nitpick, but Typescript adds static typing, not strong typing. The types are still weak because implicit type conversions still exist: const x = "one two" + 3;
- mevile 8y ago
  I think you can make either your typescript or tslint config error out on this at compile time. I think this is configurable.

bouncing 8y ago

Do people typically prefer TypeScript over ES6?

BMorearty 8y ago
From what I've seen, yes. I'm a big fan of ES6 and I haven't been a fan of typed languages for a long time but I'm liking using TypeScript. So are my coworkers.
- dak1 8y ago
  Since we all tend to live in bubbles to some extent, do we have any numbers to back this up (like, # of repos/commits in each language on GitHub, or questions on StackOverflow)? I tend to view TypeScript similar to CoffeeScript — it brings to JavaScript some features from other languages that are convenient and preferred by a subset of frontend developers. It allows for experimentation in the language, and helps inform TC39 proposals. In time, I suspect support will coalesce around a specific TC39 process proposal to add type support, it will graduate to stage 3 or 4, get integrated into browsers and Babel, and enthusiasm around TypeScript will wane.
  - dangoor 8y ago
    A flexible type system like that of TypeScript is pretty big and complex. It would take considerable time and effort to get that through TC39, I think. It could happen, but seems far off to me. For data, 46% of npm's survey respondents used TypeScript: https://blog.npmjs.org/post/180868064080/this-year-in-javascript-2018-in-review-and-npms https://blog.npmjs.org/post/180868064080/this-year-in-javasc...
chaostheory 8y ago
Coming from a background of being comfortable with Ruby, Python, and Java; I started with ES6 a few years ago and moved over to Typescript last year. While ES6 makes Javascript much nicer, Typescript makes it way better and easier to maintain especially with a decent IDE. I already had a lot of respect for Javascript developers previously, but when I started developing node apps with ES6 it grew even more. I can only imagine the discipline needed to maintain large Javascript apps before ES6 and Typescript

mort96 8y ago

One huge thing we're giving up when moving from JS to TS is iteration speed though. The typescript compiler is not only an additional step, it's also ridiculously slow compared to other languages' compilers.

jchw 8y ago
Disagree. The TypeScript compiler is quite fast even on large projects. Build systems that are unable to properly parallelize builds are common in the JS world these days so you are probably experiencing tsc much slower than it is. That said, Babel now supports TypeScript so you should get nearly the same performance with TypeScript as you did with Flow or even just plain ES transpilation. That way you can do typechecking as a separate step like you would have done with Flow.
- mort96 8y ago
  I haven't really ever seriously used flow or babel transpilation. My experience with compiled languages is mostly gcc which has initialized and started compiling in microseconds, or just writing plain JS which doesn't need transpilation. "Nearly the same performance as Flow/ES in Babel" isn't the benchmark I use.
  - jchw 8y ago
    Apples to oranges. You can use TypeScript without ES* -> ES5/ES3 transpilation. The compilation process may not be as fast as not having one, but it will be similar in speed to running a few sed commands over your source code. GCC startup time is going to be faster than Node.JS startup time, but that's irrelevant. We don't need to restart the compiler on each iteration. You can just use an auto reloader for that. And since we're real developers writing real apps, hello world is not important to us. We want to organize our code into modules and bundle those to a single JS file that is minified in production. So we're going to process the source code one way or another. C++ is a funny example to mention because it scales pretty poorly in the compilation time aspect, because it lacks modules. Compiler startup times are good... But it's not really that fun burning all 16 cores trying to compile Qt and still having it take forever. Compare to Go where compilation is so fast most people don't even talk about compilation speed. All languages compile eventually anyways, even JS. It just compiles in the browser. If you really want a "zero compilation step" experience, you can just load the TypeScript compiler directly in the browser. It's been done in the past for demos.

wanted2 8y ago

> , and to everyone's benefit. Why? I've worked on large codebases in Coffeescript, ES6 and Typescript. Whatever this whole community sings and believes, but Coffeescript still wins for me. ES6 is still trying to catch up but will probably never reach the beauty and ease of Coffeescript. Both are transpilers, only ES6 with Babel is a total horror to manage (just upgraded a large codebase to Babel 7..). Typescript takes about 2x the time to write if you want to create all your typings properly. I hear you say; only in the beginning, later it will speed up the development process. I've never seen that in reality! I've actually never seen a proper codebase in Typescript. Show me a Typescript codebase not using the type 'any'! In a decent system language you can't get away with that, it's just a fake sense of security. A good codebase should not be dependant at all by Typescript or whatever hype comes next. Writing a good codebase is IMHO a craft and should not depend on the language or a bunch of tooling. If Typescript is way to go, what about Python, Ruby, abandon it, deprecated? Are those inferior languages compared to Typescript? Typescript is just another hype, very smart play by Microsoft btw.

ex3ndr 8y ago
We are doing backend and frontend in Typescript and have very limited 'any' usage. Mostly for some hacky library for some small isolated need. I can the same way cast value to an Object in Java of NSObject in Swift.
yaseer 8y ago
There are multiple benefits from having TypeScript a clear winner. 1. One standard typed version of JS (As appose to flow and TypeScript) is a better use of open-source developer time. It also reduces decision fatigue when architecturing new JS projects. 2. TypeScript tooling is fantastic. Using VSCode or Webstorm spoils you. 3. TypeScript is a testing ground for experimental language features. It can shape the direction of future versions of JS. 4. Finally, the language is clearly well liked, in addition to being popular. We can debate the pros and cons of its quirks, but overall, the stats say developer satisfaction is high. https://hub.packtpub.com/4-key-findings-from-the-state-of-javascript-2018-developer-survey/ https://hub.packtpub.com/4-key-findings-from-the-state-of-ja...
ng12 8y ago

Waterluvian 8y ago

I agree with your sentiment but I find the location of it almost ironic. One thing I hate is when I go into a language and it's full of, "oh don't use the built-in, use this thing over here...". If we want a clear winner to everyone's benefit, wouldn't we want Yarn to go away and for npm to gain whatever it's missing that makes Yarn relevant? To be fair, I haven't touched Yarn in years. I switched to it, loved it, and then npm got the package-lock and some performance fixes and I suddenly didn't understand why I'd want to use Yarn. I'm conflicted because on one hand I strongly believe that we're all better off using the same tools so we can help each other more easily. But that suggests that alternatives shouldn't exist, which stymies innovation.

s_tec 8y ago
I get what you are saying, but the two cases are different. Typescript is a whole different language from Flow, so they can't interoperate. Every package that migrates to Typescript deprives the Flow ecosystem of compatibility and mindshare, so a win for one is always a loss for the other. Nobody wants to be a loser, so this will eventually resolve itself into a single dominant choice. NPM and Yarn don't have this problem, since they are pretty much drop-in replacements for each other. As long as `yarn install` and `npm install` both get the job done equally well, picking one becomes a personal choice. Every project that adopts a standard package.json is a win for both NPM and Yarn. There doesn't need to be a loser in this case, and diversity is good.
- Waterluvian 8y ago
  That's a really good point. Thanks for sharing. Drop in alternatives can be healthy and not that harmful. It's not like we are locked into two separate camps.