[DemocracyFTW2]

If that was the end of the story, no transpiled language could ever succeed. But they sometimes do. One could say the very same about e.g. MarkDown which typically renders as HTML, so you still have to understand HTML to a degree. And in the right environment (e.g GitHub repo readmes) you can always fall back to HTML in places where the transpiler support is lacking.

The great thing about transpilers is when they 1) produce tractable, nicely formatted output and 2) you get an 'escape hatch' so you can fall back on the transpilation target. Because then you can always 1) check the output to understand details of an unfamiliar construct, 2) just use the target language in cases where you want to copy-paste a solution written in the target, and 3) just opt out of using the transpiler by using the code it produced as a starting point for your new implementation.

[progx]

"no transpiled language could ever succeed".... TypeScript.

[orthoxerox]

TypeScript doesn't introduce new runtime semantics in practice, in 99% of the cases the generated JS is your TS code with types erased. There're no magic keywords that expand into pages of generated JS.

[aftbit]

They implemented the `x.y?.z` syntax pretty long before JS did, so that was at least transpiled for a while. I'll bet there are more features like that.

[aabbcc1241]

Similar story for await and iterator

[cerved]

yes but databases are a bit more critical in nature

[Zvez]

not exactly. Just like with the regular code, most of the stuff done on database are pretty trivial and not resource heavy. And the things that are really perfomance-critical are usually crafted very differently even in SQL