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
