Shared publicly  - 
Christian Heilmann's profile photoAlexandre Gaudencio's profile photoRoman Ivantsov's profile photoLewis Walsh's profile photo
"... we should not write more code faster but cleaner code and re-use it more often..." Amen!
My thoughts exactly on semicolons and if statement curly braces. Consistency trumps a list of rules for making readable code.
Two words: robust code. If you don't code with that principle in mind, you are not fit for the web.
Yep - all these browser quirks/shortcuts are important to study for tool development (e.g. compression tools, which is funnily enough how the whole debate got started). But not for human-readable source. If you want to omit semicolons, there's plenty of Alt-JS languages to choose from.
This might be the funniest thing I've seen today. Seriously, though. Congratulations if you can figure out how to fit a piece of code into a Twitter-sized chunk, but I say that a top-notch developer knows how to create work that other developers can maintain and understand.
completely agree. And most of the "tricks" and missing colons will be added/removed by a JS compiler/minifier, like closure compiler. We should keep writing better quality code that can be easily understood by others.
'Don't be a JavaScript hipster. Add semi-colons' - need that on a T-Shirt I think. I use CoffeeScript a lot, just because I like it, its a bit quicker for me to write and I know it compiles to compliant JS - with semicolons and everything - as far as I am concerned the ; lives.
I guess I never found semicolons to be a nuisance to the point that it slowed down my coding. It's on the main row of keys! I could understand if we had to drop a ctrl-alt tilde at the end of each line and we all had little fingers.
These arguments are always frustrating, since both sides see themselves as being obviously right. Who is more in the right, someone who calls for consistently formatted code, or someone who complains that a JavaScript formatting tool can't parse standards compliant JavaScript? The HTML syntax highlighting example is similar, on one hand inconsistent formatting, on the other, a highlighter which can't parse valid HTML. Anyone taking a "side" is both right and wrong, fertile ground for a flame war.
totally agree with your post. to know, each browser will fix bad code in its individual way, frightens me.

and what's the point of this micro-optimizations-nonsense? "i saved four bytes. yippieh…" one's focus should lay on more important things.
I still can't figure out why they would remove the semi-colons in the first place. It seems to me it will just increase the chance of errors. Think of all the wasted time just removing them from the existing code-base that had them, and how it could've been used adding new code (with semi-colons) instead.
Nice write-up, Chris! I agree with most of your points. Generally speaking, readability is much more important than file size, compression, or just laziness while typing — especially when you’re working in a team (IMHO). But then again, “readability” is a subjective measurement, which is why we end up with so many different coding styles.

However, I feel like I should clarify why I write blog posts like the ones you mentioned.

I don’t advocate the omission of optional quotes, start/end tags, or semicolons for that matter — but that doesn’t mean I don’t enjoy figuring out and writing about how exactly these things work, and what the exact rules are. It’s fun to figure out how much we as web developers can get away with — not necessarily to make use of this information, but mostly to learn something new.

P.S. As +Michael Mahemoff mentioned, this information could be useful for minifiers though. IMHO developers should write readable code (whatever they consider to be readable), and let minifiers take care of the rest. For every blog post I’ve written about “optional language parts” that aren’t considered in YUI Compressor already, I’ve filed a ticket over at their issue tracker: Other write-ups inspired me to report browser bugs (of which I ended up fixing a few myself), and to patch various open-source projects.
Some, at least, of the practices you condemn are valid javascript/html/whatever syntax, not a "parser quirk" that shouldn't be exploited. A tool intended to process such code should be able to deal with valid syntax, however objectionable you may find it.

The reason I don't omit semicolons, braces or quotes in my code is partially for your reason of allowing for future expansion, but mainly to free up space in my brain!

Sure, it's valid under certain circumstances to omit certain punctuation that's usually required. The problem is, I have to remember what those circumstances are to remove them, and remember to put them back again if those circumstances change.

I'd much rather sling those symbols in there whether I need them or not, and free up bits of my brain to think about more important things. Believe me, it becomes pretty automatic anyway to put a ; on the end of each line once you've been doing it for 30 years!
+Chris Hunt That depends on if the tool is opinionated or not. This tool by +Douglas Crockford is as opinionated as his comment implies. I'm okay with that as long as it says "does not minify insanely stupid code" on the tin.

That doesn't mean I'd use it everywhere though. I would be happy to use it for a small library, I might even prefer its strictness in that. But I wouldn't use it (if there are viable alternatives) for a whole project as there are too many libs/frameworks which, like Bootstrap in this case, may not be compliant.
Native apps are eating our lunch. And we're spending hours arguing about syntax. * cries *
the parser spends energy on every correction that must be anticipated. the parser is repeated at a billion screens, it should be energy efficient, nimble.

so this is about the planet. the planet thanks you for being prudent. do NOT be forgiving of the few beer bellies burping their offenses.

at the same time everybody has his style. just as css markups html text, so should our code-editors render the code in the format we prefer: with or without semicolons, with or without significant whitespace, etc.

all of this is form, we should not f.e. throw away the excellent infrastructure of Python JUST because our eyes are trained to expect ugly braces. this attitude is just plain stupid, but that's what we as a collective seem to excel at.

that is because there is in fact NO collective, when some have the right to harvest in the garden of others, but not be accountable for the destination they give to the produce. it is what the american way has turned into.
all this gaming going on, it is a ---king blasphemy.
Just think of a semicolon as your code winking at you. Its saying "Ah I see what you did there. Nice."
if you're writing code that isn't accepted by the compiler then don't write code like that. Using a subset of the language is a good thing, it's only bad if it prevents your code from doing what you want it to do. I use the closure compiler and get along just fine not mixing my square bracket and dot notation, not by choice, I could do many cool things quicker, but the code at the end makes more sense, is easier for people to understand and still works. I'm guessing most people aren't using eval or with, and not using automatic semicolon insertion should be considered the same thing.
Kyva Go
"All in all I get the feeling that people who argument for code that needs magical insertions and fixes by browsers simply want to show off that they can do things differently."

By putting "argument" where "argue" was meant you made me re-read that sentence three times to be sure it was a mistake. Was this a deliberate example of "the efforts of “writing code (or blog posts) faster” pointless as we push the time-wasting to a later part in the project – and make other people (the reader) suffer for our laziness."?
+Mathias Bynens yes, I mentioned that in the post. I said you do a great job poking at the parsers and finding out great information for low-level tools.

+Chris Hunt whilst valid JavaScript and HTML that doesn't make them sensible practices for a HUMAN to write. Our job is to write readable, extensible code. If there needs to be optimisation, then a build script should do that. I have yet to see an example where omitting quotes in HTML has any benefit other than typing less when you code. As I showed it breaks colourcoding though and thus readability. When you gzip your components and let the browser unpack them the gain from removing quotes is so small it is not worth it - even more interesting some tests showed that unminified code packs better. It is optimisation at the wrong level.

+Paul Irish I wasn't arguing about semicolons or not, I was arguing about writing flaky code for the sake of it. Because we bicker about being different for the sake of it we waste time. However, the statement that "Native apps are eating our lunch" is a very sweeping one. I think you can not compare apps and the web face to face. Apps NEVER can reach as far as the web can as they are tied to hardware (expensive hardware) for now. We can beat native apps if we build frameworks that work across all browsers and hardware and concentrate on the strengths of the web. We will just play catch-up if we try to match a native experience in a non-native environment. You build great experiences when you know your trade. Right now, we argue against anything that made the web what it is and try to innovate for the sake of it as we are scared of native apps and believe the marketing talk about the numbers of awesome around them.
Methinks you're missing a point somewhat. What you're saying is, basically, "don't write shitty code, write readable code"; and then you take as granted that omission of unneeded characters is bad.

The question is not whether
> you advocate omitting sensible syntax
no one does. The right questing is, whether unneeded characters are even sensible syntax.

Myself, I use semicolons, so this particular subject isn't really hurting my religious feelings or anything; your reasoning just doesn't feel right at all, defaulting to "right is whatever thing I do" approach.
"Our job is to write readable, extensible code."

The thing is sometimes omitting thins makes code more readable.
Do I really nead to write out <html>, <head> <body>? Does writing <input … disabled="disabled"> make it more readable than just <input … disabled> ?
Or just compare CoffeeScript with the JS it parses to :)
I don't think writing code with or without semicolons is the problem. Automatic semicolon insertion is part of the language and we as developers can choose if we want to rely on them or not. There are other large code bases (e.g. npm) which are written without semicolons. For me this is totally acceptable as long as it used consistently throughout the codebase. However even if we choose to insert semicolons ourselves we still have to know how it works because sometimes will still insert semicolons in places we otherwise might not expect. The npm author Isaac Schueter phrases this better than I ever could
In this regard I fully disagree with Crockford's statement. If his tool is called JSmin it should be able to process valid JavaScript code and automatic semicolon insertion is part of JavaScript.
+Rimantas Liubertas yes, to me writing HTML, head and body makes sense as maintainers want to edit the title of the document and find the linked styles in the head. I agree that disabled="disabled" is verbose, but that is an annoying inconsistency in HTML. disabled="true" or even state="disabled|enabled|hidden..." would make more sense. Comparing what coffeescript parses into to what you write by hand is like comparing what google translate makes of your English when you turn it into French.
+Fabian Jakobs yes, but this is not about semicolons. It is a bigger part of the "this works in browsers, so we don't need to add this" argument you hear a lot and my post stated that with that you expect maintainers to know what you did. In a more specialised environment like NPM this could not be an issue at all - it could even be defined in the style guide.
+Fabian Jakobs It's possible for both JSMin and Bootstrap to be "wrong". So while I generally agree JSMin, it doesn't excuse a general-purpose library from using normal language conventions.
Yotam p
If you want to write non semicolon code use Coffeescript or write your own language.
Why break a perfectly good Javascript syntax?
I can't believe (well actually I can ) how fecking picky some people can be. For feck sake the guy that refuses to add a semi-colon is an idiot. When I started developing Javascript and found that to get it to work in all browsers I had to use a var before assigning to a variable. Did I throw a strop saying "It works in Browser X, So its not my problem"? No, I made a small change so that no one would see an error.

Simple issue here is that the JSmin should stay the same and the guy should just add a fecking semicolon. After all the semi colon is telling a dumb compiler start a new line of execution. Making an assumption that the Javascript compilers will always handle missing semi colons is a bad way of going about your code.

A bit like saying that the new CMS I'm writing is runing on Apache so I can use have a "Index.php" a "index.php" and a "iNdex.php" filenames. Then when a client wants it on Windows I go "tough cookies,".
Clean, readable and robust code will help those who have to deal with it in the future - including the author himself. having coding standards is just like having best practices in anything else people do - if we are to move-the-web-forwardTM, we should make it easily readable, understandable and modifiable by anyone!
I agree with most of the post up until the last part. If your text editor isn't recognizing class names, etc... without quotes, then your syntax highlighting needs to be updated to be in line with current standards. That's nobody else's fault. Same thing with closing tags (Also, word-wrapping? That's your choice to have on). Writing lists and paragraphs honestly are much easier to read from a developer standpoint, and that's the whole point of this discussion, is it not? I completely agree with the JS bits in terms of readability, but the HTML related bits, not so much.
What I TL;DR in this is: Accept responsibility for the code you write. Don't put the onus on others to grok your coding "style".
ECMA-262 line ends have special meanings and semicolon on end of line IS NOT 'sensible' syntax. This is redundant and useless for parser, and unlike indentation and curly braces it's useless for programmers.
In situations like these, I prefer to default to a scenario where I don't have to think about syntax since there are so many other things that need to be thought about. Is the statement done? Semi-colon. Am I starting an if block? Open curly braces. That's it. I don't have to think "Well, do I need a semi-colon here? Maybe. Let's not add one and see how it goes.

Even if it only takes a fraction of a second, when reading the code, you still have to decipher whether a line is continuing or is over and the next one is beginning. The semi-colon (or whatever statement ending character your language has) tells you its done. No fuss, no muss.

Same with quotes in HTML: Sure, you don't always need them. But you sometimes do. Why make anyone (including yourself) worry about whether you need them or not? Just put them in and forget about it!
Thank you! As a guy who made the leap from VB to C# and js, I appreciate your righteous rant and hope the powers that be hear you!
+David Bradbury What about the case of two classnames then? omitting quotes around attributes assumes there will never be a space in the value - something you can not assume. I agree that soft line breaks at 80 are old-school but I also don't see the value of lining up tables like that when the content of the cells is unknown. This example tried to prove it is fine to not use closing tags for the brevity of being able to see all the content once again assuming the content is of a certain format. That is one big assumption as the content is the first thing to change. My point is once again that not using the agreed syntax of html4 strict brings you almost nothing and confuses people.
Damn straight! Especially the curly braces. To extend these arguments a little further, the same is often said of PHP. The fact that PHP (and JavaScript) allow for sloppy code it does not follow that it causes it. They're just more forgiving. Writing lazy, sloppy code whether for the parser or the human eye is the coders fault.
Add a comment...