Hacker News new | comments | show | ask | jobs | submit login

I have never written a line of JS in my life, which hopefully qualifies me as an unbiased outsider, but I don't agree that that Crockford's position here on JSMin is the right thing to do.

Here is what I see:

@fat is not inserting "!" needlessly as a statement separator. The "!" is there for its proper purpose, as a "unary not" operation, which will short circuit the second operand of the "&&" when isActive is false.

Given that, @fat has left out a semicolon in a way that is perfectly legitimate based on this language specification, at least as described in the 5.1 version linked from here: http://inimino.org/~inimino/blog/javascript_semicolons).

Could @fat have written the code differently so that he would have been required to include the ";"? Perhaps -- but I don't see why that counterfactual has any particular bearing here.

Crockford's own page on JSMin <http://www.crockford.com/javascript/jsmin.html>; claims: "JSMin is a filter that omits or modifies some characters. This does not change the behavior of the program that it is minifying."

The fact is that @fat's code is legal code and JSMin is breaking it.

IMHO, Crockford is ignoring the technical matters at hand. @fat cannot be faulted for writing code that complies with the specification and for having a reasonable expectation that code minimizers will preserve the semantics of his legal code. Crockford (and others) may wish that the language specification did not include automatic semicolon insertion because it does hamper making changes in the language without breaking existing code -- but that does not make this piece of code "insanely stupid".

Yes, forward progress on the language would be better served if automatic semicolon insertion rules weren't in the specification. However, calling one particular piece of code that leverages those rules "insanely stupid" and refusing to acknowledge that JSMin is in fact breaking the semantics of the code is not productive. Refusing to fix this in JSMin does not somehow make the problem with the specification to go away.

Here is what you're missing.

Language lawyering is fine and dandy when you know exactly which compiler will be used and you know exactly how it works.

But on the web that isn't the case. You can write code, but you have no control over what browsers, past, present and future, it will get run on. And it is your responsibility to make that work. According to the spec, you may be right. But in practice you're the one who is wrong, because you're the one whose job it is to make your code work across browsers and future versions of the spec.

Crockford is releasing a tool which is compatible with his opinions, not with JavaScript. All browsers execute that code fine, present and past, and at least for the next decade or so.

Crockford can be an arrogant ass about this stuff, that's why jshint exists, because not agreeing with Crockford does not mean bad JavaScript, no matter what he would have you believe

It's about JSMin, not JSLint. Crockford has actually several products ;-) And JSMin is IMHO not really opinionated.

In this case, it's not language lawyering. All JavaScript environments "do the right thing" with regards to ASI -- it works in all target environments as of the present day. JSMin is not a target environment, it is a minifier that happens to express some strongly-held opinions of its author.

That said, it's hard to program to a spec that does not (officially) exist yet, and doubly so if there's not clear "opt-in/out" path for future versions. Since, as a developer, I can't control what the committee adds or removes from the spec, or what they might break, I can only do the best I can with the language as it is -- not breaking existing code in future versions of the language is the committee's job.

If JSMin is not among their target environments, they should not use it.

The code in question does work across browsers.

Arguing about future version of the spec is silly. For all we know the next Javascript spec turns it into a Lisp, and 100% of existing code is broken.

JSMin is breaking working, spec compliant, cross browser compatible code. How is that not broken?

Applications are open for YC Summer 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact