The Dark Side Of Transpilers

It's cool when everyone tells us that we can use modern and future ECMAScript features today, right? Well, here the other half of the untold story, the one web developers might not be aware or just wrongly ignore.

What Is A Transpiler

A pre-processor software that converts a non supported syntax into a presumably supported one, polyfilling as example a slightly different programming language, as it is for CoffeeScript, or bringing new features not deployed and not standard and/or fully approved yet to older browsers, as it is for Traceur "ES.next oriented" case.
It's important to understand I am not blaming any specific transpiler in here and these two mentioned one are just famous examples.

Native Source Map Support Or GTFO

As simple as that, if our target browser, and once again I don't mean the one emulated via Chrome dev tools, based on V8, but the real browser with all its quirks based on that exact version of the JS engine that has nothing to do with what's inside our Chrome or Canary, does not support natively source map, we'll never be able to debug anything in a reasonable way. It will be a tedious and blind guessing process about what's going on in there.
This includes any external library that might pollute the original environment with undesired globals, and/or trying to provide meaningful info, without having a real adb live debug, an iOS live debug or a BlackBerry live debug console possibility.
All these non native, platform and browser dependent version, source map bridges aren't that good ... we can feel free to invest time using these though ... however ...

Remember Old IE Simulators? They Are Back!

As silly as it sound, using a single vendor emulator to pretend we are testing all versions of Webkit, Blackberry, Firefox, Windows Phone or webOS out there is the equivalent of pretending that IESimulator ever worked ... while we all know that to test proper IE we need either the real OS with the real IE installed, being strictly related to OS DLLs too, or at least a Virtual Machine snapshot of that OS with that version. Everything else is a lie, period.
Sadly, when we see all those browsers including iOS and iPhone in our devtool emulator, we must be fool to believe that will be the behavior the same browser will have for real.
Just try to imagine that iOS 7 freezes when you scroll while V8 and Chrome keeps firing events like a charm ... while building our next business model on top of this scrolling behavior ...

Possibly Unaware Transpilers

What if the new syntax is transpiled to a not fully compatible JavaScript? Are we going to fix the transpiler then the logic behind then the browser behavior or ... what? How double difficult is to fix a non considered target browser through a transpiler instead of directly feature detect via JS because we know where and what is the problem?
It's like thinking that an assembly issue came out of gcc compiler and we have to fix either the C syntax or the compiler itself ... can we even think about this scenario when we chose a transpiler?

Performance Upside Down

I know this hurts but it's the sad state of reality. New hardware and new software on top with great new features will perform natively as fast as possible these features ... old crappy hardware with already problematic performance issues, as it is for all Android 2 still out there, all IE < 9 browsers out there, all PC still on WinXP and ... you name it ... the moment we have to wrap everything in order to simulate some native Promise, Generator, spread operator, or arrow function to bind them all, when we all know that bound functions are very slow compared to normal one but arrow as a function shortcut it's going to bind everything no matter what, whatever it is it's going to be slower in already slower hardware and not so optimized software.

CSP Pointless Reports

Last but not least, Content Security Policy report will provide completely pointless reports because of some JavaScript generated by some non JavaScript syntax ... if security matters, this is yet another no-go, if not the main one!

About Optimizations

It came out instantly on twitter but this is another myth ... it does not matter if Emscripten compiles 10X faster thanks to asm.js, if our target browser does not support those optimizations and it actually fails with some modern Math method we are doomed. Transpilers need to know the hosting JS env and cannot optimize upfront, that's the reality once again.
This means that even using C as not supported syntax that will be optimized that much, not necessarily we need to write C to go faster .. actually, if the transpiler optimizes for some engine only, others might have worst performance ... but ...

Yeah, Some Browser Will Benefits

As mentioned initially, it's about target browsers. If we are targeting a browser that should support WebGL and asm.js and perform decently showing Unreal Tournament on the screen, there's no need to care about older browsers ... got it?

I Am Not Pushing Back Progress ... But ...

If new developers in 2014 still need to know these obvious things for most of us on the web, maybe they need to chill out with all this use the future now hype because while everything is awesome and interesting and powerful, somebody still have to support people that don't upgrade phones and PCs every year (or 6 months), and a web that would still like to be available by as many people as possible.

Graceful Enhancement

Or polyfills and meaningful libraries that work everywhere, this is my daily mantra when it comes to develop anything that might be useful ... I have no idea how we are supposed to serve different versions of the same modern standard out there. All I know is that slowly, web development is getting better but we cannot abandon web users because we don't care about slow, inefficient, problematic, and not compatible hardware ... we managed to keep alive IE6 for more than 10 years, now between this, which is wrong, and using a prematurely implemented version of ES7 there is an abyss, which represents the road that web development, IMO, should never take.

I believe the web should be similar to a book, no matter how fancy is the cover and images inside, everyone could read it.
That's how I'd like to keep it whenever is possible and reasonable (effort and target browsers speaking, of course).