> it's just within the last 7-10 years I start hearing people use this term
If I recall, the term arose out of the JS community around the time CoffeeScript, Traceur and other languages that compile to JS got popular. Brendan Eich did a lot of popularization of the term.
> IMO adds no actual value.
I think it's a really useful term. Compilers and transpilers are structurally different and have different high level aims.
If you tell me you are writing a language that compiles to JS, then my assumption is that you treat JS as effectively an "assembly language for the web". You will output whatever bizarre JS code that happens to correctly implement your language's semantics efficiently and compactly. It might make my eyes bleed, but that's OK. I'm not supposed to read it, maintain it, or debug it. Think Emscripten or dart2js.
If you tell me you are writing a language that transpiles to JS, then my assumption is that you treat the output JS as a first-class developer artifact. The generated output should, as much as possible, match the structure, formatting, and naming of the original code. I should be able to read it and step through it in my debugger. If the source language's maintainers disappear, I can check in the compiled output and move on with my life using it as vanilla JS. Think CoffeeScript or TypeScript.
Those are very very different kinds of tools, and it's handy to have words to distinguish them.
If I recall, the term arose out of the JS community around the time CoffeeScript, Traceur and other languages that compile to JS got popular. Brendan Eich did a lot of popularization of the term.
> IMO adds no actual value.
I think it's a really useful term. Compilers and transpilers are structurally different and have different high level aims.
If you tell me you are writing a language that compiles to JS, then my assumption is that you treat JS as effectively an "assembly language for the web". You will output whatever bizarre JS code that happens to correctly implement your language's semantics efficiently and compactly. It might make my eyes bleed, but that's OK. I'm not supposed to read it, maintain it, or debug it. Think Emscripten or dart2js.
If you tell me you are writing a language that transpiles to JS, then my assumption is that you treat the output JS as a first-class developer artifact. The generated output should, as much as possible, match the structure, formatting, and naming of the original code. I should be able to read it and step through it in my debugger. If the source language's maintainers disappear, I can check in the compiled output and move on with my life using it as vanilla JS. Think CoffeeScript or TypeScript.
Those are very very different kinds of tools, and it's handy to have words to distinguish them.