4 ms·

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.
- 7y ago
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.

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.
7y ago

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.