These blank lines should not - under any circumstances - be here. But I
do know why they are...
Tim Starling modified the standard distribution of JSMin[1] in some good and some bad ways. These blank lines are the result of one of these modifications which I find to be misguided. He's basically only compressed horizontal white-space, leaving new line characters in place. The blank lines you see are where the comments used to be.
I have made this point before, clearly upon deaf ears - but I will make it again.
* ResourceLoader has 2 modes. Production and Development (or debug) mode. * Production mode should be as fast as possible for users, period. * Development mode should be as easy as possible for developers, period. * Any attempt to blend the two only serves to diminish the effectiveness of either mode.
If you want a version of the script that has not been compressed add debug=true to the URL or set $wgResourceLoaderDebug = true; in your LocalSettings.php.
This particular change (the "don't delete line breaks" part of r73196) should be reverted, Tim's good changes should be pushed upstream, and we should be using a standard JSMin distribution whenever possible.
- Trevor
[1] http://www.mediawiki.org/w/index.php?title=Special:Code/MediaWiki/author/tst...
On 12/7/10 5:32 AM, jidanni@jidanni.org wrote:
Why so many blank lines in this vector component? $ cat yy set 'http://transgender-taiwan.org/load.php?debug=false&lang=zh-tw&module...' GET $1|perl -nwe 'print " $." if /^$/' $ sh yy # These lines are blank: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 20 26 27 28 29 32 33 34 37
http://transgender-taiwan.org/load.php?debug=false&lang=zh-tw&module... is affected too.
Yes these aren't meant for human consumption.
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
2010/12/7 Trevor Parscal tparscal@wikimedia.org:
I have made this point before, clearly upon deaf ears - but I will make it again.
I don't think this'll surprise anyone, but I'll just state that I fully agree with Trevor here.
Roan Kattouw (Catrope)
On Wed, Dec 8, 2010 at 3:11 AM, Trevor Parscal tparscal@wikimedia.orgwrote:
These blank lines should not - under any circumstances - be here. But I
do know why they are...
Tim Starling modified the standard distribution of JSMin[1] in some good and some bad ways. These blank lines are the result of one of these modifications which I find to be misguided. He's basically only compressed horizontal white-space, leaving new line characters in place. The blank lines you see are where the comments used to be.
I have made this point before, clearly upon deaf ears - but I will make it again.
* ResourceLoader has 2 modes. Production and Development (or debug) mode. * Production mode should be as fast as possible for users, period. * Development mode should be as easy as possible for developers,period. * Any attempt to blend the two only serves to diminish the effectiveness of either mode.
If you want a version of the script that has not been compressed add debug=true to the URL or set $wgResourceLoaderDebug = true; in your LocalSettings.php.
This particular change (the "don't delete line breaks" part of r73196) should be reverted, Tim's good changes should be pushed upstream, and we should be using a standard JSMin distribution whenever possible.
I think the point is that it makes bug reports that much easier to understand when they're reported by somebody who isn't in debug mode. This has to be traded off against the performance advantages of removing blank lines. Is there any data on how significant the performance improvements are?
On 12/8/10 3:40 PM, Andrew Garrett wrote:
On Wed, Dec 8, 2010 at 3:11 AM, Trevor Parscaltparscal@wikimedia.orgwrote:
This particular change (the "don't delete line breaks" part of r73196) should be reverted, Tim's good changes should be pushed upstream, and we should be using a standard JSMin distribution whenever possible.
I think the point is that it makes bug reports that much easier to understand when they're reported by somebody who isn't in debug mode. This has to be traded off against the performance advantages of removing blank lines. Is there any data on how significant the performance improvements are?
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.
@2010-12-09 05:25, Neil Kandalgaonkar:
On 12/8/10 3:40 PM, Andrew Garrett wrote:
On Wed, Dec 8, 2010 at 3:11 AM, Trevor Parscaltparscal@wikimedia.orgwrote:
This particular change (the "don't delete line breaks" part of r73196) should be reverted, Tim's good changes should be pushed upstream, and we should be using a standard JSMin distribution whenever possible.
I think the point is that it makes bug reports that much easier to understand when they're reported by somebody who isn't in debug mode. This has to be traded off against the performance advantages of removing blank lines. Is there any data on how significant the performance improvements are?
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;[...]
2KB with or without compression? AFAIR all calls were supposed to be gzipped and if gzip is not the lamest compressing method of all it will compress "\n" x 30 in 2B and so having 30 whitespace or just one shouldn't really be that much of a difference.
Besides 2KB? Powered by MW icon is heavier. Just lowering colour depth to 16 would save just as much. Changing two power icons into background + text + two small icons would probably save as much too.
Regards, Nux.
On 12/8/10 3:40 PM, Andrew Garrett wrote:
I think the point is that it makes bug reports that much easier to understand when they're reported by somebody who isn't in debug mode. This has to be traded off against the performance advantages of removing blank lines. Is there any data on how significant the performance improvements are?
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:18 PM, Trevor Parscal tparscal@wikimedia.org wrote:
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
This is quickly getting OT. This is a productive list guys, lets keep it that way :)
On Thu, Dec 9, 2010 at 1:12 PM, Trevor Parscal tparscal@wikimedia.org wrote:
On 12/8/10 3:40 PM, Andrew Garrett wrote:
I think the point is that it makes bug reports that much easier to understand when they're reported by somebody who isn't in debug mode. This has to be traded off against the performance advantages of removing blank lines. Is there any data on how significant the performance improvements are?
+1. I'd really like to see data on this as well. Linebreaks just seem inherently useful, and I think we need to make a stronger case for performance if we're going to remove them.
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.
I don't think it's about expertise at all.
For what it's worth, we also get a good number of drive-by bug reports, so *expecting* followup to a bug can leave you with nothing.
Is there any data on how significant the number of or quality of bug reports will be impaired by this?
No, and given the subjective nature of quality, I don't think you could easily measure it.
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.
There's lots of other differences between us and other sites of our size, so we shouldn't always look to our neighbors for advice :)
-Chad
On Thu, Dec 9, 2010 at 1:38 PM, Chad innocentkiller@gmail.com wrote:
There's lots of other differences between us and other sites of our size, so we shouldn't always look to our neighbors for advice :)
In particular, none of them expect users or volunteers to debug anything.
Chad wrote:
On Thu, Dec 9, 2010 at 1:18 PM, Trevor Parscal tparscal@wikimedia.org wrote:
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!
This is quickly getting OT. This is a productive list guys, lets keep it that way :)
I don't think this is off-topic. And I think that ignoring the underlying issues here is going to make the future dimmer, not brighter.
What authority one developer has over another should probably be made clearer. There's a fine (and important) distinction between a revert that is "this is implemented poorly or has issues currently" and "this is never going to happen because I say so." I think a lot of people have misinterpreted Tim's motives lately with specific reversions or code changes, which indicates a communication problem. This is one of the issues that comes along with developers working asynchronously and continents apart.
Snarky mailing list replies aren't helpful, though venting often is. Generally best not to vent in public, though. It isn't about people posturing themselves as superior communicators, it's about figuring out ways to ensure that actions and their underlying motives aren't misinterpreted.
MZMcBride
On 08/12/10 03:11, Trevor Parscal wrote:
These blank lines should not - under any circumstances - be here. But I
do know why they are...
Tim Starling modified the standard distribution of JSMin[1] in some good and some bad ways. These blank lines are the result of one of these modifications which I find to be misguided. He's basically only compressed horizontal white-space, leaving new line characters in place. The blank lines you see are where the comments used to be.
I have made this point before, clearly upon deaf ears - but I will make it again.
You could have just said "because Tim thought it would make debugging easier", and left out all the insults: "misguided", "deaf ears", etc. We've each given our opinions on this issue previously, the only thing you've added here is a dollop of incivility.
Your bullying has not changed my position. I think this is a minor issue, and I have better things to do than to argue about it. I don't intend on doing any more work on JSMin for the time being. Feel free to make the relevant change yourself.
-- Tim Starling
+1 to this. Lets focus more on the changes and ideas and less on the authors.
IMO, when I keep seeing things like "he did"/"he changed" and "[so and so] made it so that" instead of things like "the change made" it throws up red flags. Just discuss the change, and mention the person minimally (to help identify the changes or get the attention of person X) or not at all. I've also seen a lot of things like "misguided" and "bad idea" by some people. This raises red flags too. Just discuss *what* the problems are, rather than saying "this decision sucks".
I've seen this pattern by more than one person.
Tim Starling-2 wrote:
On 08/12/10 03:11, Trevor Parscal wrote:
These blank lines should not - under any circumstances - be here. But I
do know why they are...
Tim Starling modified the standard distribution of JSMin[1] in some good and some bad ways. These blank lines are the result of one of these modifications which I find to be misguided. He's basically only compressed horizontal white-space, leaving new line characters in place. The blank lines you see are where the comments used to be.
I have made this point before, clearly upon deaf ears - but I will make it again.
You could have just said "because Tim thought it would make debugging easier", and left out all the insults: "misguided", "deaf ears", etc. We've each given our opinions on this issue previously, the only thing you've added here is a dollop of incivility.
Your bullying has not changed my position. I think this is a minor issue, and I have better things to do than to argue about it. I don't intend on doing any more work on JSMin for the time being. Feel free to make the relevant change yourself.
-- Tim Starling
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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:
+1 to this. Lets focus more on the changes and ideas and less on the authors.
IMO, when I keep seeing things like "he did"/"he changed" and "[so and so] made it so that" instead of things like "the change made" it throws up red flags. Just discuss the change, and mention the person minimally (to help identify the changes or get the attention of person X) or not at all. I've also seen a lot of things like "misguided" and "bad idea" by some people. This raises red flags too. Just discuss *what* the problems are, rather than saying "this decision sucks".
I've seen this pattern by more than one person.
Tim Starling-2 wrote:
On 08/12/10 03:11, Trevor Parscal wrote:
These blank lines should not - under any circumstances - be here. But I
do know why they are...
Tim Starling modified the standard distribution of JSMin[1] in some good and some bad ways. These blank lines are the result of one of these modifications which I find to be misguided. He's basically only compressed horizontal white-space, leaving new line characters in place. The blank lines you see are where the comments used to be.
I have made this point before, clearly upon deaf ears - but I will make it again.
You could have just said "because Tim thought it would make debugging easier", and left out all the insults: "misguided", "deaf ears", etc. We've each given our opinions on this issue previously, the only thing you've added here is a dollop of incivility.
Your bullying has not changed my position. I think this is a minor issue, and I have better things to do than to argue about it. I don't intend on doing any more work on JSMin for the time being. Feel free to make the relevant change yourself.
-- Tim Starling
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org