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 (| <neilk(a)wikimedia.org>