Hacker News Reader

Comment by grumpy8 | Hacker News Reader

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".

View on HN

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

>> in the end, it's still javascript

This is exactly the reason I prefer Reason. :)

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.

ReasonML is also just Javascript in the end, dealing with the same platform limitations.

This is like saying Rust is just x86 assembler

The more high-level the target, the more that target bleeds through and the more you have to deal with it.

Certainly not; see for instance asm.js. Arbitrary C++ (or any other LLVM language) can be translated into JS this way.

Except wasm isn't JS. It's yet another vm in the browser.

You're right; I mean asm.js. Point stands. You can compile arbitrary languages into JS without the "js" part leaking through.

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.

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.

And?

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.

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.

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.)

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

Reply on news.ycombinator.com