On 12/8/10 3:40 PM, Andrew Garrett wrote: We already had this debate, in epic fashion, around September 30 - Oct 1st 2010. Rough estimates were traded, that suggested that these hacks to JSMin would - increase the total Javascript weight by 2KB; - delay the page load by 0.3 seconds for a low-bandwidth user (assume 56K); - increase the total bandwidth served by Wikimedia by ~600GB or even over 1TB (however, at our current scale the bandwidth cost is just $25 to $50/month). http://lists.wikimedia.org/pipermail/wikitech-l/2010-October/049760.html As for what this means I think it depends where you sit. It seems that cost is not a factor. So we have usability versus simplicity of development. I normally would say that a website should throw everything they've got into better user experience. A third of a second is already more than the difference between a page feeling snappy or sluggish.[1] Or, looked at the other way, 2KB more of Javascript could add several more features. If you look at our peers in the Alexa rankings, all of them have used minification -- sometimes really aggressive minification that results in Javascript that looks like line noise -- for more than half a decade now. While it's true we have fewer paid developers than they do, even piddly little single-developer web sites now do this sort of thing routinely. So this isn't something Trevor invented just to vex Wikitech-l with. I understand his exasperation here that we have to rehash debates that the rest of the web seems to have settled in 2004 or so. But then again, we really are different so I'm willing to suspend judgment here. We're not like Google where maybe only 10 people in the world fully understand the tricks and compromises involved in making the front page go (or if we are, we shouldn't be). For us, there's a much more gradual continuum from inside developer to random tech-illiterate user. So I'm more willing to trust Tim's judgment that better bug reports and casual inspection of source code are more important for us. If not, we can revisit this decision at a later time, perhaps when our community is more used to the whole Resource Loader concept. We'll probably get lots of bug reports complaining about the useless newlines, as we just did. ;) [1] Of course, Javascript loading trails initial page load, but the point still stands -- 2KB is a LOT. -- Neil Kandalgaonkar ) <neilk(a)wikimedia.org>

On 12/8/10 3:40 PM, Andrew Garrett wrote: You expect users to have the expertise to report a bug which includes a line number where the bug occurred, yet you don't expect they will be able to add debug=true to the URL when asked to do so? Also, the critical part of reporting a bug is rarely the only information needed to fix a problem. Is there any data on how significant the number of or quality of bug reports will be impaired by this? We would be the only web site I know of, certainly the only web site of similar size to choose to try and retain line-numbers in production output. I suspect that they are still functioning just fine. - Trevor

On Thu, Dec 9, 2010 at 1:38 PM, Chad <innocentkiller(a)gmail.com> wrote: In particular, none of them expect users or volunteers to debug anything.

This advice is all well and good, unless someone in particular actually is misguided. Glad to see people jumping on the chance to posture themselves as superior communicators - that's also really productive! - Trevor On 12/9/10 9:28 AM, Aaron Schulz wrote: