5 Things They Told You Not To Use In JavaScript
mir.aculo.us
mir.aculo.us
> A linebreak indicates, in most cases, the end of a statement; a semicolon is automatically inserted for you.
These are weasel words. Either a line break is the end of a statement or it's not. In JavaScript it is not.
> In order to be able to write properly working code, you need to be aware of the rules of Automatic Semicolon Insertion, regardless if you choose to add semicolons at the end of lines or not.
You absolutely do not. I don't care if you use semicolons or not, but don't claim that knowledge of ASI is required to write good JavaScript.
> Fix problems when you actually have them. Use the time you’ve freed up by not prematurely optimizing and spend it with your family or have a holiday on the beach.
Using deprecated features like __proto__ and arguments.callee is not something that you can trivially fix later. These are advanced features and I can't think of an easy why to duplicate their behavior once they are gone. You're going to have to rewrite a significant chunk of your code. Please never, ever use these features in libraries that are shared with other developers.
FTFY
No, actually, that's how it works in JS. ASI doesn't "work" in all cases because a line break doesn't always indicate the end of a statement. No less than Brendan Eich wrote this himself, in his blog post reply to the whole "semicolongate" which happened a couple weeks ago.
I'm sure it feels good to be all righteously angry… but it helps to be right.
> My two cents: be careful not to use ASI as if it gave JS significant newlines.
> Weasel word: An equivocal word used to deprive a statement of its force or to evade a direct commitment.
From the article, emphasis mine:
> A linebreak indicates, in most cases, the end of a statement;
"Whether you like it or not, whitespace is significant in JavaScript. A linebreak indicates, in most cases, the end of a statement; a semicolon is automatically inserted for you."
Are just flat out absurd. Like it or not, automatic semicolon insertion is NOT significant whitespace and the second sentence completely contradicts the first by pointing out that ASI happens in MOST cases--but not all. If whitespace were truly significant, it would apply in ALL cases. Again, I'm not debating whether you should use semicolons or not--but I'm willing to flat out state that Javascript does not have significant whitespace; no matter how you want to spin it.
That said (and now here comes the "someone had to say it department") this strikes me, yet again, as Thomas being contrarian for the sake of getting a rise out of folks to draw attention to himself. I mean no disrespect with this statement; but anyone who has followed him for a long time on Twitter knows that he's apt to taking an unpopular position and leveraging it as a marketing opportunity for himself (and, by extension, his consulting and training enterprises). That's a fine approach; but, I felt it time someone identified it for what it is. Thomas is a smart dude and he's built some amazing things; but his public persona and style is carefully crafted and contrarian and we're all buying in by popularizing the debates he either creates or catalyzes.
[Edit: fixed a typo]
As to this:
leveraging it as a marketing opportunity for himself (and, by extension, his consulting and training enterprises)
Thomas doesn't consult any more, and hasn't for years, and we have almost entirely discontinued our training workshops, because they are too much work. However, when we want some extra cash and put one on, they sell out regardless of what we say or do, because Thomas' real life JavaScript experience (crafting amazing libraries which jumpstarted the dynamic web, used by millions) and my real life teaching experience speak for themselves.
Yours is a fallacious argument.
And as for my entirely predictable defense of my husband… anyone who's watched us work together would laugh at that statement. But in this case, he's right, and you barely mounted an argument except that:
"Whitespace isn't significant" -- except that, of course, by ASI rules, it is sometimes and not others. You can argue over the meaning of the word "significant" and say it is all or nothing, but that is not what the rules of ASI indicate. Call it what you will -- sometimes it is, sometimes it isn't.
"This is a calculated marketer at work, trying to sell consulting and training" -- which is untrue.
As for my comment being "little more than an attempt to drag me into a 2-on-1 battle royal" -- is Thomas even addressing you? Not at all, from what I can see.
In fact, your whole argument was a subtle way of saying "He doesn't really believe this, he's just peddling shit in order to make sales." None of which you can support, especially since the implied gain (the sales) doesn't exist.
You have no real reason to believe, much less state publicly, that Thomas is disingenuous in his opinions.
This makes it an ad hominem attack, by the by.
>"Whether you like it or not, whitespace is significant in JavaScript. A linebreak indicates, in most cases, the end of a statement; a semicolon is automatically inserted for you."
>Are just flat out absurd. Like it or not, automatic semicolon insertion is NOT significant whitespace and the second sentence completely contradicts the first by pointing out that ASI happens in MOST cases--but not all. If whitespace were truly significant, it would apply in ALL cases.
I don't mean to gang up on you, but that just isn't right. Will you agree that newlines are significant in both Ruby and Python? Because both of those have cases where newlines are not terminal. So I think this absolutist stance is quite unreasonable.
Automatic semicolon insertion is ipso facto indistinguishable from significant newlines in a language where semicolons are statement terminators — both mean that you can end statements with newlines. The fact that JavaScript's ASI rules have awkward holes just means that its ASI rules have awkward holes. Have a look at Go for an ASI language whose creators take the opposite stance of Eich's — even though semicolons are canonically there at the end of statements, you're encouraged to omit them in your code.
Basically, I think you're taking a far stronger stance than is warranted. I don't agree with a lot of what Thomas Fuchs said in the OP, but let's not try to outdo him in absurdity. You can feel that including semicolons is the right choice without ignoring the plain fact that ASI does mean you can end statements with newlines most of the time (and that the inability to do so in a few edge cases does not prove otherwise).
EDIT: I went ahead and JSPerf'd it, and it is 13x slower to run the example in the article.
A lot of times this doesn't matter, but it's not nothing.
Edit 2: Also people avoid using `with` so their minification tools have a better chance. Another thing that can be overcome, but just pointing out that it's not religious dogma that makes people avoid `with`.
I think that once you start optimizing performance problems you need to 1) measure things anyway, and 2) fix on a case-by-case basis. (Don't optimize prematurely, etc.)
var id = 123;
function updateOptionalProperty(obj) {
with (obj) {
id = 456;
}
}
updateOptionalProperty({id: 0});
id // 123
updateOptionalProperty({});
id // 456If people want to save bytes, they will do it naturally. Everyone has their own coding style. Enforcing 'your way' on others is just patronizing, and shows how little regard you have for others carefully crafted workflow. Sure, avoiding the Wrath of Crockford is fine, and I demand every developer adheres to his always useful comments on the language.
But don't try and be him, by offering very little in depth advice on what 'not to do' in JS. The only people that avoid semicolon use are the ones writing JS1K demos, and actually care about bytes. The rest - they do it to save costs on their high-speed CDN setups they have on their blog.
My point is, there is no need to be religious when we already have a dozen or so packer scripts, and byte-saving scripts, on the web already (JSCrush, Dean Edward's Packer Tool, @cowboy's packify etc.)
Not to mention the already mentioned, and very powerful Closure Compiler. And I could go on, and I urge others to suggest other packers out there at the moment in this discussion.
When I'm hit by a bus, and my code is only understandable by me, then sure, by all means, attack me, and mark my code as obsolete, unusable, and redundant, but at least look through the foot-notes and see I made a developer-friendly version of my code, completely un-minified, obfuscation free, and free of gotchas and unorthodox methods.
Peace.
"Or, don’t trust what “wise” elders tell you."
"My recommendation: learn the language, and use it to your liking; and don’t rely or blindly accept what any “wise elders” tell you. Try to do something new and crazy every day. You might not end up using the crazy, but it’s the best way to master JavaScript. Develop your own style that you are comfortable with. Experiment."
these points are still up for argument, but really they are pretty trivial. __You__ should __experiment__ with them and see if they are okay to use for yourself. The main trick will be if they make your code easier to understand and/or perform better _everywhere_. As long as it helps one of those cases without the detriment of the other then go ahead, just be aware of why people argue over them.
If his point two was, for example: "You should always test received wisdom. You've probably heard not to use 'with', but do you know why? Well, let's write a quick benchmark, here's some code with 'with' and here's some without. And if we benchmark it like so...hey look! The code with 'with' is a little clearer, but it's glacially slow! And now you know not just why and when to avoid 'with', but how to test other language features too!"
But instead, basically, he said "Hey, don't listen to those idiots who say not to use 'with', listen to me! And I say it's awesome!" This is unhelpful on multiple levels.
But #4 rubs me the wrong way. This strikes me as the opposite way to spend more time with your family. A little bit of preventative effort done on the clock will often reduce the amount of emergency code fixes that you do after-hours.
There is no value in using any of those features.
As mentioned, 5 is not a thing. That's spec politics, you shouldn't be doing any of that.
As for 1, well that's a whole other argument, and it's an opinion. You choose one, nobody cares what you choose.