4 ms·

I can't think of any downsides of an optional type checker. Can you? Just curious if there's an argument I hadn't heard before.

by ssmoot 10y ago

softawre 10y ago
If it's TypeScript versus pure JavaScript (not versus Babel), there's a transpile time hit you must consider.
- WorldMaker 10y ago
  Pure (vanilla) JavaScript will remain a bit of a rare unicorn in large projects, though, at least until HTTP/2 and maybe even after HTTP/2 for whatever other reasons [1]. Just about every large project has a bundler and/or minifier step and the Typescript transpilation fits right in there, instead of in the browser. [1] People will always still want to shave bandwidth, and the new hotness is Tree Shakers which shave bandwidth and computation/JIT time for the browser...
  - Touche 10y ago
    Just about every large project has a bundler step for production. Many have for dev as well, but this is unequivocally an undesirable thing. You can't beat Refresh for dev workflows.
    - WorldMaker 10y ago
      In dev workflows you can deal with the extra few milliseconds of transpilation time just like you deal with the extra few milliseconds of overhead from any of your other dev tools. Plus, even a bunch of dev workflows are increasingly using tools like gulp-watch in the background of their refresh cycle (for whatever reasons), and Typescript's watch support has gotten very good.
      - Touche 10y ago
        You can "deal with" a lot of things, but that doesn't make them desirable. It's not like the community has evolved towards build scripts because build scripts are great, it evolved in that direction because the ecosystem has changed faster than the web has been able to keep up. Once the web catches up on the module front you'll definitely see the refresh workflow regain some lost popularity.
        WorldMaker 10y ago
        Maybe? There's always an "ES Next" in the evergreen world. There's always some feature you might want to use today that a build tool makes accessible that otherwise you'd wait months/years for browser support to "catch up". The goal posts will keep moving, especially now that TC39 is working on an "agile" yearly spec release cycle. After modules there's async/await and after that there's plenty more future to discover...
    - Keats 10y ago
      I'd say live reload beats refresh for dev workflows (when it works).
bcoates 10y ago
Same problems with linters: people write weird code and/or introduce unnecessary changes to correct code that doesn't pass the check. Also, optional type checkers throw away a lot of the upsides of type systems (safe refactoring, type-aware optimizations, useful generics) so they're kind of a worst-of-both-worlds solution.
- mercurial 10y ago
  > Same problems with linters: people write weird code and/or introduce unnecessary changes to correct code that doesn't pass the check. Having just converted a bunch of pure Javascript to Typescript, and writing new code in Typescript, this hasn't been an issue. > Also, optional type checkers throw away a lot of the upsides of type systems (safe refactoring, type-aware optimizations, useful generics) so they're kind of a worst-of-both-worlds solution. I'm not sure what you mean by "throwing away safe refactoring" but yeah, you don't get the performance benefits or reified generics (not that it's particularly useful). That said, it's not like you derive any performance benefit from Java generics either.

I can't think of any downsides of an optional type checker. Can you? Just curious if there's an argument I hadn't heard before.

by ssmoot 10y ago

I can't think of any downsides of an optional type checker. Can you? Just curious if there's an argument I hadn't heard before.

softawre 10y ago

If it's TypeScript versus pure JavaScript (not versus Babel), there's a transpile time hit you must consider.

WorldMaker 10y ago
Pure (vanilla) JavaScript will remain a bit of a rare unicorn in large projects, though, at least until HTTP/2 and maybe even after HTTP/2 for whatever other reasons [1]. Just about every large project has a bundler and/or minifier step and the Typescript transpilation fits right in there, instead of in the browser. [1] People will always still want to shave bandwidth, and the new hotness is Tree Shakers which shave bandwidth and computation/JIT time for the browser...
- Touche 10y ago
  Just about every large project has a bundler step for production. Many have for dev as well, but this is unequivocally an undesirable thing. You can't beat Refresh for dev workflows.
  - WorldMaker 10y ago
    In dev workflows you can deal with the extra few milliseconds of transpilation time just like you deal with the extra few milliseconds of overhead from any of your other dev tools. Plus, even a bunch of dev workflows are increasingly using tools like gulp-watch in the background of their refresh cycle (for whatever reasons), and Typescript's watch support has gotten very good.
    - Touche 10y ago
      You can "deal with" a lot of things, but that doesn't make them desirable. It's not like the community has evolved towards build scripts because build scripts are great, it evolved in that direction because the ecosystem has changed faster than the web has been able to keep up. Once the web catches up on the module front you'll definitely see the refresh workflow regain some lost popularity.
      - WorldMaker 10y ago
        Maybe? There's always an "ES Next" in the evergreen world. There's always some feature you might want to use today that a build tool makes accessible that otherwise you'd wait months/years for browser support to "catch up". The goal posts will keep moving, especially now that TC39 is working on an "agile" yearly spec release cycle. After modules there's async/await and after that there's plenty more future to discover...
  - Keats 10y ago
    I'd say live reload beats refresh for dev workflows (when it works).

bcoates 10y ago

Same problems with linters: people write weird code and/or introduce unnecessary changes to correct code that doesn't pass the check. Also, optional type checkers throw away a lot of the upsides of type systems (safe refactoring, type-aware optimizations, useful generics) so they're kind of a worst-of-both-worlds solution.

mercurial 10y ago
> Same problems with linters: people write weird code and/or introduce unnecessary changes to correct code that doesn't pass the check. Having just converted a bunch of pure Javascript to Typescript, and writing new code in Typescript, this hasn't been an issue. > Also, optional type checkers throw away a lot of the upsides of type systems (safe refactoring, type-aware optimizations, useful generics) so they're kind of a worst-of-both-worlds solution. I'm not sure what you mean by "throwing away safe refactoring" but yeah, you don't get the performance benefits or reified generics (not that it's particularly useful). That said, it's not like you derive any performance benefit from Java generics either.