On 9/30/10 9:31 AM, Trevor Parscal wrote:
Tim,
First off, thank you for taking the time to respond here, I know you have a lot on your plate right now, and I hope things are going well for you. I did not mean to call you out as having made a mistake as much as I wanted to point to examples of what kinds of changes have been made based on what I feel are misunderstandings.
On 9/29/10 6:28 PM, Tim Starling wrote:
On 30/09/10 08:27, Trevor Parscal wrote:
There seems to be some confusion about how ResourceLoader works, whichhas been leading people to make commits like r73196 and report bugs like #25362. I would like to offer some clarification.
I made that change because it was requested by multiple people in discussions before the resource loader was implemented. It's not because I actually had any actual problem with debugging, I'm well aware of the existence of the debug mode.
Your responsiveness to the community is admirable, but I feel this may be a case where more collaborative discussion should have taken place before action was taken. Nonetheless, I appreciate your boldness, even if I disagree with the action taken.
Concerns were raised that it may be necessary to interpret minified code in cases such as:
- Where it is suspected that, due to caching issues, the debug code
may not be the same as the minified code.
Shift+refresh?
- To debug the minifier itself, which is far short of a full
JavaScript parser and may well introduce functional differences.
If JSMin is causing the bug, then it will be best detected by seeing that debug=true/false have different behavior, not that debug=true contains line breaks.
- Where end users report platform-specific JavaScript errors, it may
be useful to be able to match the line number of the error with something meaningful.
The usefulness of this is attached to the idea the most important part of the error message is the line number. In some browsers (such as many versions of IE) the line numbers aren't even correct. Besides, as I have said already, over and over, combination is going to throw off line numbers anyways, not just making them higher, but depending on the user's preferences they may be totally different from one user to another. Line numbers in production mode (debug=false) are useless no matter how much white-space is preserved.
Since the cost of adding line breaks is fairly small, the contention was that it was a fair compromise between size and developer (and tech supporter) sanity. So I took those comments on board and implemented it shortly after the branch merge.
We should probably calculate just how small that cost is before we start making asumptions based on it being "fairly small". Also, as I have been saying, the production mode (debug=false) is only going to become more optimized in the future, further reducing the value of line numbers.
OK, now I've calculated it...
On a normal page view with the Vector skin and the Vector extension turned on there's a 2KB difference. On an edit page with the Vector skin and Vector and WikiEditor extensions there's a 4KB difference.
While adding 2KB to a request for a person in a remote corner of the world on a 56k modem will only add about 0.3 seconds to the download, sending 2,048 extra bytes to 350 million people each month increases our bandwidth by about 668 gigabytes a month. I don't know what that kind of bandwidth costs the foundation, but it's not free.
I am not meaning to argue with *you* on a point-by-point basis as much as I'm arguing with the originators of these points. I get the feeling that, while you may understand how resource loader works, they may not.
My top priorities are to make the site as high-performance as possible while maintaining a reasonable level of developer friendliness. These are on opposite ends of the spectrum, and middle ground serves neither well.
- Trevor
-- Tim Starling
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l