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

Add the semicolon

"but but but" add the semicolon

There's so much FOR it, it's unbelievable. Yes, it's good to 'break the rules' now and then. Add the semicolon

This is not about if JS allows it or not. It's important, but mostly irrelevant.

You can also not add 'var' to JS variables unless needed. That's going to be a lot of fun when it goes wrong.

But here are the million dollar questions:

1 - How much time is spent making it work without a semicolon as opposed to just typing it? This is not about typing ';' - time for that is irrelevant, but the mental effort of doing so 2 - How much time will it be wasted to fix minifiers (that is, add to them the intricacies of no-semi colon parsing and probably having to write a whole different parser) 3 - How much mental effort is needed to comprehend and correctly fix non semicolon code

Number 3 is the biggest issue and if you don't believe me it goes by another name: coding standard

Yes, JS works without semicolons. And yes, C works without indenting, without meaningful names to variables, etc.

It's not about "to write JS you should know all the nitty-gritty rules of the language and you're stupid if you don't know them so you just add semicolons". It's about teamwork, and facilitating code comprehension (and maintenance).

And language designers make mistakes. They don't know if a feature is going to become a trap, irrelevant to 99% of developers (and with an easy workaround) or just a pain in the behind.




As a devils advocate.

1. How many times are we going to have to debug and rewrite code to work around this defect? If it were just this once sure add the the ';', unfortunately it is never just this once.

2. How much time will be saved by using a minifier that actually supports the javascript language. What other language features will break because someone didn't feel like supporting javascript in their javascript minifier?

3. How much mental effort is needed to support half a dozen different minifiers that all support a different subset of the language as well as the cross browser differences we already have to take into account.

It is a matter of trust. If your tools skip supporting language features because someone decided they didn't like language feature X, what other corner cases did they skip because they were unliked?


Another advantage of the minifiers with a correct understanding of JavaScript is that they can do way more advanced minifications like shortening variable names.


How much time will be saved by using a minifier that actually supports the javascript language.

How much time would be saved by widespread use of "The Good Parts" of Javascript? This is likely to be much larger than the time you propose.

How much mental effort is needed to support half a dozen different minifiers that all support a different subset of the language

Who says you have to? If the community as a whole started omitting the hairy parts of the language, they would tend to converge on the same core. A superset of the 5 or 6 most popular subsets is still going to be a lot cleaner than the whole hairball. In practice, this is about the coverage that just about any language gets from tools like compilers and code transformers -- after all, the serious tools pretty much all have bugs. A superset of the 5 or 6 most popular language subsets is all anyone gets in practice.




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

Search: