JavaScript transpilation is a neat trick, but in practice you may seem to simply trade one multifaceted, shifting platform -- what works crossbrowser -- for another -- here, a set of constantly changing hipster libraries.

There are simple solutions to the shifting , each with one major flaw:

  • Target a "lowest common denominator" or "limiting reagent" browser (ie, IE[x]) with "native" JavaScript.
    • This stinks because even IE11's tools are much worse than Chrome's DevTools.
    • Yet if you don't live in your "worst" browser, you're going to miss issues. No, you are. Every time.
  • Pick one set of transpiled technologies & practices, and, within reason, stop.
    • You're still going to have to test in browsers
    • You'll still be responsible for debugging third-party code.
    • You'll disappoint your hipster programmers.

Interpreted incorrectly, transpilation gives the impression that you're developing for an environment like a server: a controlled, homogenous system. You're not. It's not node. And I've yet to see a practical advantage beyond very specific, situated uses -- JSX compilation for React, for example -- provided transpilation. It's all still very familiar zeroes and ones.

Labels: , , ,