Bootstrap's maintainer hates the semicolon
github.com
github.com
I hate these ideologues. But this is the trouble with JS I guess. I actually love javascript because of the highly dynamic nature of it. But that dynamism also lends itself to these kind of problems. I don't know of any other language where people can CHOOSE to follow syntax. Part of the problem is the awkward interpreter specs I guess. But also, with JS seems like everyone has an opinion :)
Now that I know there is some demand for a branch of this sort, I'll share it ASAP.
EDIT: the repo is at https://github.com/rajivnavada/bootstrap
https://gist.github.com/1815639
Of course, unless you're the sole writer and reader of the code, it's generally good to follow the common practices that evolved around the particular language.
I'm a python/haskell guy too, I hate semicolons. But I'll put up with them because javascript needs them, it doesn't enforce them, but to write sane, maintainable code it really needs them.
Javascript is enough of a mess, this kind of thing just throws gas on the fire.
Have you published your branch? I think it would be very useful.
I know the semicolon insertion rules, because I'm obsessive-compulsive like that. In any team I lead, any software I write, and any open-source project I maintain, the coding standard will be "Terminate all your statements with semicolons."
Why? Because my job is to make less work for people, not more. I could give them a list of 4 rules, often each having a list of a half dozen+ tokens, and say "memorize these, or you're not a professional JavaScript programmer". Or I could say "Terminate your statements with semicolons", and there's one rule, the same as in many other languages, for them to memorize.
Other projects are free to do whatever they want with their coding standards, and if they want to make things complicated to show how 1337 they are or just because they think it looks pretty, fine. But of all the things you need to worry about to be a good frontend engineer, where to put the semicolons seems like the stupidest possible one.
There's one and only one of these cases which I've seen (and I'd see) happen: `return`, for users of Allman, while that is completely nutty (just as Allman) some people will write:
return
{
key: value
};
`throw` would be really weird, it may happen with a labelled break or continue but I've yet to see those ever used at all (so a user of these probably wouldn't fuck up the label, plus that label would become a bareword which most static analyzers would trivially see) and postfix operators outside of continuated expressions (e.g. function calls) are unlikely to be split.
I've been bitten more often by not having inserted semicolons than by any of those.
The point's to minimize the amount of additional complexity that developers have to memorize. The set of rules above is very similar to what you see in pretty much any Algol-derived language; most developers already have it burned into their fingers. The set of rules necessary to code safely without semicolons is very specific to JavaScript, and to a very idiosyncratic style of JS at that.
Your argument is incorrect. :) Omitting semicolons is perfectly valid and correct syntax. The spec is explicit about it being allowed and how the code shall be interpreted: http://es5.github.com/
It may be a good rule of thumb to use the semicolons, because you have to be careful without them, but in the end it's a choice based on team preference. If you are a very pertinent and careful type of person, and you don't have any rabid illiterates on your team, going without semicolons makes perfect sense.
"Bootstrap is designed to help people of all skill level—designer or developer, huge nerd or early beginner. Use it as a complete kit or use to start something more complex."
So: 1. "illiterates" are welcome to use it. 2. If the goals are to be met, do not assume anything that can be interpreted differently by different players.
Why does it make perfect sense? There's nothing wrong with including them, and I find it reduces the amount of thinking you need to do. JavaScript has C-like syntax; it should end its lines with semicolons and it's a mistake that it doesn't always require them.
You should check out Lisp macros ;)
I see two camps here - people who fear the unknown or come from semicolon-mandatory languages and can't get used to the semicolon-less style, and informed people who don't fear to embrace what is aesthetically more pleasing and logically more sound, despite the persecution by the members of the first camp, which I'd say also happens to be more religion-prone.
In JavaScript, semicolons reduce ambiguity. Whether you know the semicolon rules in the language or not is immaterial to reducing ambiguity, similar to how defensive parenthesization is helpful regardless of whether you know the order of operations of a given language by heart. This is why the prevailing wisdom is to always use semicolons: principle of least surprise.
The nonsense about "persecution" and "more religion-prone" is just that. "Informed people" -- "aesthetically more pleasing" -- "logically more sound" -- ad hominem and begging-the-question horseshit. Do better.
exactly. be an evangelist, not a brogrammer.
http://okasaki.blogspot.com/2008/02/in-praise-of-mandatory-i...
I'll grant you that's not a large scale experiment on a peer reviewed paper. But I trust Chris Okasaki on this one, and to me, his experiment counts as strong evidence against semicolons and brackets. (Specifically, semicolons and brackets are error-prone, especially for beginners.)
Now for Javascript, I'd probably write the semicolons. Because there is some ambiguity in the way we humans would parse Javascript without semicolons. But really, the root of the problem is that Javascript's syntax is suboptimal. Sure, Dennis Ritchie didn't know better at the time he wrote C, but this is no longer an excuse.
If I had a say, I'd simply write an alternative syntax with mandatory indentation. It's not hard[1]. If Bootsrap's maintainer dislike semicolons so much, he probably should do so as well. He will likely lose contributors, but someone who cannot get past a Python-like syntax is probably not someone he would want to work with anyway.
[1]: http://www.tinlizzie.org/ometa/ (Quite the tool for the job. Plus, it already features a Javascript parser you can modify.)
Re-reading my post, I find 2 potentially offensive excerpts:
"Dennis Ritchie didn't know better" Assuming mandatory indentation is superior, this one is flatly true (and there are other things to be said about the syntax of types). But I'm not saying he could have known better. As far as I know, no one knew better at the time.
"someone who cannot get past a Python-like syntax is probably not someone he would want to work with anyway" I apologize for this one, but I am personally fed up with people who won't use provably superior technology just because it would break their habits. Enforcing indentation in Javascript would be a minor syntax change, that can be learned in minutes and mastered in a day. I'd be wary of someone who refuses to make the leap despite the evidence for it. I must admit however that I'd understand if they just didn't believe in the evidence. (but then we can talk).
In your estimation, is there a difference in experience between those JS coders who are knowledgeable of ASI and those who aren't?
The intention is to make code easier to read and type. The mental effort is the same.
As opposed to embracing the rationally derived and broadly accepted coding guidelines used by over 99% of open-sourced javascript projects.
I could embrace linguistic documentation and still speak a form of English that would be unnecessarily dense or terse, or just plain incomprehensible to 99% of the English speaking public.
http://en.wikipedia.org/wiki/Differences_between_Afrikaans_a...
http://bonsaiden.github.com/JavaScript-Garden/#core.semicolo...
var foo = function() {
} // parse error, semicolon expected
test()
var foo = function() {
}; // no error, parser continues
test()> Each is perfectly valid. Each behaves the same. It’s just a matter of preference and finding the style that makes most sense to you.
Part of being a good steward to a successful project is realizing that writing code for yourself is a Bad Idea™. If thousands of people are using your code, then write your code for maximum clarity, not your personal preference of how to get clever within the spec.
Code is harder to read than to write. To borrow a line from Jacob Kaplan-Moss, if I write the cleverest code that I am able to, then by definition I won't be able to understand it later.
This semicolon approach isn't invalid, but it is clearly a source of confusion, and it requires that users comprehend the choice and the tradeoffs. This seems like a poor choice for a framework whose audience is largely people who don't grok this stuff and are bolting it on wholesale.
<3 bootstrap, just my $0.02.
Principle of least astonishment (POLA) was also a core design decision behind ruby. http://en.wikipedia.org/wiki/Ruby_(programming_language)#Phi...
In this blog posting Jacob writes:
The majority of lines however don’t end with semicolons because they simply aren’t necessary and I prefer the minimalist aesthetic. For me, \n character is enough and the semicolon character is redundant.
He then points to the izs blog posting about it:
http://blog.izs.me/post/2353458699/an-open-letter-to-javascr...
Jacob calls it more 'minimalist' however it does require you to know (and think about) the rules of when Javascript accepts a newline as a line terminator and when it doesn't. In terms of cognitive minimalism 'semis-everywhere' wins. @izs even acknowledges that part of the advantage is forcing the developer to learn:
To the extent that there is an objectively “better” choice, it appears to me that the minimal-semicolon/comma-first style is slightly superior, both because it is fundamentally more scannable and because it encourages programmers to better understand the language they use.
and later:
If you don’t understand how statements in JavaScript are terminated, then you just don’t know JavaScript very well, and shouldn’t write JavaScript programs professionally without supervision, and you definitely should not tell anyone else how to write their JavaScript programs.
He excludes the possibility that you might understand the rules and still prefer to put them everywhere. So all people who disagree with his choice (which he admitted was only slightly better) tend to get categorized as people who don't understand JavaScript very well and we get a new holy war. The fact that all of the JS noobs are lumped on one side of the argument means it's not cool and we can dismiss a well reasoned opinion as ignorance.
All this being said, I personally don't care strongly one way or the other.
One should be self-expressive, but I don't think syntax is an opportunity to be so. Regardless of whether it works a certain way, there's very likely an objectively right way for it to be done.
Sure it is. Textual expression is a function of both form (syntax) and content (characters). Not only that, but TMTOWTDI enforces overlap between the right way to do something and the coding preferences of the implementor.
JavaScript interpreters insert semicolons. If you abuse this, you'll end up with unpredictable results like his function example.
You might not know that the return statement is a restricted production, but you do know when you shouldn't immediately follow it with a linebreak.
Similarly, if you see a line beginning with ( or [ which isn't a continuation of the statement on the previous line, stick a semicolon in front of it, or in the case of a wrapped function() {}, use one of the other means of telling the parser it's a function expression. There are other restricted productions, but you just solved every non return-followed-by-linebreak ASI issue I've ever seen in the wild.
I'd bet with confidence that 90% of programmers out there don't know if a semicolon is needed after a function declaration. They just put it in there blindly, then some day they find a bug because they "forgot" a semi-colon somewhere.
Indenting isn't necessary either. Less necessary even than semicolons. We do it for a reason. Maintainability, understandability.
The less ambiguity the better.
The only advantage you get is you can see a thread like this and say I DON'T USE SEMICOLONS CUZ I BE SO SMART I GET JS SO GOOD. But you're not coding to work with other people. It helps no one else, it's esoteric and unnecessary.
Imagine if a coder wrote a big huffy blog post declaring that he was only going to use single-character variables everywhere because it was more "minimalist" than using descriptive variables. He'd be hanged.
Obviously what "fat" is deciding to do with semicolons is less annoying than the strawman I just made up, but I don't think it's entirely dissimilar. The Javascript spec doesn't say that you must use descriptive variables, and using single character variables is certainly valid. However, it's an established convention that we just don't do that, because people find it irritating.
Basically this just comes down to "plays well with others".
From this we deduce that Richard Stallman is really Ron Jeremy.
Easy solution, use CoffeeScript and have it compile down to JS. My favorite feature of CoffeeScript is the ruby/python line conventions spacing (2 spaces, no tabs), and no semicolons.
They're already compiling the CSS from Less. Seems natural to add CoffeeScript to the chain.
I hate unnecessary semicolons too. Though I deal with them by including them everywhere, but making them hard to see in my editor ;)
And yes, I realise that some of these options can be turned off—but JSHint has better defaults.
{
"browser" : true,
"node" : true,
"undef" : true,
"eqeqeq" : true,
"noarg" : true
}Nobody's forcing anyone to use Bootstrap nor is anyone prevented from creating their own Bootstrap fork with semicolons.
Clearly, no good deed goes unpunished.
This is one of reasons why companies have strict coding-style guides but that is overhead for a very small company (you don't need coding-style you just need developers which know that code needs to be written with understanding it will also used and maintained by other people in your team).
var x = function() {
// something
}
// avoid polluting global scope:
(function() {
// Some initialization.
})()
There are more examples to that point, and many of them really aren't all that straightforward. So don't rely on automatic semicolons.
var x = function() {
// something
}
// avoid polluting global scope:
!function() {
// Some initialization.
}()Better or worse?
;function() {
// Some initialization.
}()
void function() {
// Some initialization.
}()Why aren't we just using the semicolon as it is required in any other (C-based) language?
var x = function() {
// something
}
// avoid polluting global scope:
;(function() {
// Some initialization.
})()
;[1,2,3].forEach(...)
'semicolons at the end of each statement' is much more random. They are unnecessary after function declarations or conditionals, and you might end up forgetting them somewhere that actually matters, just because you're not paying attention. The mental effort for this change is severely overestimated.
> The lack of semi-colons in the dropdown js file causes this compression to break
Thanks for the heads up, no bootstrap for me! (At least without something that's going to add the necessary semicolons... I wonder how many HN weekend projects out there simply don't work for people using their wireless connections?)
Also interesting that it appears the issue was closed because it contained the key phrases 'compression' and 'semicolon'... but it was not re-opened even after the maintainer realized the problem is with the wireless providers.
And honestly, that should be done by the minifier. It breaks perfectly valid javascript.
Basically, I added a 'proper' target that 'bootstrap' depends on. This target simply adds the semicolon to the end of the file. Hope it helps those of you having problems.
return
{ foo: 3 };
Personal anecdote time: I've been writing Javascript for my job for about 16 months now. When I started, I read all the same material as the readers of this site probably did, mostly written by Crockford, advocating a certain brace/semicolon heavy style. But after dutifully following this for about 6 months, I started to notice that I had made many 'mistakes' in the code, to do with missing semis particularly, and so had a lot of other people in the company. Of course, all the code ran fine everywhere and nobody had noticed in 6 months.
So, when writing code for personal exploration at home, I stopped using semis. It's surprising how much time you spend making sure they are there when the interpreter won't check for their presence (and doesn't care either way). Issues can crop up to do with missing semis, but so far I haven't had a single issue, probably because i'm aware of avoiding certain things, like starting a line with a bracket.
So, in my personal experience, it hasn't mattered to have them or not. If you absolutely need them for minification or similar, you should be using a compiler like yui. You are going to make a mistake if your code base is large enough to matter, irrespective of how vigilant you are, so you might as well leave minutiae like this to a computer.
In theory, yes, it doesn't matter. In practice, it does (and YUI, etc. do not fix the problem):
IMO this is a reasonably serious browser security issue along the same lines as CORS, but thats another argument.
Semicolons are not optional. They are inserted for you as a convenience when the parser can figure out what you meant.
This situation wasn't a big deal in the early days. But the patterns of coding that have emerged to deal with Javascript's scoping problems have brought this from a curiosity to something profoundly crazy.
Using an operator (i.e. !) to fool the parser is hilarious but really not OK.
Writing code is an exercise in communication. You are communicating with other programmers (including your future self) and the parser. The zero semicolon style espoused by @fat is problematic for both other programmers and the parser. Perhaps one day @fat will win and his style of communication will be sufficiently accepted to be valid but this is not that day.
The relevant section of the ECMAScript spec is included for your convenience:
7.9 Automatic Semicolon Insertion Certain ECMAScript statements (empty statement, variable statement, expression statement, do-while statement, continue statement, break statement, return statement, and throw statement) must be terminated with semicolons. Such semicolons may always appear explicitly in the source text. For convenience, however, such semicolons may be omitted from the source text in certain situations. These situations are described by saying that semicolons are automatically inserted into the source code token stream in those situations.
http://www.ecma-international.org/publications/standards/Ecm...
As far as minification and optimization is concerned it works fine using yui, google closure, uglify.js .
(also mentioned by fat in https://github.com/twitter/bootstrap/issues/401#issuecomment...)
A proper minifier/concatenator will add the necessary shielding semi-colons. Don't use anything that messes with your code without parsing it.
Now you can code any way you want, but no more white-space changes cluttering up the history of files. This is the worst type of holy war because it not only doesn't matter much (which is true of any) but there is a technological solution that the engineers involved are all ignoring.
People should understand the role of semi-colons and ASI, just like they should understand the comma operator. It's not hard, takes 10 minutes (read Isaac's post).
Everyone saying that they don't need to understand it is doing a disservice to the community, there's no harm in wanting knowledge of the language to evolve. A few years back people seldomly used IIFEs, and I remember hearing the same argument (wtf is that, don't use it, I don't understand). Change is good.
My repos don't have a lot of semicolon-related problems, because they don't have almost 20,000 watchers and tons of people using my code.
Am I the only one who now won't consider using Bootstrap for a project (based on this semicolon issue)?
Or at least, I would still use bootstrap even if I had to throw out all of the js.
A: Hey, remember when coding was fun? When it was an extension of yourself and you got to create things with it? Create things!
B: No. We're not allowed to do anything except what the Good Book deems acceptable.
A: But, but, you get to take this blank slate and carve out of it whatever you can imagine! Pure expression! And remember when you prioritized your coding style for enjoyment?
B: No. Coding is not fun. Coding is about maximum compliance.
A: ... I remember, but sometimes I think the web has forgotten.
A: I mean think about it. We're banished from the 'new' keyword. We can hardly use polyfills or even extend the native prototypes. How I used to love statements like [[1,2],2,3].flatten(), but lo they are forbidden! Having even one prototype extension in your library is a death sentence. No having fun in Javascript-land!
B: True, fun is not allowed.
A: Hey, what's that over there? That gleaming light coming from the back of that house? Is that a party? Hey it's that house that @fat and @mdo built. They're having fun? We should join them!
B: You don't want to go there man. They don't use semicolons.
A: Is that all they're doing? So what, they're not following the Good Book? They're not afraid to do things a bit out of the ordinary? I'm out of here. See you later Javascript-land. B, I'm going to have some fun with those guys.
B: ... prototype extensions?
(Thanks @fat, @mdo & Twitter for Bootstrap, and for giving it away nonetheless. If I ever have a problem minifying your code, I'll fork it and just add the semicolons myself.)
Even when they handle ASI itself correctly, these tools don't always handle things that nicely across files.
This code:
do a <- [1,2,3]
b <- [4,5,6]
return $ a + b
do {
a <- [1,2,3];
b <- [4,5,6];
return $ a + b
}
do { a <- [1,2,3]; b <- [4,5,6]; return $ a + b; }
do { a <- [1,2,3]
; b <- [4,5,6]
; return $ a + b }The first language I learned was VB6 (ewww), after that C, C++, Java, JavaScript and PHP, only a few years ago I started to hear a lot about Python, Ruby, etc.
I don't see what's the problem with the braces and semicolons, I got used to write them and I don't see it affect my coding speed or code readability, in fact I find it easier to read code with braces and semicolons, I learned a little of python a few months ago and ignoring the fact that I do not know the language syntax very well (or more common libraries) yet, I write it as quickly as I would write Java/C etc, for readability I read python slower but as I said I'm not used to the syntax/libraries/etc yet so that may be the problem.