Not using semicolons seems fine enough. Going through and removing the semicolons that you already used seems like you're just trying to start drama. Why not use that time to do something that effects the code positively or negatively?
I believe they'd argue the removal of semi-colons has a net positive effect on the code as Zepto.js is in essence a minimalists version of jQuery. This is particularly important for mobile sites which benefit greatly from site assets remaining in memory.
(Disclaimer: I'm the maintainer/author of Zepto.js)
FWIW, it took about 10 minutes to remove the semicolons from the codebase, with a simple grep: /;$/
For the few places where a ; is actually needed you can run a regexp based search as well, the rest is easily identified by unit tests.
We've also spend some 50+ hours on writing new code, tests, a new build and automated tests system, a completely new documentation site and answering countless issues on GitHub.
Fair enough, I'm not claiming that other, much more difficult work didn't go into the feature updates. What was the reasoning for switching to semicolon-less? Why wasn't that a concern when the project started? (Apologies if I missed it in the notes.) I have no problem with projects doing one or the other, the _switch_ just doesn't fit into my brain correctly. Perhaps your tastes just changed?
Yeah, the semicolons where just there because "that's how you write JavaScript, right?". After reading Mislav's article and of course working with him on Zepto I realized that actually, the semicolons don't do anything; and I like the code better without them. (I'm also doing a lot of Ruby and CoffeeScript, so I'm biased, I suppose.)
So yes, you could say my taste changed, but there's good a good reason behind it—the semicolons are optional, and Zepto is all about concise code.
It breaks SOME minifiers. There was some inlining tool used by some mobile ISPs that basically downloaded referenced JS files in <script> tags and injected them inline to get rid of another HTTP request. They broke, because they are stupid, broken tools.
A correct minifier works on the AST of the code anyway (at least in the abstract). It works on the semantic meaning of the code, so it interprets semicolons or the lack thereof exactly the way any other implementation would.
The first case with the broken inlining tool is typically not actually an issue, because your semicolonless code gets put through a minifier which probably adds a bunch of semicolons again :)
I can't help but think that maybe Crockford's plan was to eliminate JS semicolon use all along by sparking a nerd backlash, and that he's a goddamned evil genius.
Hey Thomas -- Given your recent CoffeeScript kick, I've been curious if you've ever thought about going fully semicolon-free by taking a stab at a Zepto.coffee. My initial take is that it doesn't make sense, because one of Zepto's goals is to hone the code down to the fewest bytes possible: something that CoffeeScript would make a bit more difficult. Have you considered it?
I love CoffeeScript, and we're considering moving the Zepto tests to use it. (We're also using Ruby for our build system, for example, because we like it, and think it's the right tool for the job.)
I think for the library code itself we prefer using JavaScript because in lots of ways it allows very fine-tuned control, one (of many) examples for this is deliberately using == instead of ===.
Interesting. Taking a brief peek through the source, I don't see any "==" comparisons that look like they couldn't just as well be done with "===" -- except for a handful of "== undefined". And of course, that particular check would be done in CoffeeScript with the existential operator. But I'll take your word for it.
I have considered it myself, but quickly dismissed it because, yes, the output would grow considerably.
I love Coffee and would use it for everything, but this is one of those cases where we simply need to squeeze every single byte and scream each time that we have to let one go.
18 comments
[ 3.0 ms ] story [ 46.7 ms ] threadAnd honestly this is, intentionally, a tiny library. If it took more then 10 minutes I'd be surprised.
FWIW, it took about 10 minutes to remove the semicolons from the codebase, with a simple grep: /;$/
For the few places where a ; is actually needed you can run a regexp based search as well, the rest is easily identified by unit tests.
We've also spend some 50+ hours on writing new code, tests, a new build and automated tests system, a completely new documentation site and answering countless issues on GitHub.
So yes, you could say my taste changed, but there's good a good reason behind it—the semicolons are optional, and Zepto is all about concise code.
A correct minifier works on the AST of the code anyway (at least in the abstract). It works on the semantic meaning of the code, so it interprets semicolons or the lack thereof exactly the way any other implementation would.
The first case with the broken inlining tool is typically not actually an issue, because your semicolonless code gets put through a minifier which probably adds a bunch of semicolons again :)
I think for the library code itself we prefer using JavaScript because in lots of ways it allows very fine-tuned control, one (of many) examples for this is deliberately using == instead of ===.
I love Coffee and would use it for everything, but this is one of those cases where we simply need to squeeze every single byte and scream each time that we have to let one go.