madrobby's comments

Of course, exceptions prove the rule. Sometimes CSS and HTML are not good enough and you'll have to resort to use JavaScript.

But you shouldn't make it the default go-to.

I'm slightly disappointed that it's implemented in more than 140 bytes.

Keep on being awesome. :)

@NathanBowers on twitter suggested looking into http://convertico.org/Multi_Image_to_one_icon/

Media resolution is relative, as people zoom in on mobile phones all the time.

For stuff like photos, just supply a larger resolution JPEG that has lower quality. This will look great when smaller and when zoomed in, while keeping the file size in a range that is ok for mobile.

Good to know that depending on the author of an article, some stories don't get flagged and disappear from the front page of hacker news.

In addition I'd say that the interpreter is broken and should be fixed to be faster. "with" is not deprecated.

I wouldn't use "with" in most situations, but I like it in the testing code and for some DSLs, as it makes things more readable (again, personal style).

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.)

#1 has nothing to do with size optimization, it's purely stylistic and about having to write less code. See also http://blog.izs.me/post/3393190720/how-this-works

It is not an issue. Zepto uses UglifyJS and there have been no issues whatsoever.

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 ===.

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.

(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.

It's my blog, the concept of which is that I write my opinion in blog posts.

So what if there's an uproar? Other license writers could also want to be treated specially.

This is just about a general filter, into "proprietary", "do whatever you want to", and "restrictive" open source licenses; for developers when they choose which projects on GitHub might be a good fit for their needs.

If you read the GPL it puts a lot of restrictions on what you can do as a developer. So do other licenses (for example licenses that allow you to use the source in open source projects but require some form of payment when used for commercial products).

It's actually really simple:

"Permissive": anything that is generally MIT/BSD/WTF/Apache 2.0

"Restrictive": anything that is GPL or requires you to pay for or share all sources

Given that the vast majority of software use only one of a handful of licenses, I think that's a non-issue (tho there may be edge cases, I agree with that). For stuff that is not categorized, people can just put in "other".

(Do you have a list of those classifications btw, that would be useful.)

In general, a setting like this would likely raise awareness of people sharing code that they should choose a license in the first place. Far too many useful pieces of code on GitHub don't come with a license or copyright statement at all.

The LICENSE or COPYING file in the repository wins, obviously. Also, not everyone would set the setting. But it's a start.

The drop down has 4 entries. Please read the article again. :)

Many people don't know what "copyleft" is, so "restrictive" makes more sense. There are more restrictions.

For complex situations, you can always choose "other". As stated in my article, this isn't a replacement for a project's LICENSE file.

A list of every type if license can't work, because it needs to be constantly updated and people may want to write their own, etc.

That's why the general type makes much more sense for a quick glimpse if some code is probably suitable license-wise for your project.

That's a bug the site has with Firefox, which we haven't gotten around to fix yet. It does work properly in Chrome/Safari/IE, tho.