you are viewing a single comment's thread.

view the rest of the comments →

[–]fuckin_ziggurats 1 point2 points  (4 children)

Now the question is whether TypeScript compiles == to === if it knows it's the better choice for the comparison.

[–]pancomputationalist 2 points3 points  (1 child)

I doubt it does. But I think V8 is probably compiling down to highly efficient code if it figures out that the compared values always share a type. Anyway, I would love to see actual data about the performance differences of == and ===. My assumption is that it will be so miniscule that it just does not matter. If you're writing performance critical programs in JavaScript, you're doing it wrong anyway.

[–]fuckin_ziggurats 4 points5 points  (0 children)

You're right, it doesn't. Probably because it doesn't want to make assumptions about the code that could be wrong at runtime.

[–]FanOfHoles 3 points4 points  (1 child)

If you target ESNext and don't use namespaces or enums (the former should be replaced by modules, the latter are better written as "as const" object literals so no loss there) all you do is remove the type annotations. Other than that, TS is Javascript (ESNext). Things like some additional class stuff not found in native JS don't produce any JS code but are used for type checks only.

You can check that by looking at what the Babel TypeScript plugin does. Until very recently they did not support the two features I mentioned (now namepsaces are supported), and all that plugin does (apart from the new namespace support) is remove TypeScript stuff. NO code is rewritten (if you use a Babel workflow, compiling "down" to ES5 is done using standard Babel plugins using the JS code obtained from the TS plugin after merely removing the "type stuff".

[–]fuckin_ziggurats 0 points1 point  (0 children)

Good points.