The Dangers of Transpiling
Transpiling. Taking code written in one language and translating it to another language of similar abstraction. Some of the most popular languages and libraries these days are transpiled. React, JSX, Scss are all common examples that have gained favor in the past few years. In perhaps the most remarkable example, modern Javascript is being transpiled to itself with the adoption of the EMCAScript 6 (ES6) standard before browsers support it. Packages like Babel quite literally convert new Javascript to current Javascript.
With so many of the core, client web technologies being transpiled, i have gained an intimate knowledge of a number of these tools. And having worked professionally with them i can say, without hesitation, I am done.
Transpiling is a zone killer
The problem, you see, is that transpiling takes time. A lot of time. In my tests on a modest client codebase, roughly 11 seconds per run. Multiply that by the times i change code and refresh site per day. What you find is that i spend around 15-20 minutes per day waiting for my React, ES6 and Scss code to figure out how to execute itself.
But the reality is far longer than those 15 minutes. Each time i have to wait for React or Scss changes to take effect, i am being yanked out of the zone. Instead of staring at my command line, i get distracted by some news post or whatever. I would not be surprised to learn that i lose nearly an hour of productivity every day, directly or indirectly, to the tranpilation process.
Transpiling is an error obfuscator
Another problem i should mention is the near complete obfuscation of errors. You see, when your code is transpiled, the code you release is not the code that you wrote. Stack traces, as you can imagine, lose most of their value. React took it a step further with the ever-so-helpful production exception message:
Error: Minified exception occurred; use the non-minified dev environment for the full error message and additional helpful warnings.
Personally, i always found the word "additional" particularly amusing in this message, as it suggests the inclusion of any helpful data at all. Of course, React is an ES6 library and therefore is transpiled. This means the stack trace is a trail of breadcrumbs as useless as the message itself. Enjoy reproducing this in development for aforementioned additional details.
Transpiling is not for me
I recently wrote an entire post on developer nirvana. The next day, i realized that i should have added a section devoted to simply to avoiding transpiled languages. I might have added it if i didn't feel so passionately about it that it could warrant a post in its own right.
To the critics of these opinions, i should make it explicitly clear that i am not arguing against these libraries themselves. Nearly without exception, coughcoughcoffeescriptcoughcough, these techs have brought some excellent changes to the web dev ecosystem. My complaint is that the ends just don't justify. The ideal stack is one that maximizes maintainability, productivity and developer morale. In every case i have experienced, none of the transiled languages make up for the shortcomings of transpiling.
So to people on the outside, i say stay away. While i may be done with these techs moving forward, removing them from existing projects is not a reasonable use of development time. So to devs debating a swap to a transpiled stack, i urge you to look carefully at the process. Turning back is rarely an easy task.
tl;dr: Many techs, like React and Scss, require transpiling. While these tools may be great, they don't make up for the cons that transpilation brings.
