3 ms·

My main issue with the term "transpiler" is not its existence per se. It is the effect that its existence has on a large portion of developers, having them reje

by sjrd 9y ago

My main issue with the term "transpiler" is not its existence per se. It is the effect that its existence has on a large portion of developers, having them reject some kinds of technologies for the wrong reasons. If we look back to when the term "transpiler" was made popular (not necessarily coined), it is fairly widely acknowledged that it was through CoffeeScript, which defined itself as such. In a sense, I think CoffeeScript was right (or at least not wrong) to define itself as "transpiler" rather than "compiler". After all, it was a syntax tree to syntax tree transformation, technically involving no more than a parser and a pretty-printer (not saying there's anything wrong with that). However, because CoffeeScript was the first language to compile to JavaScript, swaths of developers have associated the term "transpiler" to "compiles to JS" or "compiles to another language that also happens to be used as source language". Now, all these developers will systematically refuse to call TypeScript, ClojureScript, Scala.js, etc. as "true compilers" (let me list a few more in alphabetical orther so I'm not perceived as totally biased: BuckleScript, Elm, Flow, Kotlin, PureScript). Instead they insist on calling them "transpilers" and associating their characteristics to that of CoffeeScript. Now that CoffeeScript is falling out of favor (in part because most of what it brought to the table has been picked up by ES2015), this category of developers associates any kind of language that compiles to JS as a thing that no one would ever want to use. Worse, they will often consider such languages as insults to their craft. "Why don't you just learn JavaScript and code in it?", they ask. This is a cultural problem, because this mindset prevents from even considering what other languages can bring to them. Technologically speaking, there is absolutely nothing separating ClojureScript/Scala.js from Clojure/Scala. The former compile to JavaScript; the latter to JVM bytecode; but the amount of compiler engineering that go into all these compilers is basically the same. However, somehow, culturally, they are fundamentally different: ClojureScript/Scala.js devs should just learn JavaScript, while it's OK for Clojure/Scala devs not to "learn Java". In the end, the existence of the term "transpiler" has a negative effect on the perception that many developers have on the quality of languages that compile to JS. You will often read things like "such transpilers always leak JavaScript in the end", which is simply not true for ClojureScript and Scala.js. Or "interop with JS libraries is always an issue with transpilers"; again, not true. And those misconceptions make them reject and bash on similar technologies, for no good reason. And that is why I loathe the term "transpiler".

ovao 9y ago
In the end, the existence of the term "transpiler" has a negative effect on the perception that many developers have on the quality of languages that compile to JS. Is this actually true? Have there been actual widespread complaints about, say, TypeScript's quality because CofeeScript was labeled similarly?
- sjrd 9y ago
  Fair enough. I think TypeScript enjoys some "protection" from the obvious complaints because it advertises itself as (and it is) "just JavaScript", with types. Therefore the complaints I often see about other languages compiling to JS are kind of moot or very easy to dismiss. For example "it eventually leaks JS" is dismissed as "yeah, duh! it is JS". TBH I do not have too much contact with TS other than its type definitions, so the experience I describe may not be relevant to TypeScript. I have repeatedly seen it for languages that provide a different set of abstractions than JS, though.
- kitten_mittens_ 9y ago
  The post you're responding to is probably referring to languages that are further afield from JavaScript than Typescript (or coffeescript). After wrestling to get get purescript code within a factor of four difference between IE 11 and modern Chrome, I think the suspicion a lot of folks with a background in JS have for "compiled" v. "transpiled" is well deserved. Just because you target a runtime doesn't mean the nuts and bolts of ergonomics like existing library usage, profiling, and debugging are covered well.

by sjrd 9y ago

ovao 9y ago

In the end, the existence of the term "transpiler" has a negative effect on the perception that many developers have on the quality of languages that compile to JS. Is this actually true? Have there been actual widespread complaints about, say, TypeScript's quality because CofeeScript was labeled similarly?

sjrd 9y ago
Fair enough. I think TypeScript enjoys some "protection" from the obvious complaints because it advertises itself as (and it is) "just JavaScript", with types. Therefore the complaints I often see about other languages compiling to JS are kind of moot or very easy to dismiss. For example "it eventually leaks JS" is dismissed as "yeah, duh! it is JS". TBH I do not have too much contact with TS other than its type definitions, so the experience I describe may not be relevant to TypeScript. I have repeatedly seen it for languages that provide a different set of abstractions than JS, though.
kitten_mittens_ 9y ago
The post you're responding to is probably referring to languages that are further afield from JavaScript than Typescript (or coffeescript). After wrestling to get get purescript code within a factor of four difference between IE 11 and modern Chrome, I think the suspicion a lot of folks with a background in JS have for "compiled" v. "transpiled" is well deserved. Just because you target a runtime doesn't mean the nuts and bolts of ergonomics like existing library usage, profiling, and debugging are covered well.