At 2010-10-01 01:50, Trevor Parscal wrote: > On 9/30/10 4:31 PM, Maciej Jaros wrote: >> At 2010-09-30 23:13, Trevor Parscal wrote: >>> On 9/30/10 1:55 PM, Maciej Jaros wrote: >>>> At 2010-09-30 20:35, Trevor Parscal wrote: >>>>>>> [...] >>>>>>> * 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. >>>> To my experience something is better then nothing. IE (old one that is) >>>> is usually wrong when you have either long lines (ekhem ;-)) and have >>>> code inside script tags (instead of outer files). Picture this: >>>> >>>> 1. A user says his browser reports an error. >>>> 2. I ask for the browser and other stuff... >>>> 3. I don't see the problem. >>>> 4. He tries out debug mode and it's fine. >>>> 5. I search through his code... >>>> >>>> The problem with fully minified without any vertical white space code to >>>> me is that you cannot read this. Well I can't and Firebug can't and any >>>> other debugger AFAIK. If something comes up it will be almost impossible >>>> to catch. >>>> >>> There's this assumption here that when a bug is reported that a >>> JavaScript developer is going to be lost without a line number. My >>> experience is that when bugs are reported, the first step is >>> reproduction, and then investigation. If we shouldn't be relying on >>> users with little or no expertise to be participating in investigation. >>> Also, error reporting with Firebug and most browsers is much more >>> verbose than "error on line ##". >> It's not an assumption. I AM one of the main developers working on bugs >> reported by users on pl.wiki. And yes line number is very helpful if >> accurate. Also note that I was picturing a situation where I have to >> debug the minified code when I don't get the error in my browser(s) at >> hand. Usually the problem is some extension/plug-in, but I can't tell >> unless I investigate. And reading minified code at it's current state is >> impossible for me. >> > How can you possibly resolve an issue if you can't reproduce it? > Developers have access to multiple browsers for this exact reason. > Otherwise, you are debugging and programming blind, which is extremely > unproductive.
I'm very productive with inspecting code with my eyes. Ask my boss ;-). >> I understand the need to minify code I really do. I just don't get it >> why do you want to minify this that much. HTML which is usually served >> at every page load is not minified. Further more even minified HTML can >> be readable for debuging purposes as every debugger (inspector) shows >> the structure of the code rather then a code pulp. Also why are there >> are explicitly added comments like "<!-- /navigation -->". People don't >> need comments and whitespace to read code, right? Also I have a PHP >> minifier if you are interested. Let's serve Mediawiki encode and if some >> developer want to debug the code he can always switch folders. >> > I think that our outgoing HTML *should* be minified, and those comments > should be stripped, I just have yet to get to that as of yet. Go to > www.google.com and view source. Tell me what you see. Why are we so > different from them? They are taking advantage of aggressive > minification, and we should too. > > To be honest, I can't quite wrap my head around why I am getting any > friction on making the front-end as fast as possible. I was expecting > people to say I had not gone far enough. Two reasons probably: 1. The gain is not big for average user (loading big JS is only painful at first visit in a day or even more). 2. Wikipedia is not Google (you go to a Google's website and use it; you go to Wikipedia and change it). >>>> Plus developers will probably stick to debug mode if won't provide >>>> something in the middle. Yes, I can't speak for all, but personally I >>>> work on code (small tweaks) from time to time while I'm not doing other >>>> stuff in the minute. Always changing to debug mode to debug code will >>>> not be very productive to me. That's why I wrote my loader and I was >>>> hoping that you will add some stuff from it to the loader so I can use >>>> it and so the RL can be useful to me (in non-wikimedia use cases too). >>> This is what debug mode is for. Developers. Developers should always use >>> debug mode while debugging. Switching back and forth is not necessary >>> for every tiny change, just a good thing to verify before checking in code. >>>> Again I'm sure you are confident with your code and code of your >>>> colleagues and I'm not saying you screwed something up. I'm just saying >>>> something will eventually get screwed up just because it always does. >>>> That's why programmers are always needed isn't it ;-). >>>> >>> It's not a matter of me thinking our code is so good it won't break. >>> It's a matter of wanting to send fully optimized code to clients, not >>> partially optimized code. >> This is impossible. Fully optimized code would only contain one byte per >> variable name. Yo need to make sacrifices. And this seems to be needed >> as shown before and above. >> > Google Closure Compiler is on the horizon, and with it, single letter > names for temporary variables and functions within closures can be > achieved without obfuscating the original source code. Closure can do > more tricks than that, but that's a start, and usually yields 10% > reductions or more depending on how verbose your naming tends to be. If I could be honest I would say I hope no one will ever have time to implement it. >>> I agree that something will always break - I just disagree that there's >>> much merit in your approach to solving this. >>> >>> If we are talking about allowing the ResourceLoader to be configurable >>> with LocalSettings.php adjustments, then you are already assuming a >>> level of expertise about the developer debugging the problem that these >>> middle-ground approaches will be useless. >>> >>> If we are talking about adding yet another URL parameter to be able to >>> turn minification off, or otherwise customize the processing of the >>> modules beyond turning debug on and off, I think you are adding >>> complexity without reasonable benefit. >> Well we differentiate on that. I'm wondering of what is you scenario on >> debugging the minified code. > Why would you want to debug code in production mode? I'm asking you how are you going to cope with a situation in which some brand new, minified code is buggy. How are you going to fix it? Two scenarios: you are able to reproduce this only in Opera Mobile, you are only able to reproduce it in IE6. Regards, Nux. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
