I love how this thread evolved, +1 on pretty much all previous replies.
A few more thoughts though.
On 10 Dec 2013, at 03:29, MZMcBride <z(a)mzmcbride.com> wrote:
Ori Livneh wrote:
On Mon, Dec 9, 2013 at 2:58 PM, Ryan Kaldari
<rkaldari(a)wikimedia.org>
wrote:
I am somewhat concerned about the implications
for JS debugging here.
Debugging JS problems with the live sites is already pretty complicated:
1. debug=true won't reproduce some bugs (usually race condition related)
Yeah, debug mode sucks. I think we need to think it over.
Indeed, there are various improvements to be made to debug mode. As well as
various bug fixes, such as the execution scope. In debug mode we currently load
javascript without closures, thus resulting in differences when there are scope
bugs. This should make no difference for “good” code (and for this
definition of good, anything passing jshint is good enough), but we still have
extensions with largely unreviewed javascript, and of course gadgets, site
scripts and user scripts which can contain anything imaginable.
On 10 Dec 2013, at 03:29, MZMcBride <z(a)mzmcbride.com> wrote:
Currently it goes something like this, as I understand
it: by default, all
CSS and JavaScript is concatenated and minified as much as practically
possible. If you pass a "debug=true" URL parameter to index.php, you can
disable this concatenation and minification of CSS and JavaScript (which
largely, if not exclusively, come through via load.php/ResourceLoader).
Yep, baring a few oversimplified details, this is correct.
A more detailed description:
https://www.mediawiki.org/wiki/ResourceLoader/Features
On 10 Dec 2013, at 03:29, MZMcBride <z(a)mzmcbride.com> wrote:
* Minification reduces bandwidth usage.
** At the cost of making debugging more difficult.
* You can specify debug=true.
** Specifying the URL parameter can damage reproducibility.
** URL parameter is non-obvious to just about everyone.
*** Could add an HTML comment at least pointing people in this direction.
* Minification is a form of obfuscation and it harms the open Web.
I'm not sure what the right answer is here. The damage to reproducibility
and the open Web hurts a lot. The performance hit may hurt more.
Don’t forget that concatenation is also an important factor in reducing
bandwidth. Firstly because gzip is far more effective when applied to a larger
package. Secondly, because the number of http requests can sometimes be a more
significant cause of slow-down than file size, especially on mobile where both
matter very mcuh.
I disagree it makes debugging more difficult. It certainly adds a level of
abstraction, but I don’t think this level is affecting difficultly. Especially
considering the tools that browsers ship nowadays for debugging. These have
improved a lot over the years. For one, Chromium-based browsers have had for
several years now (Chrome, Opera, ..) and WebKit releases recently (Safari 6)
all have a “Pretty print” or “Original formatting” feature that will
expand minified code on-the-fly without reloading, reparsing, or reproducing
anything. That is enough to allow a developer who is reproducing a bug to
understand context and step-through code execution.
It might not give an exact file and line number, but that’s inevitable short
of banning converters (e.g. js closure wrapping, and CSSMin @embed) or compiling
(LESS) completely. What matters is the context of the error and what module it
originates from.
And in most cases you don’t even need pretty-print in order to know context.
Variable and function names in the stack trace usually provide more than enough
information when provided by a bug reporter for developers to know where to
look.
On the subject, there are other things I think we should focus on to improve
debugging in modern browsers: Source maps[1]. Having source maps will actually
provide the one thing we can’t provide right now: Getting original file names
and line numbers without sacrificing compilation or conversion. In fact, we
could drop debug mode entirely (short of its effect on debug-modules being
loaded, it wouldn’t affect the way modules are packages anymore).
As example, when working on VisualEditor I never ever use debug=true (not
locally, not in production). It is completely unnecessary and would be rather
slow to request near 600 raw js and css files from a server (used to be more
before we switched to using a compiled version of OOjs UI). For me it hasn’t
been a trade-off due to the slowness in debug=true, it simply didn’t provide
anything I already had.
— Krinkle
[1]
http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/