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
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?
issue is that you're focusing on the mess that was of your
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.
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'
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.
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
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
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."