181–190 of 224 posts
Earlier quoted context omitted.
Few people truly understand the semantics of a language, but everyone knows why indexing from 1 is bad.
... that is, for some values of "everyone" ;)
Earlier quoted context omitted.
I wonder when bug tracking sites are going to block reddit referrers (or just prevent them from posting). I've seen this before in comments to PHP bugs and bugzilla bugs.
I disagree. Imho a little infantile humor in places where it "doesn't belong" can be quite refreshing - as long as it remains the exception rather than the rule. People tend to have pretty stiff sticks up their arses in such discussions. Humor, even toilet humor, can remove fear and remind everyone that a debate over a semicolon is not necessarily a life/death situation.
Sounds like another emotional issue.
1) JSmin should be modified to handle Bootstrap-style semi-colon-ing
2) Bootstrap should adopt the more commonly understood semi-colon-ing
I am not experienced with javascript, so I don't understand this argument. Can someone please confirm the following, or explain what's going on? Here is what I understand: 1. Javascript will add a phantom semicolon at the end of each line if it seems like you need it, for some definition of seems like. To me, it sounds like this is so that new HTML writers in '98 wouldn't see their pages blow up when they forgot a se…
http://blog.izs.me/post/2353458699/an-open-letter-to-javascr... That is a pretty good rundown of the rules. The only problem with not having semicolons is cases like this, where someone is using a bad tool to minify your code. None of the tools that currently do the best job will break on that code.
But I still don't understand why the hell you would want to do this. These are a lot of rules to remember, and I don't think it makes sense to think about them for each statement I write. Nothing here says "here is what you gain with this technique", all I see is "it's perfectly valid so quit whining". This doesn't satisfy my curiosity.
Then we have this:
For example, instead of this:
foo();
[1,2,3].forEach(bar);
foo()
;[1,2,3].forEach(bar)
So now the argument is "don't worry, you get used to writing stupid looking code"? This is getting depressing.
The bootstrap code makes assumptions about the future of the js spec and browser implementations that aren't safe. Young people don't remember the dark days of people writing js to leverage IE/Netscape specific bugs which then had to be turned into features because so much code existed in the wild that could be broken.
Crockford is a scarred veteran of the spec wars. I'm sure that when he sees young people trying to game spec/implementation ambiguities, he thinks, "Never again! Not on my watch!"
I think best practice is explicit, future-proofed code that doesn't tie the hands of spec authors or browser vendors. I know that Crockford's tool doesn't accept the current spec or browser behaviour, but his choice is informed by past experience and concern for the future. It's not just some random bug that he's too stupid or stubborn to fix.
Earlier quoted context omitted.
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.…
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 wh…
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?
There's something horribly wrong with everything about this. Why is such a smart person as Crockford wasting his time arguing about semicolons in 2012? Why is this at the top of the most popular hacker website? Why are people writing detailed opinions about semicolons in this thread (with surely more to come?) One would hope that at least over time the bike sheds being argued about would start to at least evolve into…
While whether or not to use them when designing a language is bikeshedding, JavaScript already has so pitfalls caused by semicolon insertion, their use is a must.
>>>
@douglascrockford If TC-39 makes ! an infix operator, which causes \n to not terminate the statement, then that will be a syntax change that is incompatible with current code in the wild, which would be an insanely stupid move on their part.
The fact of the matter is that JSMin isn't parsing JavaScript correctly. I thought the separation of concerns was that JSLint tells you about stupid code, and JSMin correctly parses JavaScript according to the ES standard and minifies it safely.
>>>