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: crockford, javascript, node, transpilation

From Jslint Is Not A Code Quality Tool For 3rd Party Code – Hugh FD Jackson:

Crockford is an opinionated, experienced and charismatic guy. As such people often do, he has gained significant influence. In this post, I’m going to focus on what Crockford thinks the role of JSLint is, as typified by this suggestion:

“There is one reliable, objective metric of JavaScript code quality that can help you in making your choice [… of library …]: JSLint. If JSLint finds problems in a library, then dump it and move on to the next one.”

I firmly believe that this attitude is damaging; and worth focusing on given his potential influence.

Yeah, wow, no. That is bad advice.

As I've said on Stack Overflow before:

As a rule, you should exempt 3rd party libraries from your linting. There's nothing you can do about external libraries unless you want to fork them and lint them yourself, which is, well, insane. ;^) And, again, minified code often takes shortcuts that aren't lint-friendly.

Lint your code before you minify to keep its quality high, but don't worry about QAing libraries you shouldn't be touching anyhow. Assume they have another method for ensuring high quality, which might include using a different linter, or a linter with a different set of rules.

I'm a huge fan of linting your JavaScript code, and there's no more thorough linter for less investment on your part than JSLint. Nothing it forces you do is objectively wrong, and you don't have to worry about getting everyone in a room to set up an ESLint rule set before you get started.

But there's absolutely no reason not to use libraries that aren't themselves lintable in their original. There's a clear interface between you and that code. It's sort of like how RMS wishes you wouldn't use any non-GNU code. A proscription from using non-JSLinted libs is more political than rational.

Labels: code, crockford, ESLint, JSLint, style

... I get an additional error stating Unexpected space before '['.

The only way to get rid of this error is to format the script like this, which I think make it more unreadable:

var showOrHide = 'show';
jQuery('.selector')
 .removeAttr('style')[showOrHide]();

So my question is would it be possible to make the second example not produce an error?

Thanks :)

Labels: communication, crockford, JSLint