Re: [Wikitech-l] Re-evaluating MediaWiki ResourceLoader's debug mode
On Wed, 18 Dec 2013 03:28:36 +0100, Krinkle krinklem...@gmail.com wrote: 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). While this would be lovely, some browsers don't support source maps, and people do debug things on these too. I agree debug mode is rarely useful – but sometimes it is. -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Re-evaluating MediaWiki ResourceLoader's debug mode
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
Re: [Wikitech-l] Re-evaluating MediaWiki ResourceLoader's debug mode
Another point to look into if someones wants to refactor the RL debug=true: When loading VE with debug=true hundreds of modules are loaded (with different requests) and it takes long to load it. It would be nice to have an option of debug=0.5 :) in which all the resources (or at least the ve resources) will be loaded as one request, but without minified code and including all the comment. On Wed, Dec 11, 2013 at 8:46 PM, Jon Robson jdlrob...@gmail.com wrote: +1000 to what Max says. It really is kinda obvious to anyone who needs to know how to get into debug mode and if not there are wiki pages and if not it's easy enough to find out if you care enough. That said debug mode could definitely be improved and I'm glad you brought this topic up Max. A few things of the top of my head I'd like to see: * RTL working in debug mode * The code in ResourceLoader really could do with a good refactor - there are far too many different code paths and it would be good if we could simplify this to get them as close as possible. When I've worked with RL in the past to design my own modules which involves files I've had a lot of headaches trying to get things to work in both debug mode and non-debug mode (JavaScript templates [1] being one concrete example) - and even then the result wasn't quite was I was hoping for in that debug mode uses load.php urls to inject JavaScript before the file that needs it. [1] https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FMobileFrontend.git/1f3c57137afae1d0f8ac602b62dccc741893d670/includes%2Fmodules%2FMFResourceLoaderModule.php On 11 Dec 2013 08:33, Max Semenik maxsem.w...@gmail.com wrote: On 11.12.2013, 19:36 Brian wrote: As everybody else already said, less bandwidth is a good thing for most people, obfuscation is OK when the source is available elsewhere, and debug=true is not hard for developers to find. I'd actually disagree with the assertion that debug=true is easy to find, particularly for people who aren't active developers. Some random on the internet who just wants to see what our js looks like (out of curiosity or whatever) is not going to be able to find debug=true. If they look at the URL it will be pretty obvious because all of them have debug=false as first parameter. -- Best regards, Max Semenik ([[User:MaxSem]]) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Re-evaluating MediaWiki ResourceLoader's debug mode
Le 10/12/13 05:30, MZMcBride a écrit : I think adding an explicit HTML comment in the page source is a reasonable suggestion to consider. We already had an argument a few months ago regarding adding comments in the minified css/js and we said no. Who ever look at that source code will be able to find the unminified source. -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Re-evaluating MediaWiki ResourceLoader's debug mode
2013/12/10 MZMcBride z...@mzmcbride.com * Minification reduces bandwidth usage. ** At the cost of making debugging more difficult. There is one thing that debug mode makes harder: Seeing how the page looks in an RTL language. That's because CSSJanus doesn't work in debug mode, and there were several objections in the past to changing that. That is the only thing that I'd love to see re-evaluated. As everybody else already said, less bandwidth is a good thing for most people, obfuscation is OK when the source is available elsewhere, and debug=true is not hard for developers to find. -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Re-evaluating MediaWiki ResourceLoader's debug mode
As everybody else already said, less bandwidth is a good thing for most people, obfuscation is OK when the source is available elsewhere, and debug=true is not hard for developers to find. I'd actually disagree with the assertion that debug=true is easy to find, particularly for people who aren't active developers. Some random on the internet who just wants to see what our js looks like (out of curiosity or whatever) is not going to be able to find debug=true. --bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Re-evaluating MediaWiki ResourceLoader's debug mode
On 11.12.2013, 19:36 Brian wrote: As everybody else already said, less bandwidth is a good thing for most people, obfuscation is OK when the source is available elsewhere, and debug=true is not hard for developers to find. I'd actually disagree with the assertion that debug=true is easy to find, particularly for people who aren't active developers. Some random on the internet who just wants to see what our js looks like (out of curiosity or whatever) is not going to be able to find debug=true. If they look at the URL it will be pretty obvious because all of them have debug=false as first parameter. -- Best regards, Max Semenik ([[User:MaxSem]]) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Re-evaluating MediaWiki ResourceLoader's debug mode
On Wed, Dec 11, 2013 at 11:33 AM, Max Semenik maxsem.w...@gmail.com wrote: If they look at the URL it will be pretty obvious because all of them have debug=false as first parameter. As a proof of concept, this is how I found out about the debug parameter the first time I tried doing Javascript debugging in MediaWiki. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Re-evaluating MediaWiki ResourceLoader's debug mode
+1000 to what Max says. It really is kinda obvious to anyone who needs to know how to get into debug mode and if not there are wiki pages and if not it's easy enough to find out if you care enough. That said debug mode could definitely be improved and I'm glad you brought this topic up Max. A few things of the top of my head I'd like to see: * RTL working in debug mode * The code in ResourceLoader really could do with a good refactor - there are far too many different code paths and it would be good if we could simplify this to get them as close as possible. When I've worked with RL in the past to design my own modules which involves files I've had a lot of headaches trying to get things to work in both debug mode and non-debug mode (JavaScript templates [1] being one concrete example) - and even then the result wasn't quite was I was hoping for in that debug mode uses load.php urls to inject JavaScript before the file that needs it. [1] https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FMobileFrontend.git/1f3c57137afae1d0f8ac602b62dccc741893d670/includes%2Fmodules%2FMFResourceLoaderModule.php On 11 Dec 2013 08:33, Max Semenik maxsem.w...@gmail.com wrote: On 11.12.2013, 19:36 Brian wrote: As everybody else already said, less bandwidth is a good thing for most people, obfuscation is OK when the source is available elsewhere, and debug=true is not hard for developers to find. I'd actually disagree with the assertion that debug=true is easy to find, particularly for people who aren't active developers. Some random on the internet who just wants to see what our js looks like (out of curiosity or whatever) is not going to be able to find debug=true. If they look at the URL it will be pretty obvious because all of them have debug=false as first parameter. -- Best regards, Max Semenik ([[User:MaxSem]]) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Re-evaluating MediaWiki ResourceLoader's debug mode
On 12/09/2013 11:30 PM, MZMcBride wrote: Matthew Flaschen wrote: On 12/09/2013 09:29 PM, MZMcBride wrote: * You can specify debug=true. ** Specifying the URL parameter can damage reproducibility. ** URL parameter is non-obvious to just about everyone. I can't think of a more straight-forward name. It's also clearly documented. Clearly documented where? The detailed explanation is on the ResourceLoader features page (https://www.mediawiki.org/wiki/ResourceLoader/Features#Debug_mode), which is linked from the main documentation for developers using ResourceLoader (https://www.mediawiki.org/wiki/ResourceLoader/Developing_with_ResourceLoader). I just made a tweak to make it more prominent on the developing page. I see that you've filed two bugs regarding source maps: https://bugzilla.wikimedia.org/45514 and https://bugzilla.wikimedia.org/53510. Thanks for these. Source maps are another good approach to consider. Yes, I'd like to see this. It's a standard approach, somewhat analogous to how C, etc. debugging works. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Re-evaluating MediaWiki ResourceLoader's debug mode
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. 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). I believe there's been extensive discussion on this mailing list about the trade-offs being made here. Perhaps it's time for another discussion. * 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. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Re-evaluating MediaWiki ResourceLoader's debug mode
On 12/09/2013 09:29 PM, MZMcBride wrote: * Minification is a form of obfuscation and it harms the open Web. That's true iff there isn't a readily available way of getting the non-obfuscated source. For normal day-to-day browsing you /want/ to shave those extra ms off (all the more so if you are on a metered data plan). -- Marc ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Re-evaluating MediaWiki ResourceLoader's debug mode
On 12/09/2013 09:29 PM, MZMcBride wrote: * You can specify debug=true. ** Specifying the URL parameter can damage reproducibility. ** URL parameter is non-obvious to just about everyone. I can't think of a more straight-forward name. It's also clearly documented. * Minification is a form of obfuscation and it harms the open Web. No, it doesn't. It's no different that compiled code in any other environment. No one says the compiled Linux kernel is bad for C developers. People that need the source can easily find it. The same is true for MediaWiki. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Re-evaluating MediaWiki ResourceLoader's debug mode
Matthew Flaschen wrote: On 12/09/2013 09:29 PM, MZMcBride wrote: * You can specify debug=true. ** Specifying the URL parameter can damage reproducibility. ** URL parameter is non-obvious to just about everyone. I can't think of a more straight-forward name. It's also clearly documented. Clearly documented where? I think adding an explicit HTML comment in the page source is a reasonable suggestion to consider. I see that you've filed two bugs regarding source maps: https://bugzilla.wikimedia.org/45514 and https://bugzilla.wikimedia.org/53510. Thanks for these. Source maps are another good approach to consider. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
