4 ms·

Why start this from scratch ? Why not build on top of TypeScript ? I get the single pass rationale but isn't it possible to integrate a bundler into TypeScript

Why start this from scratch ? Why not build on top of TypeScript ? I get the single pass rationale but isn't it possible to integrate a bundler into TypeScript compiler ? I'm just wondering because Microsoft has a decently sized team of paid engineers working on TS for years now - what are the odds an OSS project outperforms them at implementing their own language (which they also evolve with every release)

wolfgang42 6y ago
The TypeScript compiler API[1] is beta, underdocumented, and not really designed to support use-cases other than working with an abstract AST. It’s OK for transpiling, but would be a bit awkward for writing a linter and not at all suitable for a formatter. As an example of the sort of problems you might run into with the API in its current state, trying to parse and then pretty-print code can cause comments to vanish[2] under certain circumstances. This is fine for transpiling, but is a major issue when you’re trying to prettify and overwrite the original source file. [1] https://github.com/Microsoft/TypeScript/wiki/Using-the-Compiler-API https://github.com/Microsoft/TypeScript/wiki/Using-the-Compi... [2] https://github.com/microsoft/TypeScript/issues/39620 https://github.com/microsoft/TypeScript/issues/39620
- rubber_duck 6y ago
  I get that - but since TS is also OSS you can fork and upstream, still sounds like less work than writing everything from scratch.
  - wolfgang42 6y ago
    Sure, but they may well have looked at the state of it and concluded that it would need to be rewritten to get it to do what they needed—in which case doing that in a new project is actually less effort, since you don’t need to support the existing uses. (I agree it’d be interesting to hear from the creators, since this is a somewhat unusual result.)
  - rmthw 6y ago
    Why? TS and Rome architectural goals are completely incompatible. Writing a transpiler is not complicated at all, especially for someone who has written Babel in the past. On the other hand, if you familiarise yourself with both TS's gigantic codebase and with Rome's goals, you'll quickly see that modifying TS would be much vaster undertaking than writing it from scratch. Also if Rome were just an also-ran to replace ESLint/Webpack/Babel/etc, it would be ok to have a less-than-ideal starting point, but it's actually trying to do things differently: better error messages, recoverable parser errors, more fixable linter messages, being faster. This is the exact case of something that should be written from scratch (or at least use something that makes it possible) rather than building on some another technology with completely incompatible goals. Another example? It took several years for Webpack to achieve tree-shaking that was as good as Rollup first versions, even with more maintainers, more sponsorship and a lot of time. Why? Because Webpack's architecture was completely different.
    - rubber_duck 6y ago
      But you're basically trying to superset the TS compiler. If this doesn't cover TS typechecking then it fails on it's promise of a single pass compiler stack. Are you suggesting that TS team is so incompetent or legacy burdened that their codebase is impossible to extend. What use case of TS would you exclude to arrive at simpler code base ? Writing a transpiler that ignores type checks is probably simple but also quite useless for dev workflow - if I need to run a separate type checker might as well run a separate linter and compiler, the tech is established.
      - brundolf 6y ago
        The TypeScript plugin for Babel already works this way: it strips out the type annotations to make the code understandable to plain JS interpreters, nothing more. Most people do their type checking through their editor or some other tooling. The coupling of building and checking in a single step, in the case of a dynamic language, is really just a matter of convenience for the implementers (as well as historical tradition). Unlike C, in TypeScript type information is not actually needed to output runnable code.
constexpr 6y ago
I think the odds are pretty good. The TypeScript compiler's performance is not optimal: https://twitter.com/evanwallace/status/1275945317045657602 https://twitter.com/evanwallace/status/1275945317045657602. Microsoft's TypeScript team has a lot of priorities and other things likely take precedence over performance work. Also it's pretty trivial to build a faster compiler if you don't have to worry about type checking. You can still have type checking with a bundler that ignores types by running the official TypeScript type checker in parallel with your bundler.
- rubber_duck 6y ago
  But without typechecking I still have to run a separate tool during development (which is where single pass performance matters the most me) - so suddenly it's not a single parse all-in-one solution.
rk06 6y ago
>what are the odds an OSS project outperforms them at implementing their own language? A lot more than you imagine. Esbuild can already transpile 100x faster than typescript.(Note: esbuild does not typecheck). If they use similar technique as esbuild, they can easily surpass typescript compiler in all functional areas
- atom_arranger 6y ago
  esbuild does not type check. TypeScript type checks and then emits code. Better performance can be achieved by just stripping types and emitting code. It would be great to improve the performance of type checking, but that’s more complicated. Some project are trying, the Deno maintainers have asserted that TypeScript should be rewritten in Rust for better performance. swc is trying to do that - https://github.com/swc-project/swc/issues/571 https://github.com/swc-project/swc/issues/571

wolfgang42 6y ago

The TypeScript compiler API[1] is beta, underdocumented, and not really designed to support use-cases other than working with an abstract AST. It’s OK for transpiling, but would be a bit awkward for writing a linter and not at all suitable for a formatter. As an example of the sort of problems you might run into with the API in its current state, trying to parse and then pretty-print code can cause comments to vanish[2] under certain circumstances. This is fine for transpiling, but is a major issue when you’re trying to prettify and overwrite the original source file. [1] https://github.com/Microsoft/TypeScript/wiki/Using-the-Compiler-API https://github.com/Microsoft/TypeScript/wiki/Using-the-Compi... [2] https://github.com/microsoft/TypeScript/issues/39620 https://github.com/microsoft/TypeScript/issues/39620

rubber_duck 6y ago
I get that - but since TS is also OSS you can fork and upstream, still sounds like less work than writing everything from scratch.
- wolfgang42 6y ago
  Sure, but they may well have looked at the state of it and concluded that it would need to be rewritten to get it to do what they needed—in which case doing that in a new project is actually less effort, since you don’t need to support the existing uses. (I agree it’d be interesting to hear from the creators, since this is a somewhat unusual result.)
- rmthw 6y ago
  Why? TS and Rome architectural goals are completely incompatible. Writing a transpiler is not complicated at all, especially for someone who has written Babel in the past. On the other hand, if you familiarise yourself with both TS's gigantic codebase and with Rome's goals, you'll quickly see that modifying TS would be much vaster undertaking than writing it from scratch. Also if Rome were just an also-ran to replace ESLint/Webpack/Babel/etc, it would be ok to have a less-than-ideal starting point, but it's actually trying to do things differently: better error messages, recoverable parser errors, more fixable linter messages, being faster. This is the exact case of something that should be written from scratch (or at least use something that makes it possible) rather than building on some another technology with completely incompatible goals. Another example? It took several years for Webpack to achieve tree-shaking that was as good as Rollup first versions, even with more maintainers, more sponsorship and a lot of time. Why? Because Webpack's architecture was completely different.
  - rubber_duck 6y ago
    But you're basically trying to superset the TS compiler. If this doesn't cover TS typechecking then it fails on it's promise of a single pass compiler stack. Are you suggesting that TS team is so incompetent or legacy burdened that their codebase is impossible to extend. What use case of TS would you exclude to arrive at simpler code base ? Writing a transpiler that ignores type checks is probably simple but also quite useless for dev workflow - if I need to run a separate type checker might as well run a separate linter and compiler, the tech is established.
    - brundolf 6y ago
      The TypeScript plugin for Babel already works this way: it strips out the type annotations to make the code understandable to plain JS interpreters, nothing more. Most people do their type checking through their editor or some other tooling. The coupling of building and checking in a single step, in the case of a dynamic language, is really just a matter of convenience for the implementers (as well as historical tradition). Unlike C, in TypeScript type information is not actually needed to output runnable code.

constexpr 6y ago

I think the odds are pretty good. The TypeScript compiler's performance is not optimal: https://twitter.com/evanwallace/status/1275945317045657602 https://twitter.com/evanwallace/status/1275945317045657602. Microsoft's TypeScript team has a lot of priorities and other things likely take precedence over performance work. Also it's pretty trivial to build a faster compiler if you don't have to worry about type checking. You can still have type checking with a bundler that ignores types by running the official TypeScript type checker in parallel with your bundler.

rubber_duck 6y ago
But without typechecking I still have to run a separate tool during development (which is where single pass performance matters the most me) - so suddenly it's not a single parse all-in-one solution.

rk06 6y ago

>what are the odds an OSS project outperforms them at implementing their own language? A lot more than you imagine. Esbuild can already transpile 100x faster than typescript.(Note: esbuild does not typecheck). If they use similar technique as esbuild, they can easily surpass typescript compiler in all functional areas

atom_arranger 6y ago
esbuild does not type check. TypeScript type checks and then emits code. Better performance can be achieved by just stripping types and emitting code. It would be great to improve the performance of type checking, but that’s more complicated. Some project are trying, the Deno maintainers have asserted that TypeScript should be rewritten in Rust for better performance. swc is trying to do that - https://github.com/swc-project/swc/issues/571 https://github.com/swc-project/swc/issues/571