5 ms·

IMHO the biggest reason to use TypeScript rather than Reason is because, in the end, it's still javascript and it stays within the same ecosystem. As great as R

IMHO the biggest reason to use TypeScript rather than Reason is because, in the end, it's still javascript and it stays within the same ecosystem. As great as Reason is, it's adding too many dependencies. The only time I'd go with Reason instead of Typescript is if the developers on the team are already proficient with OCaml. It's going back to the "Use boring technologies even though some things suck as it's better to deal with known issues than unknown issues; the grass isn't always greener with new technologies, just different things that suck".

StreamBright 7y ago
>> in the end, it's still javascript This is exactly the reason I prefer Reason. :)
- gridlockd 7y ago
  ReasonML is also just Javascript in the end, dealing with the same platform limitations.
  - s_y_n_t_a_x 7y ago
    You can rename a JS file to a TS extension and it's TypeScript. The annotations are replaced with whitespace when JS is generated, it doesn't result in different code.
    - gridlockd 7y ago
      Being as close as possible to JS for transpilation is a design goal of Typescript, but the compiler still does more than just strip away the types if you use certain language features. If it was just about stripping away types, then there wouldn't be a need for a compiler and the type checker could be a separate program.
      - WorldMaker 7y ago
        You can already run Typescript type checker separately from a type stripper today, though. Typescript has babel plugins for exactly that. Almost all webpack best practices for Typescript involve the fork-ts-type-checker plugin, running type checks in a separate thread from the transpile phase. At this point almost all of what Typescript compiles (transpiles) that isn't just "type stripping" is some form of downleveling from current ES standards to older ES versions and is almost all entirely optional. There's also nothing stopping you from leaving it all to Babel to do it instead of having Typescript do it, if you wish. (Though personally, I think Typescript is a lot lighter weight a solution than most Babel presets and tslib (the optional dynamic link version of the inline downlevel helper functions TS emits) is a lot smaller than Babel's equivalents in core-js.)
  - dymk 7y ago
    This is like saying Rust is just x86 assembler
    - wvenable 7y ago
      The more high-level the target, the more that target bleeds through and the more you have to deal with it.
      - dymk 7y ago
        Certainly not; see for instance asm.js. Arbitrary C++ (or any other LLVM language) can be translated into JS this way.
        ori_b 7y ago
        Except wasm isn't JS. It's yet another vm in the browser.
        dymk 7y ago
        You're right; I mean asm.js. Point stands. You can compile arbitrary languages into JS without the "js" part leaking through.
        wvenable 7y ago
        I don't think this refutes my original point. Asm.js is exactly a low-level subset of JavaScript. ReasonML doesn't compile to Asm.js. Most languages that compile to JavaScript also want to interop with JavaScript APIs and other high-level JavaScript code. Other posts in topic discuss this exact difficulty of combining ReasonML with the JS ecosystem.
        gridlockd 7y ago
        The JS part definitely leaks through even with asm.js, particularly the lack of native 64-bit integers. The further away you go from Javascript, the more performance issues you encounter and the larger your build size becomes. Of course in theory nothing stops you from having an entire turing-complete VM inside JS, but that's not what you want for real deployments.
  - ernst_klim 7y ago
    > ReasonML is also just Javascript in the end It's not, it's a mere syntax rewriter for OCaml. OCaml has default native target, bytecode target, and two JS transpilers.
- hermanradtke 7y ago
  TypeScript interops with JavaScript much easier than ReasonML. I can’t stand BuckleScript and all the work required to interop with the rest of the JS ecosystem.
robbrit 7y ago
> it's still javascript This is exactly the reason why Typescript took off and none of the other compile-to-JS languages did (other than a brief flash by CoffeeScript). Dart had a very similar problem as Reason - it wasn't Javascript. The interop between Dart and JS libraries was just too much of a pain to deal with, where in Typescript everything just worked. Since building your own ecosystem that rivals the JS ecosystem for libraries is an extremely difficult task, any candidate to replace JS must have good interop with its libraries to be successful.

StreamBright 7y ago

>> in the end, it's still javascript This is exactly the reason I prefer Reason. :)

gridlockd 7y ago
ReasonML is also just Javascript in the end, dealing with the same platform limitations.
- s_y_n_t_a_x 7y ago
  You can rename a JS file to a TS extension and it's TypeScript. The annotations are replaced with whitespace when JS is generated, it doesn't result in different code.
  - gridlockd 7y ago
    Being as close as possible to JS for transpilation is a design goal of Typescript, but the compiler still does more than just strip away the types if you use certain language features. If it was just about stripping away types, then there wouldn't be a need for a compiler and the type checker could be a separate program.
    - WorldMaker 7y ago
      You can already run Typescript type checker separately from a type stripper today, though. Typescript has babel plugins for exactly that. Almost all webpack best practices for Typescript involve the fork-ts-type-checker plugin, running type checks in a separate thread from the transpile phase. At this point almost all of what Typescript compiles (transpiles) that isn't just "type stripping" is some form of downleveling from current ES standards to older ES versions and is almost all entirely optional. There's also nothing stopping you from leaving it all to Babel to do it instead of having Typescript do it, if you wish. (Though personally, I think Typescript is a lot lighter weight a solution than most Babel presets and tslib (the optional dynamic link version of the inline downlevel helper functions TS emits) is a lot smaller than Babel's equivalents in core-js.)
- dymk 7y ago
  This is like saying Rust is just x86 assembler
  - wvenable 7y ago
    The more high-level the target, the more that target bleeds through and the more you have to deal with it.
    - dymk 7y ago
      Certainly not; see for instance asm.js. Arbitrary C++ (or any other LLVM language) can be translated into JS this way.
      - ori_b 7y ago
        Except wasm isn't JS. It's yet another vm in the browser.
        dymk 7y ago
        You're right; I mean asm.js. Point stands. You can compile arbitrary languages into JS without the "js" part leaking through.
        wvenable 7y ago
        I don't think this refutes my original point. Asm.js is exactly a low-level subset of JavaScript. ReasonML doesn't compile to Asm.js. Most languages that compile to JavaScript also want to interop with JavaScript APIs and other high-level JavaScript code. Other posts in topic discuss this exact difficulty of combining ReasonML with the JS ecosystem.
        gridlockd 7y ago
        The JS part definitely leaks through even with asm.js, particularly the lack of native 64-bit integers. The further away you go from Javascript, the more performance issues you encounter and the larger your build size becomes. Of course in theory nothing stops you from having an entire turing-complete VM inside JS, but that's not what you want for real deployments.
- ernst_klim 7y ago
  > ReasonML is also just Javascript in the end It's not, it's a mere syntax rewriter for OCaml. OCaml has default native target, bytecode target, and two JS transpilers.
hermanradtke 7y ago
TypeScript interops with JavaScript much easier than ReasonML. I can’t stand BuckleScript and all the work required to interop with the rest of the JS ecosystem.

robbrit 7y ago

> it's still javascript This is exactly the reason why Typescript took off and none of the other compile-to-JS languages did (other than a brief flash by CoffeeScript). Dart had a very similar problem as Reason - it wasn't Javascript. The interop between Dart and JS libraries was just too much of a pain to deal with, where in Typescript everything just worked. Since building your own ecosystem that rivals the JS ecosystem for libraries is an extremely difficult task, any candidate to replace JS must have good interop with its libraries to be successful.