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...@mzmcbride.com> wrote: > Ori Livneh wrote: >> On Mon, Dec 9, 2013 at 2:58 PM, Ryan Kaldari <rkald...@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...@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...@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/ _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
