Re: [Wikitech-l] ResourceLoader Debug Mode ( the need for a platform)
On 9/30/10 6:04 PM, MZMcBride wrote: 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. The front end that we have *now* is fast for some people. The point of writing a new platform is to be able to do more, if we want. 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. I think we have a large difference of vision here. By contemporary standards the amount of JS in the UsabilityInitiative, and related projects, is a mere trifle. Our competitors invest a lot in Javascript infrastructure because they find that every last efficiency is usually worth it. If stripping newlines gives us 1K more per page, we can squeeze 1K more of usability or other interface niceties in. Now, we might decide not to do certain kinds of minification for other very good reasons. But I say this to put the Resource Loader in context. The point here, at least as I see it, is to bring Wikimedia sites up to the standards of the rest of the web, not to clean up some mess. 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. I agree this is a very good reason why we should hesitate before doing anything that would obfuscate our pages. View Source doesn't work as well on the web any more, and it should on Wikipedia. (I personally would set the balance at a different point -- I'd like there to be a note right in the page source explaining how to view an unoptimized version.) That said, your assertion that Google doesn't allow customizations of its page is just not true. Google has offered skins for something like a year or more now, and their home page widget platform is literally called Gadgets. http://www.google.com/ig/ The great grandaddy of all site-Javascript modifiers is GreaseMonkey, and the guy that wrote that is even a Google employee (Aaron Boodman). Mihai Parparita, another Google employee, circulates a very popular set of Greasemonkey improvements to Gmail. So, the argument that Google etc. just don't get developer hacks, or that they do them badly, is quite wrong. Their platforms for doing this are far, far more successful than ours. We should be learning from them on this, not vice versa. Here's how they do it: Google guarantees that certain Javascript functions or DOM objects are reliably available for use and modification, and others are not. So they use minification for efficiency while explicitly preventing some things from being altered (that's a feature of Google's Closure Compiler). This is a story as old as computing; to enable a community, create a rich platform with a stable public API. Merely leaving the pages open to any modification is actually worse for gadget writers, since anything could change. Anyway, I think that's somewhat in the flavor of what the Resource Loader people are trying to achieve here. Efficiency *and* community. Minification *and* openness. Gadget-writers are a big part of their targeted use cases. Otherwise, they would have just used something off the shelf. There are a lot of good JS libraries out there, but none that quite fit the needs of our community. -- Neil Kandalgaonkar (| ne...@wikimedia.org ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ResourceLoader Debug Mode ( the need for a platform)
On 9/30/2010 10:03 PM, Neil Kandalgaonkar wrote: Here's how they do it: Google guarantees that certain Javascript functions or DOM objects are reliably available for use and modification, and others are not. So they use minification for efficiency while explicitly preventing some things from being altered (that's a feature of Google's Closure Compiler). This is a story as old as computing; to enable a community, create a rich platform with a stable public API. As a gadget developer, I would love that. However, that seems to be, in part, the opposite of what's happening. We're taking a public API that's been used for years (wikibits.js) and deprecating the whole thing, with no documentation (that I can find in a couple minutes of searching) for the replacements. When the new skin/editor was rolled out, there was basically no documentation for anything and there still isn't very much. When I rewrote the reftoolbar gadget[1] to support the new toolbar, in advance of the rollout, I had to do it by reading the Wikieditor code and testing on a personal sandbox wiki running trunk, which changed often and was frequently broken. Now I'm probably going to have to do that again to make sure it won't break with ResourceLoader. That's not a very good development process. Merely leaving the pages open to any modification is actually worse for gadget writers, since anything could change. Anyway, I think that's somewhat in the flavor of what the Resource Loader people are trying to achieve here. Efficiency *and* community. Minification *and* openness. Gadget-writers are a big part of their targeted use cases. Otherwise, they would have just used something off the shelf. There are a lot of good JS libraries out there, but none that quite fit the needs of our community. That's all great, but if you're going to go that route, you have to make damn sure you get everything right, else we're going to end up with a bunch of frustrated gadget developers and a ton of angry users with broken gadgets. [1] http://en.wikipedia.org/wiki/Wikipedia:RefToolbar_2.0 -- Alex (wikipedia:en:User:Mr.Z-man) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ResourceLoader Debug Mode ( the need for a platform)
Neil Kandalgaonkar wrote: The front end that we have *now* is fast for some people. The point of writing a new platform is to be able to do more, if we want. Do more, such as? If there's a broader outlook here, a roadmap for the future, what is it and where is it posted? I think there's a reasonable expectation that if you're going to make claims like this and push forward on projects like ResourceLoader, there be a list of all the gains that are going to be made as a result of it, or at least a list of all the foreseeable gains from it. You're talking about doing more. Be specific. I've looked at http://www.mediawiki.org/wiki/ResourceLoader and Trevor has said that the non-public roadmap will soon be public, though it's my understanding that the roadmap is more about deployment, not about the grand vision of what ResourceLoader will enable in the future. Can you shed some light on this? 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. I think we have a large difference of vision here. By contemporary standards the amount of JS in the UsabilityInitiative, and related projects, is a mere trifle. Our competitors invest a lot in Javascript infrastructure because they find that every last efficiency is usually worth it. If stripping newlines gives us 1K more per page, we can squeeze 1K more of usability or other interface niceties in. Which competitors are you referring to here? You seem to be suggesting that a lot of other sites bog down their users' experience with an obscene amount of JavaScript, so it's okay for Wikimedia to do the same, albeit with a bit less JavaScript. This doesn't follow. You also seem to be creating a mostly false trade-off through the idea of premature optimization. There isn't a fixed size a page can be. Making the HTML output unreadable and adding a feature aren't mutually exclusive. To suggest that they are isn't fair. 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. I agree this is a very good reason why we should hesitate before doing anything that would obfuscate our pages. View Source doesn't work as well on the web any more, and it should on Wikipedia. (I personally would set the balance at a different point -- I'd like there to be a note right in the page source explaining how to view an unoptimized version.) That said, your assertion that Google doesn't allow customizations of its page is just not true. Google has offered skins for something like a year or more now, and their home page widget platform is literally called Gadgets. http://www.google.com/ig/ I was talking about www.google.com, as was the post I was replying to. Google has iGoogle, that much is certain, but I don't see how that's relevant to the broader discussion, sharing the use of the term gadgets notwithstanding. I think it's possible that your answer to the what are the future benefits of ResourceLoader? question might make what you were trying to say here clearer. Anyway, I think that's somewhat in the flavor of what the Resource Loader people are trying to achieve here. Efficiency *and* community. Minification *and* openness. Gadget-writers are a big part of their targeted use cases. Otherwise, they would have just used something off the shelf. There are a lot of good JS libraries out there, but none that quite fit the needs of our community. The broad point of my previous reply was that minification and obfuscation come at a real cost and the acknowledgement of this cost seems to be non-existent from the people pushing ResourceLoader forward. That's my take from reading the past discussion on this list, but perhaps I'm completely off the mark. When people talk about friction but can't understand the source of this friction, that indicates a problem to me. And it seems to be directly incompatible with your stated goal of efficiency *and* community. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
