“Transpile” is a proper subset of “compile”, where both the source and target of compilation are languages designed primarily for direct human editing (source code); it is source-to-source compilation.
Using the term for anything where the source is JVM bytecode is plain wrong, and it's also dubious for anything targeting WebAssembly (though if the target is specifically .wat/.wast, it may perhaps be arguably defensible.)
there existed "translators" from one asm variant to another in the past. [0][1]
so i guess one might use "transpile" wrt bytecode in the spirit of that. but i guess asm source files are still "human readable", where bytecode generally isn't considered as such.
I think it's pretty clear that "transpile" is a subset of "compile" and that there are both examples of "compile" that are indisputably not "transpile" (plain old source to architecture specific binary) and examples of "compile" that anybody who uses the term "transpile" would include in their personal variety of "transpile" (translation between source formats that are commonly used for human written code).
I don't see why the existence of a grey area should be enough to question the utility of the term.
If compile/decompile are used for a transformations along one axis, transpile is used for transformations that are predominantly orthogonal to that axis.
At the time of this reply, there are at least five competing definitions being argued for and against in this thread; some either requiring that the input and output be machine code or disallowing it, some necessitating that both input and output be at "the same level of abstraction" and others arguing that inputs and output can be at different levels of abstraction.
Given the large inconsistency and incompatibility between all these definitions and the existence of a well-accepted term that comprises all of these definitions, is it a mystery why people question the utility of the term? After all, what use is a nuanced term if it can't reliably convey that additional information.
>After all, what use is a nuanced term if it can't reliably convey that additional information.
I would recommend the general term "A/B compiler" where A and B are arbitrary regular languages. That way it would be pretty clear what a Pascal/C compiler is, or a JVM/Webasm compiler, for instance. Or a x86/C compiler which would also make the word "decompiler" obsolete.
Using the term for anything where the source is JVM bytecode is plain wrong, and it's also dubious for anything targeting WebAssembly (though if the target is specifically .wat/.wast, it may perhaps be arguably defensible.)