Trevor Parscal wrote: > 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.
Yes, I've looked at www.google.com's page source. It doesn't have a closing <body> tag or a closing <html> tag. It's also largely unreadable. I'm not sure why this is a something to strive for. Bandwidth on Wikimedia's end is cheap. The emerging bandwidth issues come largely from mobile platforms, which have separate mobile sites to address this. That isn't to say bandwidth should be needlessly wasted, but there's no reason to be paranoid about it. Whether or not you remove every newline from the HTML output is going to have a negligible impact for mobile and non-mobile platforms. It will have a demonstrable impact on developers and users, though, which I'll discuss below. > 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. You're getting friction because of three different issues. The first issue is that the front-end is currently pretty damn fast for _most_ people. It's serving cached HTML most of the time with very little JavaScript executed for a huge majority of users because (1) these users are not editing, they're just reading; and (2) these users are not logged in. I imagine there would be a lot more support for making, for example, page rendering faster. Anyone who has edited a large article logged in knows how painful it is. If ResourceLoader is going to address _that_ problem, then this is a marketing and public relations issue. The second issue is that you're focusing on the mess that was of your creation. There's a huge effort to clean up the insane amount of JavaScript that the UsabilityInitiative introduced. There isn't going to be much appreciation for cleaning up your own mess. Don't take that the wrong way, please. I'm not saying that the UsabilityInitiative's work wasn't good, but it came at a cost that now has to be addressed. You're asking why people aren't too excited about the clean-up and I'm offering my theory. The third issue is that, unlike www.google.com, Wikimedia wikis are editable sites. People customize their experience via gadgets, user scripts, and other things of that nature. The same isn't true for Google's homepage. The interactivity of Wikimedia wikis means that users need to be able to read the page source easily. This includes the HTML page source, the CSS, and the JavaScript that's loaded. Minification and obfuscation come at a cost when trying to develop scripts that modify the user experience. People have been trying to say this to you in so many ways, but you don't seem to be quite getting that. Yes, there's a debug mode via a URL parameter, but anyone who has ever dealt with settings set temporarily by URL parameter (?useskin, ?uselang, etc.) know what a pain in the ass these are. And, as with every feature ever introduced, there _will_ be bugs that come from minification and obfuscation. There doesn't seem to be an acknowledgement of this in a lot of your writing, which seems to be frustrating a lot of people. MZMcBride _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
