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, which >>> has 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 >> [email protected] >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
