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 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.
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.
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?
- Trevor
Regards,
Nux.
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l